An endpoint that answered in 40ms for a year now takes nine seconds. Nothing was deployed. The query is unchanged. The table crossed some threshold last Tuesday and the planner changed its mind.
Whoever on your team can walk into that and come out with the cause in twenty minutes is worth several people who can write elegant SQL, and your interview almost certainly cannot tell them apart. Writing SQL is a skill most backend candidates have. Diagnosing a database under load is a different skill, weakly correlated with the first, and it is the one that gets called at 2am.
Whiteboard SQL tests recall. Write a query with a self-join and a window function. It measures whether somebody has written that shape recently. It says nothing about behaviour at volume, because on a whiteboard there is no volume.
"How would you optimise this query" invites recitation. Add an index, avoid SELECT *, watch out for N+1. Everyone has read the list. The list is correct and it is not the skill, because the skill is knowing which item applies to the specific slow thing in front of you, and that is a diagnostic judgment made from evidence.
Schema design questions are a different job. Worth asking, and they measure modelling rather than operations. A great modeller can still be helpless when the planner switches to a sequential scan.
The gap in all three: there is no database, so there is no plan, no statistics, no lock, no cache, and no actual slowness. Every interesting fact about a slow query is a fact about a running system.
Run each on a real database with enough data that the behaviour is real. A few million rows is usually enough, and the setup work is the price of the entire signal.
1. The query that got slow. An endpoint that was fast and is now slow, with data volume grown past the point where the plan flipped. Nothing changed in the code.
What you watch: whether they ask for the plan. EXPLAIN ANALYZE is the first move and a surprising number of candidates start by rewriting the query on instinct. Then whether they read the plan properly: the difference between estimated and actual rows is where the answer usually is, and noticing a 200x estimate error is the moment the good ones visibly change direction. Missing statistics, a discarded index, a bad correlation assumption: all findable in one plan, by somebody who reads plans.
2. The N+1 that only appears under load. An endpoint that is quick alone and collapses at concurrency, because it issues one query per row and the connection pool is finite.
What you watch: whether they look at the application at all, or only at the database. A candidate who stares at slow query logs and never notices that the same query appears eleven hundred times is missing the actual pattern. The tell is looking at query count rather than query duration, and it is a habit people acquire by having been burned.
3. The lock. Writes queueing behind a long transaction, or a migration taking a lock nobody expected. Everything looks idle. CPU is low. Latency is terrible.
What you watch: whether they know that "the database is not busy and everything is slow" points at waiting rather than at work. Someone who reaches for pg_stat_activity and looks at wait events has operated a database. Someone who starts tuning work_mem has read about operating one.
4. The index that made it worse. They add an index and the write path degrades, or the planner picks it and picks badly. Optional, and the strongest candidates enjoy it.
What you watch: whether they measure after changing something. The most common real-world failure is not choosing the wrong fix, it is not verifying the fix, and this scenario catches it directly.
Every scenario above requires a database with data in it, a workload, and tooling. Described in conversation, all four become "I would look at the query plan", which is what everybody says.
In EasyEnv the candidate gets a real machine with the database, a seeded dataset at realistic volume, the application, and a load generator. The session is recorded, so the review is over the sequence: did they check the plan before rewriting, did they count queries or only time them, did they measure after the change. In database work that order is nearly the whole assessment, because the difference between an engineer who diagnoses and one who guesses is not what they know, it is when they look at evidence.
It also lets you be honest about AI. Let them use it. A model will produce an excellent general explanation of why a sequential scan might be chosen, and it cannot tell you why the planner chose one for this table without the plan, the statistics and the row counts. Watch whether the candidate goes and gets them.
Knows the list. Suggests an index, suggests avoiding SELECT *, mentions N+1 as a category. Correct vocabulary, no diagnostic loop. Would probably fix it eventually by trying things.
Reads the evidence. Runs EXPLAIN ANALYZE first. Notices the estimate versus actual gap. Checks whether statistics are current. Counts queries rather than only timing them. Verifies after changing something. This is the working level and it is what you are hiring for.
Has been on call. All of the above, plus the questions that reveal operational scar tissue: is this a replica or the primary, when did autovacuum last run on this table, is the connection pool sized for this or inherited, will this index build lock the table in production. They also ask what the acceptable latency is before optimising anything, which is the question that separates engineering from tuning.
You can place a candidate in one of these three bands inside twenty-five minutes, on one scenario, if the database is real.
Do not ask them to recite isolation levels. Look up the specific semantics of REPEATABLE READ in your database, right now, without checking, and see how you get on.
Do not make the fix the pass condition. Some of these have several defensible fixes and the reasoning is the signal. A candidate who finds the cause, explains the tradeoff between an index and a query rewrite, and runs out of time has passed.
How to assess debugging skill is the general form of this, and interviewing data engineers on a pipeline that actually breaks applies the same idea further up the stack.
The last time a query got slow on your system, how long did it take to find out why?
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
When the candidate pairs with an AI instead of with you, the assessment moves from writing code to judging it. Here is what to watch, how to design a task the model cannot finish alone, and what a strong session actually looks like.
Hiring managers are now expected to judge how well candidates work with AI, mostly without having done it themselves on real work. Here is the minimum literacy you need to run that round honestly, and the four questions that expose whether you have it.
Read more
The first infrastructure hire is not a scaled-down platform engineer. Here is what the role really is at that stage, why tool-list interviews mislead, and four scenarios that show whether someone can work inside a system nobody documented.
Read more
