# Backend Developer Interview Questions for Hiring Teams

> Backend developer interview questions for hiring teams: 15 questions with follow-ups, strong and weak answers, and how to run them at volume.

- URL: https://tracyinterview.ai/blog/backend-developer-interview-questions
- Published: 2026-11-11
- Author: Tracy team

> **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](/use-cases/technical-interviews), and for general engineering questions, [software engineer interview questions](/blog/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

*Table 1: APIs and failure, with follow-ups and what a strong answer contains.*

| Ask | Follow up with | Listen for |
| --- | --- | --- |
| 1. A payment request times out. How do you decide whether to retry it? | What makes the call safe to repeat, and where do you record that? | Backoff, a request key, idempotency. Names what a duplicate would cost. |
| 2. How do you design an API change that existing clients must survive? | What do you do when one client cannot upgrade for a quarter? | Versioning, deprecation notice, additive changes. A real client they had to protect. |
| 3. A downstream service is slow, not down. What happens to yours? | How would you find out it is happening before users do? | Timeouts, circuit breakers, queues filling. Metrics they would watch, not a general "monitoring". |

### Group 2: data and storage

*Table 2: Data and storage, with follow-ups and what a strong answer contains.*

| Ask | Follow up with | Listen for |
| --- | --- | --- |
| 4. Walk me through how you chose a database for your last service. | What did the choice make harder? | 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? | What if the plan has not changed? | 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? | What do you do if the migration fails halfway? | Expand and contract, backfill in batches, a way back. Has done it. |

### Group 3: design trade-offs

*Table 3: Design trade-offs, with follow-ups and what a strong answer contains.*

| Ask | Follow up with | Listen for |
| --- | --- | --- |
| 7. When would you add a cache, and when would you refuse to? | What goes wrong when it serves stale data? | 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? | How does it behave across several servers? | 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? | How do you handle a message that always fails? | Decoupling, retries, dead-letter handling, ordering. Knows delivery is not exactly-once by default. |

### Group 4: production and debugging

*Table 4: Production and debugging, with follow-ups and what a strong answer contains.*

| Ask | Follow up with | Listen for |
| --- | --- | --- |
| 10. Tell me about the last incident you helped fix. | What would have caught it earlier? | 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? | How do you tell a leak from normal growth? | Heap profiles, comparing builds, load patterns. Does not guess. |
| 12. What do you log, and what do you never log? | How would you trace one request across three services? | Request ids, structured logs, no secrets or personal data. Has used tracing. |

### Group 5: working with others

*Table 5: Working with others, with follow-ups and what a strong answer contains.*

| Ask | Follow up with | Listen for |
| --- | --- | --- |
| 13. Describe a review where you pushed back on a design. | Were you right? | Gives their reasoning and how it ended, including being wrong. |
| 14. How do you decide something is ready to ship? | What do you do when the deadline says ship and your tests say no? | 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? | Why? | 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.

![Transcript card: a payment times out, candidate says retry with backoff, Tracy asks what makes the call safe to repeat.](/blog/images/backend-developer-interview-questions-1.png)

*Tracy asks a follow-up built on the candidate's own answer. Your engineers hear whether the candidate has built it. Illustration with sample data*

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](/product).
- **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](/blog/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](/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](/blog/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](/pricing).

![Tracy result for a fictional backend developer: four assessments and a highlighted 12:17 transcript answer.](/blog/images/backend-developer-interview-questions-2.png)

*A recording and timestamped transcript sit behind every Tracy result. The engineer who reads it checks the evidence before moving a candidate forward. Illustration with sample data*

Your engineers can open the recording and transcript behind each assessment before they decide.

## Keep three decisions with your engineers

1. **Who moves forward.** A senior backend engineer reads the report and decides. Tracy ranks and flags; a person has the last word.
2. **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.
3. **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](/blog/ai-interview-vs-human-interview). The case for Tracy starts when applicants outnumber your engineers' hours, as in [volume hiring](/use-cases/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?

Ask about failure handling, data and storage, design trade-offs, production debugging and working with others. Pick one or two from each group and keep the follow-up beside each, because the follow-up is where the real answer starts.

### What backend developer interview questions suit experienced engineers?

Use the design trade-off and production groups. Experienced candidates should name what a choice made harder and describe an incident with a timeline and their own part in it.

### How do you interview a backend developer without a live call?

Run a structured first-round interview: Tracy asks in the candidate's field, follows up on what they said and returns a recording, transcript and assessment per question for your engineers to review.

### Can Tracy include a coding or SQL task?

Yes. A coding task, SQL, debugging or multiple choice can sit inside the same interview, with follow-ups on approach and trade-offs.

### Does Tracy decide who to hire?

No. A person reads the evidence and decides.

---

Create an interview for this exact role from these questions, then read the recording and report; the button opens the Connect page. Or send us one role and we will build the interview plan, with a recording and report you can check. [Try it free](https://tracyinterview.ai/connect?utm_source=blog&utm_medium=seo&utm_campaign=backend-developer-interview-questions&utm_content=try-free) · [Book a demo](https://cal.com/tracy-ai/tracy-demo-web?utm_source=blog&utm_medium=seo&utm_campaign=backend-developer-interview-questions&utm_content=demo)

## Sources

- [Tracy AI Interviewer home page](https://tracyinterview.ai/), retrieved 9 Nov 2026.
- [Tracy AI Interviewer pricing](https://tracyinterview.ai/pricing), retrieved 9 Nov 2026.
- [Tracy AI Interviewer Connect page](https://tracyinterview.ai/connect), retrieved 9 Nov 2026.