"If You Were Building a New API, What Would You Write It In?"
I said "Ruby on Rails" in an interview recently. Out loud. To a hiring manager. In 2026.
He paused. "Ruby, huh?"
And I knew immediately. That wasn't the answer of someone who'd evaluated the landscape and made a deliberate choice. That was muscle memory from 2016. I'd been asked what I'd build a new API in, and instead of thinking about it, I just... answered. Like the last decade of the industry hadn't happened.
I recovered. Took a beat, acknowledged I was reaching for something outdated, and redirected. But the moment stuck with me, because it revealed something I preach to candidates all the time and apparently still need to hear myself: this question is not about your favorite tool. It's about whether you're paying attention.
The shelf life of a good default
Rails was a genuinely good answer for a long time. It was fast to prototype, the conventions were strong, the community was active, and hiring was easy. I built real things in it. I liked building in it. I liked the philosophy behind it, the way it made decisions for you so you could focus on the product instead of the plumbing. And some part of my brain apparently still lives in that era, because when the question came, that's exactly where it went.
But here's the thing about defaults: they age out quietly. The Rails talent pool has been shrinking for years. The ecosystem is aging. New libraries and integrations show up for Node and Python months or years before they show up for Ruby, if they show up at all. And choosing Ruby for a new project in 2026 isn't really a technical decision anymore. It's a hiring constraint. You're limiting your future candidate pool every time you pick a technology, and that cost compounds in ways that don't show up in a sprint planning meeting or a technical spec. It shows up six months later when you're trying to backfill a role and the recruiters keep telling you the pipeline is thin.
PHP went through this. Perl before that. The technology doesn't become useless overnight. It just gradually becomes a liability that gets harder and harder to justify. Ruby is somewhere on that curve right now, and I should have known that in the room instead of having to remind myself mid-sentence.
What I actually think now
If I'm starting something from scratch and the team is flexible, Node.js with TypeScript is where I land for most API work. Type safety across the stack, a massive ecosystem, deep hiring pool, and the ability to share types between backend and frontend if you're in a JS-heavy environment. It's not exciting. It's not contrarian. It's a solid, defensible choice for the majority of use cases, and sometimes that's exactly what you want.
GraphQL enters the conversation when the API has to serve meaningfully different clients. A mobile app, a web dashboard, and an external integration all hitting the same backend but needing different shapes of data. That's where REST starts to buckle and GraphQL earns the complexity it brings with it. But I want to be clear: GraphQL brings real overhead in caching, in error handling, in server-side implementation. I wouldn't reach for it by default. I'd reach for it when REST starts requiring too many specialized endpoints to stay maintainable, and not before.
If the system is high-throughput event processing, the answer is probably Go. If it's data-heavy with a lot of ML integration, Python with FastAPI. If the team already knows C# and lives in Azure, .NET is the right call regardless of what I'd pick in a vacuum. The point is that the answer moves. It should move. And if yours doesn't, if you've been giving the same answer to this question for three or four years without reexamining it... that's worth sitting with.
The real answer is a question
The best thing I could have done in that interview, and what I eventually got to after the Rails stumble, was to ask what the API needed to do before picking anything. "Give me a use case and I'll walk you through how I'd build it." That single reframe does more work than any technology name ever could.
It turns a trivia question into a design conversation. It shows the interviewer you think about context before committing to solutions. And it puts you in a position to demonstrate actual depth instead of just familiarity with a logo.
When I'm on the other side of the table and I ask this question, the best answers I've heard all started with a question back. "What's the scale? Who's the team? What does the data look like?" One candidate said, "If the team already knows Python, I'd lean toward FastAPI because onboarding cost matters more than my personal preference." That one sentence told me more about her engineering judgment than any technology choice would have. Because she wasn't answering the question I asked. She was answering the question behind it, which is: how do you make decisions when the constraints are ambiguous?
The worst answers are the confident ones with no qualifiers. "Go, for everything." "Microservices, obviously." Those tell me the person has strong opinions, which is fine. But they haven't learned when to set those opinions aside, and at the senior level, that matters more than any specific technical skill.
What to take from this
If you're preparing for interviews, pick a current default and know why you'd choose it. Know where it breaks down. And practice the habit of asking a clarifying question before answering technical questions that lack context. That instinct, the reflexive "what problem are we actually solving?" before anything else, is the most reliable signal of engineering maturity I've seen from either side of the table.
And if you catch yourself defaulting to something you haven't critically evaluated in a while, don't panic. Just pause and do the evaluation right there in the room. The interviewer would rather watch you think than hear you recite.