Use this guide to interview a Senior Backend Engineer. At the senior level the bar is not harder trivia — it is owning systems in production, reasoning about partial failure by default, and raising the level of the engineers around them. Pick eight to twelve questions per session, keep the set consistent across candidates, and push every design answer toward real constraints from {{Your product or domain}}.

API and service design

• Walk me through designing a public API third parties will build on. What must be right on day one because it can never change?
• How do you split a service that has grown too large? Which boundaries do you look for, and which apparent boundaries are traps?
• Contract-first versus code-first API development — what have you practiced, and what did each cost?
• How do you evolve an event schema that consumers already depend on?
• When is gRPC, REST, or async messaging the right interface between internal services?

Data and storage

• How do you choose a primary datastore for a new service? Walk me through a real decision, including the options you rejected.
• Explain transaction isolation levels and a concrete bug you have seen from getting them wrong.
• Design a zero-downtime migration that changes the shape of a heavily written table.
• How do you scale past a single database? Replicas, sharding, CQRS — where does each approach break?
• Tell me about a data-corruption or data-loss incident you handled. What was the root cause, and what changed?

Distributed systems and reliability

• Two services must update state consistently without a shared database. What are your options and their costs?
• Explain idempotency in a payment-like flow. How do you build it end to end?
• What happens when a downstream dependency slows to a crawl but does not fail? How do you defend against it?
• How do you design retries so they do not become a self-inflicted denial of service?
• Design a rate limiter for a multi-tenant API. Where does its state live?
• Walk me through an outage where you were incident lead: detection, mitigation, and what changed afterward.
• How do you set and use SLOs? When has an error budget actually changed a roadmap decision?

What good looks like: senior candidates reason about partial failure without being prompted — backpressure, circuit breakers, jittered retries, deduplication keys, and timeouts appear naturally in their designs. Incident stories should end in systemic fixes such as alerts, runbooks, or architectural changes, not hero debugging, and SLO answers should show error budgets driving real prioritization.

Security and operations

• How do you handle secrets across services, and what breaks the first time you rotate them?
• Where do authorization checks live in your services, and how do you prevent the missed-check class of bug?
• What telemetry is mandatory before a service ships? Which questions must logs, metrics, and traces be able to answer?
• How do you make deployments boring? Describe the pipeline you would build from scratch.
• A dependency announces a critical vulnerability. Walk me through your response.

Technical leadership and mentorship

• How do you run a design review that actually improves the design instead of performing status?
• Tell me about growing a mid-level engineer into a senior one. What did you concretely do?
• How do you handle a strong engineer who consistently ships code only they can maintain?
• Rewrite versus refactor: tell me about a time you argued against a rewrite — or for one — and what happened.
• How do you keep an on-call rotation humane and still effective?

What good looks like: look for evidence the candidate raises the level of people and systems around them — reusable review practices, documentation that outlived them, engineers they developed who now lead. Mentorship answers should name specific actions and outcomes, not generic philosophy about helping others grow.

Judgment and ambiguity

• What is the most over-engineered thing you have built, and how would you build it today?
• How do you make progress when requirements are genuinely unclear and stakeholders disagree?
• Which strongly held backend belief have you changed in the last few years, and why?