A report page that always loaded in 300ms now takes 12 seconds. Nobody changed the query and nobody deployed. What is your first hour?
What they are really testing: They want to hear that you know a query plan can change even when the SQL does not, and that you can separate a database problem from an application problem with evidence.
A real interview question
A report page that always loaded in 300ms now takes 12 seconds. Nobody changed the query and nobody deployed. What is your first hour?
What most people say
drag me
“The database is probably under load, so I would ask to scale it up to a bigger instance and see if that helps.”
Scaling up is a guess that costs money and often changes nothing, and it shows no ability to read a plan or reason about why a plan flipped.
The follow-ups they ask next
How would a plan change without the query changing?
Stale statistics, data volume crossing a threshold, parameter sniffing, or a dropped or invalidated index.
The report is genuinely scanning millions of rows. Now what?
Move from tuning to design: a covering index, a materialised view, or precomputing the report off the hot path.
What the interviewer is listening for
- Separates one slow query from a globally slow database
- Reaches for EXPLAIN ANALYZE and reads the plan
- Names stale statistics and autovacuum as a real cause
- Adds a latency alert so the next occurrence is caught early
What sinks the answer
- Immediately asks to scale the instance up
- Says nothing changed so it must be the network
- Cannot explain what an index scan versus a sequential scan means
- Adds an index with no measurement before or after
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“I have not hit this exact regression, but here is how I would reason about it: the SQL is the same, so I would look for what changed underneath it, which is usually the data volume or the statistics that drive the plan.”
Keep going with troubleshooting
Junior
You get paged at 2am. Checkout latency has gone from 200ms to 4 seconds and it started right after the 11pm deploy. Walk me through what you do.
Junior
It is 3am and you get paged: the primary application server is at 100% disk usage and the app is throwing write errors. You are the only one online. Walk me through exactly what you do.
Junior
You push a new version of a service and within two minutes the pods are all showing CrashLoopBackOff. The team is watching you share your screen. Walk me through exactly what you do.
Junior
A developer pings you: the checkout service cannot reach the payments service, the calls just hang and time out. You have never worked on either service. Walk me through what you do.
Junior
A developer messages you: 'My app suddenly gets Access Denied writing to the S3 bucket. Nothing changed.' It worked yesterday. Walk me through what you do.
Mid
Your load balancer shows 5xx errors jumping from 0.1 percent to 12 percent of requests over ten minutes. There was no deploy. What do you do?
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free