About Backend Software Engineer interviews
Backend Software Engineer interviews are usually multi-stage and heavily weighted toward technical depth. Expect a recruiter screen focused on stack alignment (languages, databases, cloud), followed by a hiring manager conversation that probes engineering judgement, ownership of production systems, and how you collaborate with product and frontend peers. The core of the loop is almost always a technical assessment: a live coding round (data structures, algorithms, or a practical API/service task), one or two system design interviews scaled to your seniority, and sometimes a take-home or pair-programming exercise involving a small service or debugging session. Mid-to-senior candidates can expect a deep-dive on a past system they built — schema choices, scaling decisions, failure modes. A final round typically covers values, cross-functional behaviour, and on-call/incident maturity. Where candidates most often stumble: they treat coding rounds as competitive programming and miss signals around testing, edge cases and code clarity; they jump to a database or queue in system design without clarifying requirements, traffic patterns, or consistency needs; or they describe past projects in vague team terms without owning specific trade-offs they personally made. Strong candidates narrate their thinking, ask sharp clarifying questions, and are honest about what they'd do differently. The bar is usually not 'optimal solution' but 'sound engineer I'd trust with production traffic at 3am.'
Typical stages
- Recruiter screen
- Hiring manager interview
- Live coding round
- System design interview
- Take-home or deep-dive on past project
- Final / values and cross-functional
Common formats
- Behavioral STAR
- Live coding
- System design
- Code review / debugging exercise
- Take-home project
- Past-project deep-dive
What hiring managers screen for
- Clear reasoning about trade-offs in data modelling, consistency, and scale rather than memorised patterns
- Production maturity: testing discipline, observability, error handling, and on-call instincts
- Pragmatic API and service design — clean contracts, backwards compatibility, sensible failure modes
- Ability to collaborate with frontend, product and platform engineers without ego
- Code that is correct, readable and reviewable under time pressure — not just clever
Red flags to avoid
- Reaching for microservices, Kafka or Redis in system design without justifying the need
- Writing code with no tests, no input validation, and no thought to edge cases
- Inability to explain why a past architectural choice was made, or blaming 'the team' for decisions
- Treating databases as black boxes — no view on indexes, transactions, or query plans
- Dismissing operational concerns like logging, metrics, deployment or rollback as 'someone else's job'
Primary questions (14)
Behavioural
Tell me about a backend system or service you owned end-to-end. What were the key technical decisions you made and why?
Why this comes up: Hiring managers use this to verify genuine ownership versus passive contribution on someone else's design.
Prep pointers
- Pick a system where YOU made the design calls — not one you joined late. Be ready to name specific trade-offs you personally weighed.
- STAR Situation: scope the system's purpose and scale (users, RPS, data volume). Task: clarify what was uniquely yours vs the team's. Action: walk through 2-3 concrete decisions (e.g. choice of datastore, sync vs async, schema shape) with the alternatives you rejected. Result: quantified outcome plus what you'd change today.
- Avoid narrating the happy path only — interviewers want to hear what broke or what you got wrong.
- Have a clean architecture sketch ready in your head; you may be asked to whiteboard it.
Technical
Design a URL shortener that handles 10,000 writes per second and 100,000 reads per second with low latency globally.
Why this comes up: It's a canonical system design prompt that quickly reveals depth across hashing, storage, caching and geo-distribution.
Prep pointers
- Start with clarifying questions: read/write ratio, link lifetime, custom aliases, analytics needs, latency SLOs per region.
- Drive the conversation through: API contract → key generation strategy (counter vs hash vs base62) → storage choice and schema → caching layer → read path vs write path → geo-replication and consistency model.
- Be explicit about trade-offs: strong vs eventual consistency for redirects, hot key handling, collision strategies.
- Don't forget the boring bits: rate limiting, abuse prevention, monitoring, and how you'd roll out a schema change.
- Senior candidates: discuss capacity estimation with real numbers (storage growth, cache sizing, bandwidth).
Technical
Walk me through how you would diagnose a production API endpoint whose p99 latency has suddenly jumped from 80ms to 1.2 seconds.
Why this comes up: Tests real on-call reasoning and whether the candidate has actually debugged production systems versus only built them.
Prep pointers
- Structure the answer as a hypothesis tree, not a checklist: what changed (deploy, traffic, dependency), where time is being spent (app, DB, downstream), and who is affected (all users or a segment).
- Reference specific tools you'd reach for: APM traces, slow query logs, flame graphs, dashboards for DB connection pool saturation, GC pauses, etc.
- Mention how you'd protect users while investigating — feature flag, rollback, circuit breaker, scaling out — before deep-diving on root cause.
- Show you separate symptom from cause: a slow query might be the symptom of a missing index, a noisy neighbour, or a runaway N+1.
- Avoid jumping to 'add a cache' as a diagnosis.
Technical
You have a relational database table with 500 million rows and a query that has become unacceptably slow. How do you approach fixing it without downtime?
Why this comes up: Backend engineers are expected to be fluent with database internals, not just ORM usage.
Prep pointers
- Begin with EXPLAIN/EXPLAIN ANALYZE — show you reason from the query plan, not guesses.
- Cover the toolbox: indexes (and their cost on writes), query rewrites, denormalisation, partitioning, read replicas, materialised views, archival of cold data.
- Discuss online schema change tools (pt-online-schema-change, gh-ost, or native concurrent index builds) for the 'no downtime' part.
- Talk about how you'd validate the fix safely: shadow queries, canary deploys, and rollback if regressions appear.
- Acknowledge when the answer is 'this query shouldn't be hitting the primary DB at all' — sometimes the fix is architectural.
Behavioural
Describe a time you disagreed with a teammate or tech lead about a technical approach. How did it play out?
Why this comes up: Backend teams need engineers who can push back constructively without becoming blockers or bystanders.
Prep pointers
- Choose a real disagreement with substance — a library choice is too thin; an architectural or data-modelling debate works better.
- STAR Action should show: how you steelmanned the other view, what evidence or prototype you brought, and how the decision was actually made.
- Be willing to share an example where you were overruled and the team was right — humility scores well here.
- Avoid framing the story as 'I was right and they finally saw it' — interviewers screen for collaboration, not victory.
Technical
How would you design an idempotent payment-processing API that must never double-charge a customer, even under retries and network failures?
Why this comes up: Idempotency, exactly-once semantics and distributed failure modes are bread-and-butter backend concerns at any company handling money or critical state.
Prep pointers
- Lead with the idempotency key pattern: client-supplied key, server-side dedupe table, TTL considerations.
- Distinguish at-least-once delivery from exactly-once processing — make it clear true exactly-once doesn't exist, you build idempotent consumers.
- Address the hard cases: what if the original request is still in-flight when the retry arrives? Locking, status records, and request-fingerprint comparison.
- Cover the failure surfaces: DB write succeeds but response is lost, downstream PSP times out, partial commits across services.
- Mention auditability — every charge attempt should be traceable end-to-end.
Situational
Two days before a major launch, you discover a data-integrity bug in code that's already in production. What do you do?
Why this comes up: Tests judgement under pressure and whether the candidate balances engineering rigour with business reality.
Prep pointers
- Show a decision framework: blast radius, reversibility, who needs to know, and what 'good enough for launch' looks like.
- Walk through immediate actions: stop the bleeding (feature flag, write-path disable), assess data damage, communicate to stakeholders.
- Distinguish the fix from the cleanup — patching code vs reconciling corrupted data are different workstreams.
- Acknowledge the human element: pulling in the right people, not heroically solo-fixing at 2am.
- Avoid extremes — neither 'always delay the launch' nor 'ship it and fix later' is a good answer without conditions.
Competency
How do you decide what to test, and at what level — unit, integration, or end-to-end — for a new backend service?
Why this comes up: Testing philosophy is a strong proxy for engineering maturity and how much pain a candidate has lived through in production.
Prep pointers
- Reference the testing pyramid but be ready to defend deviations — some teams reasonably invert it for service-heavy architectures.
- Talk about what you don't test: trivial getters, framework code, third-party libraries.
- Cover contract testing for service boundaries, and how you'd test against real dependencies (Testcontainers, ephemeral environments) vs mocks.
- Mention test data strategy, flakiness management, and how tests gate deployment.
- Be specific about a time test investment paid off — or a time it didn't.
Behavioural
Tell me about a time you introduced or championed a significant technical improvement — a refactor, a new framework, a migration. How did you get buy-in and measure success?
Why this comes up: Differentiates engineers who execute tickets from those who actively improve the codebase and influence the team.
Prep pointers
- Pick an example with measurable impact (latency, error rate, deploy frequency, developer time saved) — vague 'cleaner code' stories underperform.
- STAR Action should cover: how you built the case (data, prototype, proposal doc), how you de-risked it (incremental migration, dual-writes, feature flags), and how you brought others along.
- Be honest about cost: how long it took, what you broke en route, what slipped because of it.
- Avoid framing yourself as the lone hero — strong stories show enrolment of teammates and leadership.
Situational
A product manager asks you to add a 'simple' feature that you can see will create significant technical debt. How do you handle the conversation?
Why this comes up: Backend engineers must defend long-term system health without becoming the 'no' person, especially on cross-functional teams.
Prep pointers
- Show you understand the PM's pressures — frame it as collaborative problem-solving, not gate-keeping.
- Quantify the debt in terms PMs care about: future velocity, on-call load, incident risk, customer impact.
- Offer options, not vetoes: minimal version now + proper version later, time-boxed spike, or trade against another item.
- Mention writing it down — a short ADR or tech-debt ticket creates a paper trail.
- Avoid sounding precious about code quality for its own sake.
Competency
How do you approach observability for a new service — logging, metrics, tracing, alerting? What does 'good' look like?
Why this comes up: Reveals whether a candidate has been on-call for systems they've built, or only handed them off.
Prep pointers
- Distinguish the three pillars and what each is for: logs (forensic), metrics (aggregate health), traces (request-path latency attribution).
- Discuss what you instrument by default: RED or USE metrics, business KPIs, dependency health, saturation signals.
- Be opinionated about alerting: alerts should be actionable, page-worthy, and tied to user-facing SLOs — not CPU thresholds.
- Mention log levels, structured logging, PII handling, and retention costs.
- Have an example of an outage where observability either saved you or failed you.
Behavioural
Tell me about the worst production incident you were involved in. What was your role and what did you learn?
Why this comes up: Senior backend hiring almost always probes incident response — it shows maturity, accountability and learning behaviour.
Prep pointers
- Pick a real, meaningful incident — customer-impacting, ideally with a postmortem you contributed to.
- STAR Action should separate detection, mitigation, and root cause — these are different phases with different decisions.
- Take ownership without scapegoating. 'A teammate pushed bad code' is weak; 'our deployment pipeline allowed an untested config change' is strong.
- Be explicit about the systemic changes that resulted — runbook, alert, test, architectural fix.
- Avoid stories where you were a passive observer.
Culture fit
What kind of engineering culture do you do your best work in, and what kind drains you?
Why this comes up: Helps both sides assess whether the team's pace, autonomy and review norms will be a fit — and prevents short tenures.
Prep pointers
- Be honest rather than strategic — bad fit hurts you more than the company.
- Have concrete examples: 'I work best when...' followed by a real situation, and similarly for what doesn't work.
- Touch on a few axes: autonomy vs structure, async vs sync, code review depth, on-call expectations, shipping cadence.
- Avoid criticising past employers harshly — describe environments, not villains.
- Have a thoughtful question ready about their actual engineering culture, not just the marketing version.
Competency
Walk me through how you'd review a pull request from a junior engineer that 'works' but isn't quite right.
Why this comes up: Code review behaviour is a strong indicator of how a candidate will raise (or lower) the bar across a team.
Prep pointers
- Distinguish must-fix issues (correctness, security, data integrity) from preferences (style, naming) — and review them differently.
- Show you separate the code from the coder: comments should critique the change, not the person.
- Talk about teaching moments — linking to docs, suggesting alternatives, pairing offline rather than leaving 20 nitpick comments.
- Mention when you'd pull the PR offline for a synchronous conversation instead of escalating in writing.
- Be ready to give a specific example of feedback that landed well, and one that didn't.
More practice questions (15)
Technical
Explain the differences between optimistic and pessimistic concurrency control. When would you use each?
Why this comes up: Concurrency handling comes up constantly in backend work and quickly separates surface-level from deeper candidates.
Technical
When would you choose a message queue over direct service-to-service HTTP calls?
Why this comes up: Tests judgement about async architectures versus reflexive over-engineering.
Technical
Implement a function that finds the top K most frequent elements in a stream of data. Discuss space and time complexity.
Why this comes up: A standard live-coding prompt that touches data structures, complexity analysis and streaming considerations.
Technical
Explain what happens, step by step, when a client sends an HTTPS request to your backend service running behind a load balancer.
Why this comes up: Reveals depth of understanding across networking, TLS, load balancing, and request lifecycle.
Technical
How do database indexes work, and why can adding more indexes hurt performance?
Why this comes up: Fundamental DB knowledge that backend engineers are routinely expected to demonstrate.
Technical
Describe how you'd implement rate limiting for a public API. What algorithm would you choose and why?
Why this comes up: Common design sub-problem that tests both algorithm choice (token bucket, leaky bucket, sliding window) and distributed-systems thinking.
Behavioural
Tell me about a time you had to learn a new technology or language quickly to deliver something. How did you approach it?
Why this comes up: Stacks change; hiring managers want evidence you can ramp up without hand-holding.
Behavioural
Describe a piece of code or a system you're particularly proud of. What makes it good?
Why this comes up: Reveals taste, standards, and what the candidate considers excellent engineering.
Behavioural
Tell me about a project that was late or failed. What happened?
Why this comes up: Standard probe for accountability, retrospection, and ability to operate in messy real-world conditions.
Situational
Your service depends on a third-party API that has just started returning intermittent 5xx errors. What do you do, in what order?
Why this comes up: Tests resilience patterns (retries, backoff, circuit breakers) and communication under partial failure.
Situational
You inherit a legacy service with no tests, sparse documentation, and frequent incidents. Where do you start?
Why this comes up: Many backend roles involve modernising existing systems rather than greenfield work — interviewers want to see a pragmatic plan.
Competency
How do you balance shipping quickly with maintaining code quality?
Why this comes up: A frequently-asked judgement question; weak candidates give clichéd answers, strong ones show context-dependent thinking.
Competency
What does a well-designed REST or RPC API look like to you?
Why this comes up: API design is a daily backend activity and a strong signal of attention to consumers and long-term maintainability.
Culture fit
Why this company, and why this team specifically?
Why this comes up: Standard but high-weight question — generic answers signal lack of genuine interest or prep.
Culture fit
How do you stay current with backend engineering — languages, frameworks, distributed systems thinking?
Why this comes up: Helps assess curiosity and self-driven growth, which most engineering cultures explicitly value.
Get a prep pack tailored to your experience
describe.me matches these questions against your real work history,
flags your prep priorities, and gives you a STAR scaffold per question.
Start free →