Backend Developer interview questionsTechnical Interview round

Purpose

Frames the hour as an inheritance, not a quiz, and makes asking for evidence normal, so the candidate reasons from the page rather than listing what goes wrong with APIs.

Purpose

Production debugging, read on one request. The trace holds a textbook problem — 200 queries — worth 4% of the time; the read is whether the candidate adds the spans up before reaching for a fix they know, and asks for the plan before proposing an index.

Signals to score

• Adds the trace up and ranks it before proposing anything: pool wait 3.8 s, page query 3.6, count 1.4, lookups 0.4, serialisation 0.2
• Reads the pool wait as queueing behind other slow requests, not as a pool that is too small
• Asks for the plan, and infers from page 1 costing what page 1,200 does that every page reads all the tenant's rows and sorts the unpaid ones
• Proposes an index matching the filter and the sort — `tenant_id`, `status`, `created_at`, then `id` — and says why `id` is last
• Explains that OFFSET still reads every skipped row with that index, and adds a cursor on `created_at` and `id`, keeping `page`, capped, until the vendor moves
• Notices that invoices issued or paid mid-crawl shift the pages, so the connector misses some and reads others twice
• Asks who reads `total`, and drops it or makes it optional rather than counting 120,000 rows per page
• Names the 200 lookups as N+1 and batches them, while placing them at about 4% of the request
• Sees that the crawl exists because the changes feed was abandoned, so a feed the connector trusts removes most of the load
• Measures the fix at 09:00: the tenant's p99, the pool wait, and the statement's time in `pg_stat_statements`

Follow-up questions

• The trace has 200 queries in it. Is that your first fix?
• Run alone, page 1 takes about as long as page 1,200. What does that tell you?
• With your index in place, what does page 1,200 still cost?
• Invoices get paid while the connector is paging. What does it see?
• What does `total` cost, and who reads it?

Purpose

Tests whether the candidate can explain a cascade from a pool, a health check, a retry policy and a connection limit, see that the service let one endpoint take everything, and contain it without buying capacity. Many fix the query and stop.

Signals to score

• Tells the chain: sixteen page queries pin the database CPU, every query slows, connections are held longer, and the pools empty into 503s
• Reasons with rate times hold time: 300 requests a second at 20 ms keep 6 of 60 connections busy; at 200 ms, all 60
• Notices the middleware's transaction holds each connection for the whole request, serialisation included
• Explains that `/healthz` shares the pool, so the load balancer pulls working instances and piles their traffic on the rest
• Says the connector's 10-second give-up and instant retry leave the abandoned query running beside a second copy
• Rejects 12 instances with pools of 20: 260 connections against a limit of 100, and more queries on a saturated CPU
• Caps concurrent list requests per tenant, answering the excess with 429 and Retry-After
• Sets a statement timeout on the API's database role, so a query nobody is waiting for stops using CPU
• Makes the health check answer for the instance, not for the database through the request pool

Follow-up questions

• `GET /v1/me` reads one row. Why does it return 503 at 09:03?
• What does the load balancer do when `/healthz` can't get a connection?
• A colleague wants 12 instances with pools of 20. What happens at 09:00 tomorrow?
• The connector gives up after 10 seconds and retries. What happens to the request it gave up on?
• Once the page query takes 20 ms, why keep any of this?

Purpose

The read is whether the candidate explains each loss by its mechanism — what a filter excludes, what a bulk write skips, when a row becomes visible — before reaching for a new technology. The third loss separates those who know a timestamp is taken before the commit that makes the row visible.

Signals to score

• Explains the unpaid invoices: the feed returns only `issued` invoices, so a payment takes an invoice out of the feed instead of into it
• Explains the late fees: the job's SQL `UPDATE` bypasses the ORM, so `updated_at` never moves
• Reads the example: stamped 10:00:00.2 but invisible until 10:00:06.1, by when the client's `since` was already 10:00:04.8
• Generalises it: a write that commits after a later-stamped write has been read is lost for good, and slow commits make that routine
• Returns every changed invoice with its current status, and a tombstone for anything deleted
• Sets `updated_at` in the database with a trigger, so no write path can skip it and one clock stamps every row
• Knows any stamp a trigger takes — `now()` or `clock_timestamp()` — precedes the commit, so it does not fix the example
• Stops each response, and the `since` it implies, just before the oldest open write transaction began, or follows a commit-ordered log instead
• Pages on `updated_at` and `id` together, so rows sharing a timestamp are not skipped at a page boundary
• Makes the client's apply idempotent, and adds a per-day count or checksum to catch the next silent loss

Follow-up questions

• Paid invoices still show unpaid in the ERP. Which part of the feed's definition does that?
• The correction was saved at 10:00:00.2. Why did the 10:00:03 sync miss it, and why did every later one?
• The late-fee job now sets `updated_at` on 9,000 invoices in one statement. What does the connector receive?
• What is the newest `since` the server can safely hand out?
• How will you hear about the next lost change before the tenant's accountants do?

Purpose

Tests whether the candidate treats tenant isolation as something the data layer guarantees rather than something each handler remembers, and handles a leak in order: close it, keep the evidence, measure it, tell people. Many fix the handler and stop; others offer UUIDs as the fix.

Signals to score

• Closes it within the hour — the tenant condition in the query, or the route switched off — before the investigation, not after
• Copies the access logs somewhere safe this morning, since their 30-day retention deletes a day of evidence every day
• Answers another tenant's id with 404, not 403, because a tenant-scoped query cannot tell "not yours" from "not there"
• Joins the logs to invoice owners to list cross-tenant downloads in the 30 days logged, and treats that as a floor for a route open since last year
• Treats the 290 sequential downloads from one token as scripted enumeration, malicious or a broken integration: revokes the token and finds out whose it is
• Searches for every other query on a tenant's table that lacks the tenant, rather than calling it one bug
• Makes scoping the default: a data-access layer that will not query a tenant's table without a tenant, or row-level security behind it
• Adds a test that calls every route with a second tenant's token and expects 404
• Rejects UUIDs as the fix: harder to guess is not the same as checked
• Brings in whoever owns security and privacy today, and plans to tell the affected tenants

Follow-up questions

• Do you fix it now, or wait until you know how far it goes?
• The logs keep 30 days. What do you do about that this morning?
• Should another company's invoice get a 403 or a 404?
• Someone proposes switching invoice ids to UUIDs. Is that the fix?
• How do you stop the next endpoint someone writes from doing this?