I once built 25 microservices for a side project.

Not because I needed them, but because I wanted to see how far I could push myself.

REST spoiled us. You can debug with curl, Postman, or even a browser. JSON is readable, shareable, and instantly tells you what’s wrong.

gRPC, on the other hand, feels like a black box unless you invest in observability. One time, we spent hours chasing weird strings in a Nest.js object — no errors, nothing obvious. The culprit? A single skipped field number in the protobuf contract. Instead of 3 → 4, someone jumped 3 → 5, and the entire binary translation broke.

REST makes onboarding and debugging simple. gRPC brings efficiency and type safety, but also frustration when contracts break or errors point nowhere. And that’s why many companies hesitate to switch: juniors hit roadblocks, seniors don’t always have time to guide, and adoption slows down.

I once had an interview where I was asked to build a queue messaging system using child processes. The irony? Every company I’ve ever worked for already used RabbitMQ, Kafka, or Azure Service Bus.

Another time, I wasn’t allowed IntelliSense or documentation — I had to pretend I was coding in a vacuum. These kinds of tests always left me wondering: are we really measuring the right things?

But not all interviews are bad. One of the best I ever had was supposed to last 30 minutes. Instead, I ended up in a two-and-a-half-hour conversation with another developer. We bounced ideas on gRPC, Node.js, C#, React, and Flutter, exploring how they might fit into a project. We didn’t just test skills — we shared perspectives. I walked away having learned something new, and the interviewer got value from my outside experience too.

That’s the kind of interview that measures what senior developers actually do: collaborate, design, and trade ideas.