Back End Developer interview questions and how to answer them
Back end interviews test whether you can reason about data, failure, and trade-offs out loud. Syntax trivia comes up less than people fear. Most rounds want to watch you think through a messy, realistic problem and explain why you'd pick one approach over another.
What happens in each round
- 1
Recruiter screen
What happens
Whether your stack roughly matches theirs, what level you're aiming for, and whether you can describe a recent project in plain words without drowning the recruiter in acronyms.
- 2
Technical phone screen
What happens
A short coding problem in a shared editor, often something with maps, sorting, or parsing. They're watching whether you clarify the input, talk while you code, and test your own solution before calling it done.
- 3
Take-home or live API exercise
What happens
Can you build a small working service: a couple of endpoints, a real data model, validation, error handling, and a few tests. Reviewers read your README and your commit history as closely as the code.
- 4
System design
What happens
How you break a vague product ask into services, storage, and queues, and whether you spot the bottlenecks and failure points yourself before the interviewer points at them.
- 5
Behavioral and team fit
What happens
How you handle incidents, code review disagreements, and on-call pressure. Usually run by an engineering manager who wants specific stories, not general claims.
Questions you're likely to get
1.Walk me through what happens when a request hits one of your API endpoints.
Why they ask
It's a warm-up that shows how deep your mental model goes. Weak candidates stop at the controller. Strong ones mention the load balancer, middleware, the database connection pool, and what gets logged.
How to answer
- Pick a real endpoint from your own work instead of a textbook example
- Trace it through routing, authentication middleware, validation, business logic, and the database call
- Mention where the connection pool, caching, or a queue fits in
- Close with what gets logged or traced so you could debug it later
2.How would you design a REST API for a simple orders system?
Why they ask
They want to see resource naming, status codes, pagination, and how you think about the clients who'll consume it. Small details here reveal whether you've built APIs other teams depend on.
How to answer
- Ask who calls it first: a mobile app, other services, or outside partners
- Lay out resources and verbs, such as listing orders, fetching one, and creating one
- Cover pagination, filtering, and consistent error responses
- Talk about versioning and how you'd change the contract without breaking existing clients
- Mention idempotency keys on order creation so a retried request doesn't charge twice
3.A page that used to load instantly now takes several seconds. How do you find out why?
Why they ask
Slow endpoints are the most common real problem in back end work. This checks whether you debug from evidence or from guesses.
How to answer
- Start with metrics and traces in a tool like Datadog to see where the time goes
- Check whether it's one query, many small queries, or a slow downstream call
- Run EXPLAIN on the suspect query and look for missing indexes or full table scans
- Look at what changed recently: a deploy, a data growth spike, a new feature flag
- Fix, measure again, and add an alert so it's caught earlier next time
4.What's the one-query-per-row problem, and how have you run into it?
Why they ask
ORMs make it easy to fire a separate query for every item in a list. Interviewers want proof you've spotted it in real code, not only read about it.
How to answer
- Explain it plainly: loading a list, then querying related data once per item in a loop
- Describe how you noticed it, such as a trace full of near-identical queries
- Show the fix: eager loading, a join, or a single batched query
- Mention how you'd stop it recurring, such as a query-count check in tests
5.When would you choose a relational database over a document store?
Why they ask
This tests whether you pick storage from the shape of the data and the queries, or from habit and hype.
How to answer
- Tie the choice to access patterns and consistency needs, not preference
- Point out that orders, payments, and inventory usually want transactions and joins
- Give a fair case for a document store, like flexible event payloads or content blobs
- Admit that Postgres with a JSON column covers a lot of the middle ground
6.Two users try to buy the last item in stock at the same moment. What happens in your system?
Why they ask
Concurrency bugs cost real money. They want to hear you reason about transactions, locking, and race conditions without hand-waving.
How to answer
- Name the race: both requests read stock as available before either writes
- Offer fixes such as a row lock, a conditional update, or optimistic locking with a version column
- Explain what the losing user sees and how the client should handle it
- Say how you'd test it, for example by firing parallel requests in an integration test
7.Design a URL shortener, or a notification service, that many users hit at once.
Why they ask
It's the classic system design prompt. They're checking structure and trade-offs more than any single right answer.
How to answer
- Clarify requirements and rough scale before drawing anything
- Sketch the API, the data model, and the read path versus the write path
- Add caching with Redis and a queue for slow work, and say why each earns its place
- Walk through what breaks first under load and how you'd notice
- Name a trade-off you're accepting on purpose
8.How do you handle a call to a third-party API that sometimes times out?
Why they ask
Every back end talks to services it doesn't control. This checks whether you design for failure or just hope.
How to answer
- Set sensible timeouts instead of relying on the library default
- Retry with backoff, but only for requests that are safe to repeat
- Consider a circuit breaker or moving the call onto a queue so users aren't kept waiting
- Log and alert on the failure rate so you know before customers tell you
9.How do you store passwords and protect an API from misuse?
Why they ask
Security basics are non-negotiable for back end roles, and a wrong answer here can end the interview quickly.
How to answer
- Hash passwords with a slow algorithm like bcrypt or scrypt, never plain or reversible encryption
- Use parameterized queries to block SQL injection
- Cover authentication with tokens or sessions and authorization checks on every resource
- Add rate limiting and keep secrets out of the code and logs
10.Tell me about a production incident you were part of.
Why they ask
They want to know how you act under pressure and whether you learn from failure without blaming people.
How to answer
- Set the scene quickly: what broke and who was affected
- Describe what you checked first and how you narrowed it down
- Separate the quick mitigation from the real fix
- Share what changed afterward, like a new alert, a test, or a runbook entry
11.Describe a time you disagreed with a code review comment.
Why they ask
Back end teams review constantly. This shows whether you can defend a choice with evidence and also let go when you're wrong.
How to answer
- Pick a real technical disagreement, not a style nitpick
- Explain how you made your case, such as a benchmark or a link to the docs
- Say how it resolved, including if the reviewer turned out to be right
Mistakes that sink good candidates
Naming tools you can't discuss past the first follow-up question
Designing a system before asking a single question about users or load
Blaming a former teammate or manager for an outage story
Going silent while you code instead of talking through your reasoning
Need more Back End Developer interviews to prep for?
HeroApply applies to Back End Developer jobs that match you, every day. 177 jobs are open today.