Backend Engineer interview questions
Backend interviews test whether you can be trusted with data that has to stay correct. Expect a coding round, a system design round that leans on databases and failure, and at least one conversation about something that broke on your watch. Here's what each question is really checking and how to answer it well.
What happens in each round
- 1
Recruiter screen
What happens
Whether your languages and stack roughly match theirs, whether you've worked on services that ran in production, and what you're looking for next. Have a short story ready about a service you owned.
- 2
Technical phone screen
What happens
A coding problem in a shared editor, often with a data-handling twist like parsing records or merging sorted results. They're watching whether you talk through edge cases like empty input, duplicates and bad data before you type.
- 3
System design
What happens
How you'd build a real service end to end: the API, the data model, where it caches, how it scales and what happens when a dependency is down. Senior candidates get judged mostly here.
- 4
Code review or debugging exercise
What happens
Some teams hand you a pull request or a failing service and ask what's wrong. It checks whether you spot race conditions, missing indexes and unsafe migrations the way a good reviewer would.
- 5
Behavioral and team fit
What happens
How you handle incidents, disagreements over design and on-call pressure. The hiring manager wants to know if you'll write the postmortem or disappear after the fix.
Questions you're likely to get
1.Design a URL shortener, then tell me what breaks first when traffic grows a lot.
Why they ask
It's small enough to finish in the time and wide enough to show how you think about storage, reads versus writes, and caching.
How to answer
- Clarify the requirements first: custom links or not, expiry, analytics, how long links must live
- Sketch the API and a simple table keyed by the short code
- Point out the traffic is mostly reads and put a cache such as Redis in front of the database
- Explain how you'd generate codes without collisions across several servers
- Name the first bottleneck honestly and how you'd notice it on a dashboard
2.A page that used to load quickly is now slow. The code didn't change. How do you find out why?
Why they ask
Performance problems in backend work usually come from data growing, not code changing. They want to see a calm, ordered way of narrowing it down.
How to answer
- Start with metrics and traces to find which call got slower
- Check the database: run EXPLAIN on the query and look for a missing index or a full table scan
- Ask what changed in the data, such as one customer with far more rows than anyone else
- Look for one-query-per-item loops that only hurt at larger sizes
- Fix the cause, then add an alert or test so it doesn't come back quietly
3.How would you add a column to a large, busy table without downtime?
Why they ask
Schema changes are where backend engineers cause outages. This separates people who've run migrations in production from people who've only run them locally.
How to answer
- Add the column as nullable or with a cheap default so the change doesn't lock the table
- Backfill existing rows in small batches and watch database load while it runs
- Deploy code that writes the new column before code that depends on reading it
- Only add constraints once every row is filled
- Mention how you'd roll back if the backfill goes wrong
4.What does idempotent mean, and where have you needed it?
Why they ask
Retries, queues and flaky networks mean the same request will arrive twice. Payment and order systems live or die on this.
How to answer
- Define it plainly: doing the same operation twice leaves things as if you'd done it once
- Give a real example like a charge, an email or a webhook handler
- Explain an idempotency key stored with a unique constraint
- Mention message queues that deliver at least once and how your consumer copes
5.When would you pick a relational database over a document or key-value store?
Why they ask
They want to know you choose storage from the shape of the data and the questions you'll ask of it, not from habit or hype.
How to answer
- Say relational is the sensible default when data has relationships and you need transactions
- Describe a case where a key-value store fits, like sessions or a cache
- Talk about how you'll query the data later, since that decides more than how you store it
- Admit the cost of running two kinds of database on a small team
6.Walk me through what happens when two requests try to update the same record at the same moment.
Why they ask
Race conditions are the classic backend bug that never shows up in testing. They're checking whether you've met one.
How to answer
- Describe the lost update: both read the old value, both write, one change disappears
- Explain row locks with SELECT FOR UPDATE and when they're worth the cost
- Offer optimistic locking with a version column as the lighter option
- Mention doing the math inside a single UPDATE statement when you can
7.How do you design an API that other teams will depend on?
Why they ask
Once mobile apps and partners call your endpoint, you can't change it freely. They want to see you think about the people on the other end.
How to answer
- Start from what the caller needs, not how your tables look
- Use consistent errors, pagination and naming across endpoints
- Plan for change by adding fields instead of renaming them and versioning when you must
- Write the contract down with OpenAPI or similar before building
- Mention auth, rate limits and what happens when a caller misbehaves
8.Tell me about an outage or incident you were part of.
Why they ask
Every backend engineer breaks production at some point. They care about how you found it, how you fixed it and what changed afterward.
How to answer
- Set the scene briefly: what service, what users saw
- Explain how it was detected and what you checked first
- Say what you did to stop the damage before finding the root cause
- Describe the lasting fix and the postmortem, without blaming anyone
9.A downstream service you call is timing out. What should your service do?
Why they ask
Backend systems fail in chains. They want to see that your code protects itself and its callers.
How to answer
- Set a sensible timeout instead of waiting forever
- Retry only safe requests, with backoff and jitter so you don't pile on
- Mention a circuit breaker to stop hammering a service that's already down
- Decide what the user gets meanwhile: cached data, a partial answer or a clear error
10.How do you decide what to test in a service, and how?
Why they ask
Backend tests that fake the database can pass while production fails. They're checking whether you know where the real bugs hide.
How to answer
- Unit tests for business rules that don't need I/O
- Integration tests against a real database, often in a Docker container
- Contract tests or at least a smoke test for the APIs other teams rely on
- Say what you don't test and why, so it's clear you're choosing, not skipping
11.Tell me about a time you disagreed with a design decision.
Why they ask
Design arguments are a normal part of backend work. They want someone who argues with evidence and then commits.
How to answer
- Name the decision and your concern in concrete terms
- Explain how you made the case, such as a quick benchmark or a written proposal
- Share how it ended, including if you lost
- Say what you learned about raising the next disagreement
Mistakes that sink good candidates
Naming every tool you've heard of in the design round without explaining why each one is there
Skipping failure cases, since backend interviewers will ask what happens when the database or a dependency goes down
Talking badly about a past team when you describe an outage
Writing code in the screen without saying a word about duplicates, empty input or bad data
Need more Backend Engineer interviews to prep for?
HeroApply applies to Backend Engineer jobs that match you, every day. 986 jobs are open today.