Backend Engineer interview kit: questions and rubric

How to use this kit

1. Agree the competencies with the hiring manager before the job is posted.
2. Give each interviewer one or two competencies, so nothing is asked twice.
3. Ask every candidate the same core questions; follow up freely.
4. Rate each competency against the anchors straight after the interview, alone.
5. Debrief on quotes, not adjectives, then decide with the rule at the end.

First-round screen

Fifteen to twenty minutes, by phone, video or a disclosed AI screen. The aim is to confirm the basics before the panel spends its time.

1. What draws you to backend work, and what kind of systems do you want to work on next?
2. Walk me through a service you built or own in production: what it does, what it depends on, and what has gone wrong with it.
3. This role works in the language, database and cloud named in the job description. Which of them have you run in production, and for how long?
4. The job description sets out the location, working pattern and start date. Do those work for you, what is your notice period, and what compensation range are you expecting?

1. Exercise, 25 minutes: design the API and the database tables for booking meeting rooms. Employees book a room by the half hour and can cancel, and a room must never be double-booked. Sketch the endpoints and tables on a whiteboard or in a shared doc; no code needed.

   Follow up with

   • How do you stop two people booking the same room at the same moment?
   • What happens if the client retries a booking request after a timeout?
   • How would you add recurring bookings later without breaking existing clients?
   Strong answer

   Names the entities and relationships, chooses keys and indexes deliberately, and enforces "no double-booking" in the database (a unique or exclusion constraint, or a transaction with the right locking), not only in application code. Makes booking safe to retry with an idempotency key, uses clear resource names and status codes, and plans additive changes for new features.

   Weak answer

   Checks availability in application code and then inserts, with no thought for two requests at once. Designs endpoints as verbs that mirror functions, ignores retries, and cannot explain a single constraint or index.

2. Tell me about a schema or API change you made to something other teams or clients already depended on. How did you roll it out?

   Follow up with

   • How did you migrate the existing data?
   • How did you know when the old version could be removed?
   Strong answer

   Describes an expand-and-contract change: add the new field or endpoint, backfill, move consumers across, then remove the old one once usage shows nobody calls it. Keeps old clients working throughout, and avoids long locks on busy tables.

   Weak answer

   Made the breaking change in one release and fixed consumers as they broke, or ran a migration that locked a busy table with no plan for it.

1. Debugging walk-through, 15 minutes: since this morning's deploy, the orders endpoint's 95th-percentile latency has gone from 200 ms to 4 seconds, for some customers only. Error rates are normal. I will play the system: ask for any log, metric, trace or query plan you want. (Script the answers in advance, such as a new query that scans a whole table for customers with many orders.)

   Follow up with

   • What is your first hypothesis, and what would disprove it?
   • At what point would you roll back, and why?
   • What would you add so this is found faster next time?
   Strong answer

   Asks whether rolling back is the fastest way to stop the harm, then narrows systematically: which customers, which queries, what changed in the deploy. Asks for a trace or a query plan, finds the cause, and separates mitigation (roll back) from the fix (an index or a rewritten query) and the follow-up (a test or alert).

   Weak answer

   Guesses causes at random, restarts servers or asks for bigger machines. Never asks what changed in the deploy and never considers rolling back.

2. Tell me about the hardest production bug you have tracked down. How did you find it?

   Follow up with

   • What did you rule out first, and how?
   • What did you change so it could not happen again?
   Strong answer

   Describes a specific bug (a race condition, an exhausted connection pool, a time zone or encoding error), the evidence used to narrow it, the root cause rather than the symptom, and a lasting fix such as a test, an alert or a design change.

   Weak answer

   The story ends at a restart or a retry, or the bug was found by luck. Cannot explain the root cause or what changed afterwards.

1. A service you own calls a third-party payments API that sometimes takes 30 seconds to answer, or times out. What do you do about it?

   Follow up with

   • What timeout and retry policy would you set, and why?
   • How do you make sure a customer is never charged twice?
   • What would you alert on?
   Strong answer

   Sets explicit timeouts, retries only safe operations with backoff and jitter, sends an idempotency key so a retry cannot charge twice, moves slow work off the request path to a queue where that fits, and alerts on what users feel rather than on every error.

   Weak answer

   Raises the timeout or adds unlimited retries, which can charge customers twice or overload the provider. Has no way to tell whether the change worked.

2. Tell me about a service you were on call for. What did you change because of what the pager taught you?

   Follow up with

   • Which alert did you change or delete, and why?
   • What did the review after the worst incident lead to?
   Strong answer

   Names specific changes: a noisy alert tied to a user-facing symptom instead, a runbook written, a health check or dashboard added, a capacity limit found and raised. Took part in blameless reviews and saw the actions through.

   Weak answer

   Has never looked at their service after deploy, or treated alerts as noise to mute. No follow-up after incidents.

3. What would you check before running a background job that rewrites ten million rows in production for the first time?

   Follow up with

   • How would you stop it halfway if something looked wrong?
   Strong answer

   Runs it in batches that are safe to re-run, tests it on a copy of production data, limits its rate, watches database load and replication lag, and keeps a way to pause and resume. Has a rollback or a backup plan for the data.

   Weak answer

   Runs it as one large transaction against production and watches what happens. No way to stop it cleanly or to undo it.

1. Work sample, 10 minutes: here is a 30-line endpoint that returns an invoice by id. It checks that the user is signed in but not that the invoice belongs to their account, builds its SQL by joining strings, and logs the full request body. What would you change?

   Follow up with

   • Which issue would you fix first, and why?
   • How would you test that the fix works?
   • Where else in the codebase would you look?
   Strong answer

   Finds the missing ownership check (any signed-in user can read any invoice), the injection risk and the personal data in the logs. Fixes them with an authorization check scoped to the account, parameterized queries and redacted logging, adds a test for the access rule, and looks for the same pattern elsewhere.

   Weak answer

   Finds only the SQL string, or says the sign-in check is enough. Proposes a firewall or a scanner instead of fixing the code.

2. Tell me about a security issue you found, caused or fixed in a system you worked on.

   Follow up with

   • How was it discovered?
   • Who did you tell, and how quickly?
   Strong answer

   Gives a concrete case (a leaked secret rotated, a broken access check, a dependency with a known vulnerability), acted quickly, told the right people, and fixed the kind of problem, not just the one instance.

   Weak answer

   Cannot name one, or kept a mistake quiet. Treats security as the security team's job.

1. Tell me about a time a frontend, mobile or partner team needed a change to your API sooner than you thought was safe. What happened?

   Follow up with

   • What did you offer them?
   • What did you write down, and where?
   Strong answer

   Understood what the other team actually needed, offered a safe interim (a narrower endpoint, a feature flag, a dated plan), wrote the agreement down in the API docs or a ticket, and delivered what was promised.

   Weak answer

   Refused without an alternative, or rushed the change and broke something. The other team learned about the outcome by accident.

2. What would you do if you found that another team's service was writing bad data into a table your service reads?

   Follow up with

   • How do you protect your own service meanwhile?
   • Who do you contact first?
   Strong answer

   Protects their service with validation or by skipping bad rows, contacts the owning team with evidence, agrees a fix at the source and a clear contract for the data, and helps clean up what was already written.

   Weak answer

   Quietly patches the data or adds workarounds in their own code, or escalates to managers before talking to the owners. Treats it as the other team's problem alone.

Never ask

• Don't ask a candidate's age, or their graduation year to work it out. Why: age says nothing about engineering skill, and age-based decisions are unlawful in many places.
• Don't ask about marital status, children, pregnancy or plans to start a family. Why: none of it is job-related, and the question is still put mostly to women, which makes it discriminatory as well as irrelevant.
• Don't ask about religion, caste, community or the origin of a surname, directly or by proxy ('What does your father do?'). Why: in India these questions signal caste and religion, which have no bearing on the job.
• Don't ask 'Where are you from originally?' or 'What is your native place?'. Why: it invites judgments about region, language and community. If location matters, ask whether the candidate can work from the job's location.
• Don't ask about citizenship or nationality. Why: it is not job-related and can be unlawful discrimination in the US, the EU and elsewhere. Ask only whether the candidate has the right to work in the job's location, or will need sponsorship.
• Don't ask about health conditions, disabilities or past medical leave. Why: the only relevant question is whether the candidate can perform the essential functions of the job, with or without reasonable accommodation.
• Don't ask for salary history where the law restricts it: many US states and cities do, and the EU Pay Transparency Directive requires member states to. Why: it carries past pay gaps into the new offer. Ask for the expected range; in India, where current pay is commonly asked, still set the offer from the role's band.
• Don't ask the candidate to share code, schemas or incident details from their current employer, or to solve a problem from your real backlog. Why: the first may breach their confidentiality duties, and the second is unpaid work. Use fictional exercises like the ones in this kit.

Questions people ask

What should a backend engineer system design interview cover?

For a mid-level engineer, the design of one feature or service at a realistic scale: the data model, the API, concurrency, and what happens when a dependency fails. A global-scale design question mostly tests rehearsal. Ask how the design changes at ten times the load to see judgment about growth.

How do you test debugging skills in an interview?

Run a walk-through in which the interviewer plays the system. Describe the symptom, then answer each request for a log, metric or trace from a script written in advance. It shows how the candidate forms and tests hypotheses without any laptop setup. Use the same script for every candidate.

Does a backend engineer need to know our exact language and database?

Usually not, for a mid-level hire. Data modeling, concurrency, debugging and security carry over between languages and relational databases. If the job truly needs a specific stack from day one, test it directly and say so in the invitation.

How much security should a backend engineer know?

Enough to avoid the common mistakes in their own code: broken authorization, injection, secrets in code or logs, and outdated dependencies. They do not need to be a security specialist. The ten-minute invoice-endpoint review above tests the basics.