Sample interview

Senior Backend Engineer

7 questions · 60 minutes

Python services on PostgreSQL with payments, background jobs and on-call ownership.

Illustrative: the job post, candidate and results are examples.

Why this interview

Requirements

The job requires

Python services
PostgreSQL
Payments APIs
Background jobs
Production reliability

Claims

The résumé claims

Django and Celery
Payments integration
AWS

Focus

So the interview tests

Concurrency and transactions
Idempotency
Async Python
Failure modes

The plan we propose

Every question comes with the reason it was chosen. The interviewer can swap any of them before sending.

1
Two concurrent withdrawals
Multiple choice · Advanced · ~5 min
Why this question: The job runs on PostgreSQL. Lost updates under READ COMMITTED are a classic, costly concurrency bug.
2
Reviewing an idempotency key implementation
Select all · Advanced · ~6 min
Why this question: The résumé claims payments work. Idempotency under retries and crashes is the core of it.
Try it below
3
Confirmation emails for orders that do not exist
Multiple choice · Advanced · ~5 min
Why this question: Django and Celery are on the résumé. Enqueueing work before the transaction commits is a frequent real bug.
4
Health checks fail when a dependency is slow
Line selection · Advanced · ~4 min
Why this question: Python services: tests whether the candidate understands the event loop, not just async syntax.
Try it below
5
Slow recovery after a database failover
Multiple choice · Senior · ~6 min
Why this question: On-call ownership means recognizing retry storms that keep a system down.
6
Why is the email index ignored?
Multiple choice · Intermediate · ~4 min
Why this question: Reading a query plan is daily PostgreSQL work.
7
Contain a poison message
Ordering · Advanced · ~5 min
Why this question: Background jobs need a plan for messages that can never succeed.

Try two of the questions

Answer as the candidate would. The interviewer guide beside each question is what the interviewer sees.

Reviewing an idempotency key implementation

Candidate view

Exactly what the candidate sees. Try answering it.

A payments API accepts an Idempotency-Key header on POST /payments so clients can safely retry. The handler looks like this:

1handle(request):
2    key = request.header("Idempotency-Key")
3    existing = store.get(key)
4    if existing:
5        return existing.response
6 
7    response = charge_card(request.body)
8    store.put(key, response, ttl = 24h)
9    return response

Select every statement that is true.

Select every statement that applies

Choose an answer to check it.

Interviewer guide

Objective

Test whether the candidate can find the race and atomicity gaps in an idempotency key implementation.

Hints

Ask them to run two identical requests through the handler at the same instant.

Follow-ups

deepenWhat should the server return while the first request with a key is still in progress?
if-quickHow would you choose the TTL for stored keys?
deepenPayments live in PostgreSQL. Where and how would you store the keys?

Strong signals

Spots the check-then-act race and the crash gap between charging and recording.
Proposes atomically claiming the key before charging, scoped per account, and rejecting a changed body.

Weak signals

Believes checking the store first makes it safe.

Rubric

Looks fine. Selects D or F.
Finds one gap. Finds the race or the crash gap but not both, or misses scoping.
Correct design. Finds every issue and designs an atomic claim with in-progress handling.

Health checks fail when a dependency is slow

Candidate view

Exactly what the candidate sees. Try answering it.

The service runs as a single uvicorn worker. When the internal rates service slows down to about 4 seconds per response, the /health endpoint starts timing out too, and the orchestrator restarts the container. /health does no I/O at all.

Click the line that explains why /health is affected.

Click line numbers to select · 0 of 3 max

app.pypython

Choose an answer to check it.

Interviewer guide

Objective

Test whether the candidate recognizes a blocking call that stalls a single-threaded event loop.

Do not initially reveal

Do not point out that requests is a synchronous library.

Hints

Ask how many requests a single uvicorn worker can process at the same moment, and what that depends on.

Follow-ups

deepenHow would you detect event loop blocking in production before it causes restarts?
if-quickShould /health have been affected by the rates service at all? What would you change about the health check?

Strong signals

Identifies requests.get inside async def as blocking the event loop for every coroutine.
Offers a correct fix such as an async client, asyncio.to_thread or a plain def handler.

Weak signals

Blames asyncio.sleep(0) or the timeout value without understanding the event loop.

Rubric

Wrong cause. Selects a line unrelated to blocking or cannot explain the shared loop.
Found it. Selects line 10 but the explanation of why /health stalls is shaky.
Event loop fluent. Explains the stall precisely, gives a correct fix and discusses detection or health check design.

See what the interview actually established

Built only from the interviewer's judgment on each question. The job and résumé decide what gets tested; they never count as evidence.

What the interview established

Strongest evidence was in APIs & backend, Queues & background jobs, Reliability & incidents and SQL & data storage. Concurrency & runtime showed mixed evidence.

5 of 5 required areas evaluated · 7 questions judged by the interviewer

Required competencies

From the job. Open a row for the questions and notes behind it.

CompetencyRésuméQuestionsEvidence

Concurrency & runtime–2Mixed

Two concurrent withdrawals
StrongInterviewer
Interleaved the two transactions correctly and offered three fixes with tradeoffs.
Health checks fail when a dependency is slow
MixedInterviewer
Needed a nudge to see that requests.get blocks the whole event loop.

APIs & backendClaimed1Strong

Reviewing an idempotency key implementation
StrongInterviewer
Found the check-then-act race without a hint and proposed an atomic claim of the key.

Queues & background jobsClaimed2Strong

Confirmation emails for orders that do not exist
StrongInterviewer
Explained both the rollback case and the visibility race; knew transaction.on_commit.
Contain a poison message
StrongInterviewer
Designed bounded retries, a dead-letter queue and a safe replay.

Reliability & incidentsDemonstrated beyond résumé claims–2Strong

Slow recovery after a database failover
StrongInterviewer
Computed the retry multiplier and argued for retries at a single layer with budgets.
Contain a poison message
StrongInterviewer
Designed bounded retries, a dead-letter queue and a safe replay.

SQL & data storageDemonstrated beyond résumé claims–3Strong

Two concurrent withdrawals
StrongInterviewer
Interleaved the two transactions correctly and offered three fixes with tradeoffs.
Confirmation emails for orders that do not exist
StrongInterviewer
Explained both the rollback case and the visibility race; knew transaction.on_commit.
Why is the email index ignored?
StrongInterviewer
Read the plan correctly and proposed an expression index.

Also observed

Not required for this role, but the questions produced evidence.

CompetencyRésuméQuestionsEvidence

Caching & performance–2Mixed

Health checks fail when a dependency is slow
MixedInterviewer
Needed a nudge to see that requests.get blocks the whole event loop.
Why is the email index ignored?
StrongInterviewer
Read the plan correctly and proposed an expression index.

Distributed systems–2Strong

Reviewing an idempotency key implementation
StrongInterviewer
Found the check-then-act race without a hint and proposed an atomic claim of the key.
Slow recovery after a database failover
StrongInterviewer
Computed the retry multiplier and argued for retries at a single layer with budgets.

How they worked

The kind of work the questions asked for, across competencies.

Way of workingJudgedExercisedEvidence

Debugging44Mixed

Design reasoning33Strong

Root-cause analysis33Mixed

Incident analysis22Strong

Build interviews like this for your roles.

Post a job, and we propose an interview for every applicant from the job and their résumé.

Start interviewing More samples