Skip to content
Aethel

AI interview prep for backend developers

Backend questions in an AI screen are rarely about syntax. They ask about systems you ran: an API under load, a schema that had to change while people used it, a payment call that failed halfway. Below are the kinds of questions to expect, two worked answers with what separates weak from strong, the mistakes that cost backend candidates the most, and a free way to practice at your level.

Practice backend questions free

Entrevista con IA para desarrolladores backend: esta guía en español

What AI screens ask backend developers

  1. A service you owned

    “Tell me about a service you were responsible for. What did it do, how much traffic did it take, and what made it hard to run?”

    Listening for: Concrete scale (requests per second, data size), your own part in it, and one real difficulty rather than a tour of the architecture.

  2. A data model that had to change

    “Describe a time you changed the schema of a large table that was in use. How did you avoid downtime?”

    Listening for: The migration in steps, how old and new code ran side by side, and how you checked the data afterwards.

  3. Performance under load

    “An endpoint got slow as traffic grew. How did you find out why, and what did you change?”

    Listening for: A measurement before the fix (a profile, a query plan, a trace), the cause in one sentence, and numbers before and after.

  4. Failure halfway through

    “What happens in your system when a downstream call fails in the middle of a request?”

    Listening for: Timeouts, retries with limits, idempotency, what the user sees, and a real case where it mattered.

  5. Security and personal data

    “How did you handle secrets, authentication or personal data in a service you built?”

    Listening for: Specific controls you put in place and why, instead of a list of best practices.

  6. A trade-off you defended

    “Tell me about a time you chose a simpler design over a more scalable one, or the other way round.”

    Listening for: The options, the cost of each, and what would have made you choose differently.

  7. Explaining to people outside engineering

    “How would you explain to a product manager why a feature needs a two-week backend change?”

    Listening for: Plain words, the risk stated honestly, and an option that trades scope for time.

Worked example: a slow endpoint

Each example shows a weak and a strong answer to the same question. The “With Aethel's rules” lines apply Aethel's published scoring rules, one concrete example of how an AI interview can judge an answer.

Made-up exampleWritten by Aethel to show the difference. Not a real candidate, and not scored by the AI.

Question: “An endpoint got slow as traffic grew. How did you find out why, and what did you change?”

Weak answer

“We had an endpoint that was slow, so I looked into it and found the database queries were inefficient. I added some indexes and caching and it got a lot faster. I always try to profile before optimizing, and I think performance is really important for user experience.”

Why it is weak: No specific case: no product, no traffic, no numbers. The cause is generic ("inefficient queries"), two fixes are named without saying which one mattered, and the last sentence is a belief about performance, not evidence of it. A follow-up such as "how much faster?" has nothing to stand on.

With Aethel's rules: Situation 0, reasoning 1, result 1: 2 of 8 points, and with no specific case the area is at most 60 on Aethel's scale.

Strong answer

“At a ticket resale marketplace with about 2 million monthly users, I owned the search results endpoint. During a big concert on-sale its p95 went from about 300 milliseconds to over 4 seconds. I pulled the slow query log instead of guessing, and one query stood out: listings were joined to the venue seating table and sorted by price, and the query plan showed a full scan of about 18 million seat rows on every request. I added a composite index on event, section and price, and rewrote the sort so it ran on the index. I considered putting a cache in front of it, but prices change every few seconds during an on-sale, so a cache would have shown seats that were already gone, which is worse than slow. On the next on-sale the endpoint held a p95 of about 250 milliseconds at twice the previous peak, and I added the query to our load test so a regression would fail the build.”

Why it is strong: It places the case in one sentence (the product, the users, the endpoint), shows how the cause was found (the slow query log and the query plan, not a guess), names one fix precisely, and explains why the obvious alternative lost. The result is a before and after under real load, plus a guard against the problem coming back.

With Aethel's rules: Situation 2, reasoning 2, result 2: 6 of 8 points, which is 87 on Aethel's fixed scale. A real score can differ.

What comes next: Likely next question: how did you add an index to an 18-million-row table without locking it? Have that answer ready. Naming a second option you compared, such as a read replica, and why it lost, would raise the reasoning.

Worked example: a payment call that failed halfway

Made-up exampleWritten by Aethel to show the difference. Not a real candidate, and not scored by the AI.

Question: “What happens in your system when a downstream call fails in the middle of a request?”

Weak answer

“I make sure we have retries and good error handling. If a call fails we retry it a few times and log the error so we can look at it later. We also have monitoring and alerts, so if something goes wrong the on-call engineer gets paged and can fix it.”

Why it is weak: This describes good intentions, not a case. Retrying "a few times" without idempotency can charge a customer twice, which is exactly what a careful interviewer asks next. There is no system, no failure and no outcome.

With Aethel's rules: Situation 0, reasoning 0, result 0: 0 of 8 points, and with no specific case the area is at most 60 on Aethel's scale.

Strong answer

“In the order service at a meal kit company, about 30,000 orders a day, checkout called our payment provider and then wrote the order. One afternoon the provider started timing out after the charge had gone through, and our client retried, so 212 customers were charged twice in about forty minutes. I led the fix. Every checkout now sends an idempotency key built from the cart id and the attempt, so the provider returns the first charge instead of making a new one. I changed the flow to write the order as pending before calling the provider and to settle it from the provider's webhook, so a timeout no longer leaves us guessing. I looked at moving to separate authorization and capture steps, but our provider charged per authorization and the change would have taken a quarter. In the eight months since, through two more provider incidents, we have had no duplicate charges, and the refund script we wrote that day has not been needed again.”

Why it is strong: It starts from a real failure with its size (orders a day, customers affected, minutes), then gives the mechanism: idempotency keys, a pending state and a webhook, each tied to the failure it prevents. It weighs a bigger alternative and says why it lost, and the result is followed for months, through later incidents.

With Aethel's rules: Situation 2, reasoning 2, result 3: 7 of 8 points, which is 91 on Aethel's fixed scale. A real score can differ.

What comes next: Be ready for: what happens if the webhook never arrives? A strong answer names the job or the timeout that settles orders stuck in pending.

Common mistakes in backend answers

  • Touring the architecture diagram. Walking through every box (load balancer, three services, a cache, a database) uses your time without showing judgment. Pick the one part where you made a choice and spend the answer there.
  • Saying "it scaled" without a number. Scale is the context of backend work. Requests per second, rows, messages a day or the size of the team let the interviewer place your case. Round numbers are fine.
  • Retries without idempotency. Mentioning retries for payments, emails or anything with side effects, without saying how duplicates are prevented, invites the hardest follow-up in a backend interview.
  • Skipping how the change reached production. Backend changes fail during rollout: migrations, backfills, dual writes, feature flags. Say how yours shipped safely, not only what it was.
  • Claiming speed without measuring it. "It got faster" is a claim. "p95 went from 4 seconds to 250 milliseconds at twice the traffic" is a result.
  • Naming tools as reasons. "We used Kafka because it is the industry standard" gives no reason. "We needed to replay messages after consumer bugs, and our old queue deleted them on read" does.

Numbers worth having ready

An interviewer places a case by its numbers. Find these for each of your cases before a backend interview; rounded is fine:

  • Requests per second at peak, and p50, p95 or p99 latency for the endpoint you discuss
  • Error rate or availability before and after a change
  • Rows, gigabytes or messages a day for the data involved
  • How long a migration or backfill took, and whether anything went down
  • How many services or teams depended on yours
  • For one incident: time to detect, time to recover, and customers affected

Practice backend questions free

Pick a level, type an answer to each question, and read the quick check after each one. Free, no account, nothing saved, and not a score.

Questions from backend developers

Will an AI interview ask me system design questions as a backend developer?

Often. It may be about a system you built or a hypothetical one. In Aethel's interview it is about your own systems, sometimes followed by a realistic change such as a traffic spike, and you answer in words, without a whiteboard.

Should I mention specific databases and frameworks?

When they explain a choice. "I used Postgres" says little. "I kept search in Postgres with a partial index instead of adding a search cluster, because nobody on the team could run a second one" shows judgment.

How technical should my answers be if the interviewer is an AI?

As technical as the question. AI interviewers are usually told the role, so naming a query plan, an index or an idempotency key is fine. What matters is that each detail serves the story: the problem, your choice, and what happened.

Which practice level should I pick?

The level of the job you want, not your current title. If you are a mid-level developer applying for a senior role, practice the senior questions: they ask about decisions across teams and results followed for months, and it helps to find those cases before the interview does.

More developer guides

Start from the developer guide, Prepare for an AI interview as a developer, or read what Aethel's software engineering interview covers.