Skip to main content
VirtualInterview.ai
Sign InSign Up

Mock interviews by role · Software & Engineering

Backend Developer mock interview

Backend interviews test whether you can keep data correct when requests retry, dependencies fail, and two writes race. A clever schema that loses a payment or double-sends an email is a failing answer.

Rehearse these questions by drawing the request path first: client, API, database, and the one dependency that can time out. Then say what you persist and what you do when the call is repeated.

Practice this role with an AI interviewer

What the loop usually looks like

  1. Screen

    30 min

    A service you own, its data store, and a failure you handled.

  2. API or coding

    45–60 min

    Design or implement an endpoint with validation and errors.

  3. Systems and behavioral

    45 min

    Consistency, retries, and how you worked with on-call.

What interviewers score

  • Data integrity
  • Idempotency
  • Failure behavior
  • Operational clarity

10 backend developer interview questions and model answers

  1. Technical

    1. How do you make a payment endpoint safe to retry?

    What they are testing: Idempotency.

    The client sends an idempotency key. The server stores the key with the result and returns the same response if the key is seen again. The charge and the record commit together, so a retry cannot create a second charge after a timeout.

  2. Technical

    2. Two requests update the same inventory row. What do you do?

    What they are testing: Concurrency.

    I use a conditional update that checks the version or the remaining count in the same statement. If the count would go below zero, the statement updates no rows and the API returns a conflict. I do not read the count in the app and write it back later.

  3. Technical

    3. When do you choose a relational database over a document store?

    What they are testing: Data model choice.

    I choose relational when orders, users, and payments must stay consistent and I will query across them. A document store fits a payload I always read as a whole and rarely join. I name the query that would become painful in the wrong store.

  4. Technical

    4. A downstream email provider times out after you have already charged the user. What happens?

    What they are testing: Partial failure.

    The charge is committed. The email is a separate job that retries with backoff and eventually alerts a human. The API does not roll back a successful charge because a receipt failed to send.

  5. Domain

    5. How do you version an API that mobile clients cannot all update?

    What they are testing: Compatibility.

    I add fields and keep old ones until usage drops. I do not change the meaning of an existing field. A breaking change gets a new path and a date when the old one stops, written down where client teams will see it.

  6. Behavioral

    6. Tell me about a migration that had to run while the app stayed up.

    What they are testing: Safe changeover.

    I expanded the schema first, wrote both shapes, backfilled in batches, then switched reads. I kept the old column until the new path had a full day of traffic. The rollback was switching reads back, which I rehearsed before the backfill finished.

  7. Situational

    7. An endpoint is correct but p99 latency doubled. Where do you start?

    What they are testing: Performance triage.

    I check whether the slow requests share a query, a tenant, or a dependency. A flame graph or a query log beats guessing at indexes. If one query dominates, I fix that before I add caches everywhere.

  8. Technical

    8. What belongs in an application log versus a metric?

    What they are testing: Operability.

    A metric is a number I alert on: error rate, latency, queue depth. A log is the detail I need after the alert fires: request id, user id, and the error code. I do not log secrets or full card numbers.

  9. Behavioral

    9. Describe a time you pushed back on a shortcut that would corrupt data.

    What they are testing: Integrity under pressure.

    The proposal was to mark an order paid in the app before the provider confirmed. I showed a replay where a timeout would mark it paid twice in our books. We stored the provider event as the source of truth and made the UI wait on that record.

  10. Domain

    10. How do you explain a 500 to a support teammate?

    What they are testing: Cross-team communication.

    I say what the user tried to do, whether their data was saved, and what to tell them to do next. The stack trace stays in the ticket. The sentence support can read aloud is the one I write first.

Frequently asked questions

Are backend interviews only system design?

No. Many loops include a practical API or SQL exercise plus one design conversation. Practice both the endpoint and the story of a failure you handled.

How much infrastructure detail is enough?

Name the database, the queue, and the failure you designed for. Vendor product names matter less than what happens when a request is retried.

Should I draw during the mock?

Yes for design questions. A four-box sketch you can talk through beats a paragraph of tools. In a voice-only mock, describe the boxes in order.

How does scoring work on a backend mock here?

VirtualInterview.ai scores the answer on the round rubric, including correctness of the failure story and whether you named a trade-off. It does not write the code for you during a live interview.

Keep practicing