You're forty minutes into a backend interview and the candidate has named every technology on your job post. Node, PostgreSQL, Redis, Docker. You still don't know whether they can build the thing you need built.
A stack list is the easiest part of an interview to prepare for. What's harder to fake is why any of it was chosen, what it cost and what happened when it broke. That's where your interview time should go.
Ask why, not what
A weaker candidate tells you they used Redis. A stronger one tells you they put Redis in front of a query that was being requested constantly and didn't need recalculating every time, and that they accepted eventual consistency because the business never needed the number to be perfectly current.
Same technology, completely different signal. Listen for tradeoffs, constraints and consequences arriving unprompted. Candidates who think that way in an interview tend to keep doing it in your codebase.
Backend work is mostly data work, so push on it. Ask what they'd do when an API that was fast at ten thousand rows crawls at ten million, and listen for query plans, indexes, N+1 queries, pagination and connection pools rather than one tidy answer. You're testing whether they can investigate a database problem, not whether they've memorized the fix.
Then ask what happens when it fails. Good backend developers do this automatically: an API call makes them think about timeouts, a queue makes them think about duplicate messages, a cache makes them think about stale data. If failure never comes up on its own, that's your answer.
Skip the algorithm puzzle and hand them something that looks like your actual work.
Tell them a customer clicks Pay and the payment provider takes eight seconds to answer, then ask how they'd design the backend around it. Watch for idempotency, retries, timeouts, duplicate charges, webhooks, queues and the failure states in between. Follow it with a debugging prompt: an endpoint that normally answers in 200ms is taking eight seconds today, walk me through it. What you want is a method rather than a guess, something like reproduce, observe, narrow, find the root cause, fix, verify. Engineers who write code and engineers who can find problems in code they didn't write aren't always the same person, and you're hiring for the second one too.
Production is the other thing local development hides. Ask what they do when they deploy a change and five minutes later the error rate jumps from 0.2% to 15%. Logging, metrics, alerts, rollbacks and a calm order of operations tell you they've operated something real, not just built it.
Judgment shows up in hindsight
Ask about something they actually built
Ask them about the most complex system they’ve built. Dig into what they owned, what broke, how they fixed it, and what they’d change today. That last answer often reveals real engineering judgment, not just technical knowledge.
Score the same areas every time: readable code, data and performance, system design, debugging, reliability, security, production experience, communication, ownership and judgment. Someone comfortable in Python and SQL can get productive in Laravel faster than an incurious specialist can learn to think.
Communication belongs on that list too. The best backend developer on your team is the one who can tell a non-technical colleague that orders aren't being lost, they're just slow because the payment provider is slow. At eComia we look for the same things when we build teams around a real stack: judgment first, frameworks second.