In short
Tracy AI Interviewer interviews every backend candidate in their own field and follows up on design trade-offs, so you see how they reason, not only which tools they have used.
Use the 15 backend developer interview questions below, each with a follow-up and what to listen for.
Every result keeps a recording, a timestamped transcript and a written assessment per question; your engineers decide.
Next step: paste three of these questions into a Tracy interview.
We make Tracy AI Interviewer.
You open a backend role and 200 applications arrive. Most list the same stack, and the CV cannot tell you who has run a service under load and who has read about it. Backend developer interview questions have to find that gap, so ask what they did when their queue backed up.
These 15 backend developer interview questions are written for engineering managers and recruiters hiring mid-level to senior backend developers. Each has a follow-up and a note on what a strong answer contains. They suit a first technical conversation of 20 to 30 minutes; deep architecture and coding belong to a later round with your own engineers.
Tracy AI Interviewer runs that first conversation at volume. She asks each candidate in their own field, follows up on what they just said and waits for the end of the thought. For the wider process, see technical interviews, and for general engineering questions, software engineer interview questions.
Fifteen backend developer interview questions, grouped by what they test
Pick one or two from each group. Ask the follow-up only after the first answer. Choose your opening questions for the role and write down what a strong answer contains before the first candidate joins.
Group 1: APIs and failure
1. A payment request times out. How do you decide whether to retry it?
- Follow up with
- What makes the call safe to repeat, and where do you record that?
- Listen for
- Backoff, a request key, idempotency. Names what a duplicate would cost.
2. How do you design an API change that existing clients must survive?
- Follow up with
- What do you do when one client cannot upgrade for a quarter?
- Listen for
- Versioning, deprecation notice, additive changes. A real client they had to protect.
3. A downstream service is slow, not down. What happens to yours?
- Follow up with
- How would you find out it is happening before users do?
- Listen for
- Timeouts, circuit breakers, queues filling. Metrics they would watch, not a general "monitoring".
Group 2: data and storage
4. Walk me through how you chose a database for your last service.
- Follow up with
- What did the choice make harder?
- Listen for
- A trade-off named without prompting. Consistency, query shape, operations, cost.
5. A query that took 50 ms now takes 4 seconds. What do you do first?
- Follow up with
- What if the plan has not changed?
- Listen for
- Reads the plan, checks indexes and data growth, then locks and load. Measures before changing.
6. How do you change a column on a table with millions of rows without downtime?
- Follow up with
- What do you do if the migration fails halfway?
- Listen for
- Expand and contract, backfill in batches, a way back. Has done it.
Group 3: design trade-offs
7. When would you add a cache, and when would you refuse to?
- Follow up with
- What goes wrong when it serves stale data?
- Listen for
- Invalidation as the real cost. Says when correctness matters more than speed.
8. Design a rate limiter for a public API. What do you ask before drawing anything?
- Follow up with
- How does it behave across several servers?
- Listen for
- Asks who is limited, burst rules, failure mode. Counter versus window, and the cost of each.
9. Where would you use a queue instead of a direct call?
- Follow up with
- How do you handle a message that always fails?
- Listen for
- Decoupling, retries, dead-letter handling, ordering. Knows delivery is not exactly-once by default.
Group 4: production and debugging
10. Tell me about the last incident you helped fix.
- Follow up with
- What would have caught it earlier?
- Listen for
- A specific timeline, their own role, a change they made afterwards.
11. Memory use climbs for a week, then the service restarts. How do you investigate?
- Follow up with
- How do you tell a leak from normal growth?
- Listen for
- Heap profiles, comparing builds, load patterns. Does not guess.
12. What do you log, and what do you never log?
- Follow up with
- How would you trace one request across three services?
- Listen for
- Request ids, structured logs, no secrets or personal data. Has used tracing.
Group 5: working with others
13. Describe a review where you pushed back on a design.
- Follow up with
- Were you right?
- Listen for
- Gives their reasoning and how it ended, including being wrong.
14. How do you decide something is ready to ship?
- Follow up with
- What do you do when the deadline says ship and your tests say no?
- Listen for
- Checks, rollout plan, a way to turn it off. Says it to the team early.
15. What have you stopped doing in the last two years?
- Follow up with
- Why?
- Listen for
- Something specific and a reason they changed their mind.
A strong answer names what it would check, and a weak one names the tool
Listen to the second answer, where the two diverge. We wrote these pairs to show how it sounds; none is a quote from a real candidate.
Table 6: Weak and strong answers to the same questions, written as examples.
| Weak answer | Strong answer | |
|---|---|---|
| Question 1, the timeout | "I'd add a retry with backoff." | "Backoff, but only if the call is safe to repeat. For a payment I'd send a request key so a second attempt returns the first result." |
| Question 5, the slow query | "I'd add an index." | "I'd read the plan first. If the data grew, an index may help. If it did not change, I'd look at locks and concurrent load." |
| Question 10, the incident | "The team fixed it quickly." | "I found it was a missing timeout. I added it, then added an alert on queue depth so we'd see it before users." |
Listen for ownership. "We" tells you about the team. "I checked this, and this is what I do now" tells you about the person.
One follow-up chain shows where the real answer starts
This is an illustration with sample data, not a real interview. The candidate is fictional. It shows the shape of what Tracy runs: an opening question from your list, the answer, and a follow-up built on it. It starts from question 1.
Tracy: A payment request times out. How do you decide whether to retry it?
Candidate (fictional): I retry with backoff, but only if the call is safe to repeat.
Tracy: What makes this call safe to repeat, and where would you store that?
Candidate: The client sends a request key. The server stores it with the result and returns the same result on a repeat.
Tracy: What happens if two requests with the same key arrive together?
Candidate: The second should wait or fail on a unique constraint, not run the payment twice.
The first answer is the one in every tutorial. By the third, you can hear whether the candidate has built it.
A follow-up on the candidate's own answer separates having read about retries from having built them.
Run the technical interview for every applicant
A live call for every applicant does not survive 200 applications.
- Your questions or ours. Describe the role and Tracy drafts questions from the job description, which you edit; see the product page.
- A task inside the interview. Live coding, SQL, debugging or multiple choice can sit in the same interview, with follow-ups on approach and trade-offs. See AI technical interviews.
- CV check, as a setting. With it on, Tracy can read the CV and ask about what it claims.
- Start on click. Each candidate opens a link in a browser, with no account and no calendar, at any hour. They are told on the join screen that the conversation is recorded and transcribed. See the participant experience.
- A result you can check. A recording and a timestamped transcript sit behind every result, with a written assessment per question. See AI interview reports.
- Integrity signals, with the evidence. Tracy captures tab changes, gaze, face detection, delay before answers, fullscreen exits and external screens and shows the evidence to a person. A signal is not proof.
It is $1 per credit, one credit per started 20 minutes of an interview that produced a result. The first 3 results are free with no card, and there are no seats. See pricing.
Your engineers can open the recording and transcript behind each assessment before they decide.
Keep three decisions with your engineers
- Who moves forward. A senior backend engineer reads the report and decides. Tracy ranks and flags; a person has the last word.
- The calibration. Have one of your engineers read five transcripts blind. If they disagree with the written assessments, change the questions before inviting the next hundred.
- The deep round. Architecture whiteboarding and pairing stay with your team.
For five hires a quarter, a call with your own engineer is simpler and probably better; see AI interview vs human interview. The case for Tracy starts when applicants outnumber your engineers' hours, as in volume hiring. To try it, put three of these questions into one open backend role, send the link to your next batch of applicants and have an engineer read what comes back.
Common questions
What are good backend developer interview questions?
What backend developer interview questions suit experienced engineers?
How do you interview a backend developer without a live call?
Can Tracy include a coding or SQL task?
Does Tracy decide who to hire?
Try Tracy on your next role
Tracy interviews every applicant, asks follow-up questions and sends you a ranked shortlist.
Try it free (opens in a new tab) Book a demo (opens in a new tab)
Your first 3 results are free. No card needed.
Sources
- Tracy AI Interviewer home page, retrieved 9 Nov 2026.
- Tracy AI Interviewer pricing, retrieved 9 Nov 2026.
- Tracy AI Interviewer Connect page, retrieved 9 Nov 2026.
