Database Administrator interview questions and how to answer them
A DBA interview is mostly one question asked a dozen ways: can we trust you with the data at the worst possible moment? Expect to talk through restores, slow queries and outages you've actually handled, often on a whiteboard or a shared screen. The people who do well tell specific stories with the commands, the numbers they watched and the mistake they won't make twice.
What happens in each round
- 1
Recruiter screen
What happens
Which engines you've run in production (SQL Server, PostgreSQL, Oracle, MySQL), whether you've carried a pager, and if you've worked on cloud services like Amazon RDS or Azure SQL. Keep it factual. They're matching keywords to the posting.
- 2
Hiring manager
What happens
How you think about backups, recovery and change control. Expect stories about an outage, a bad deploy or a developer who wanted production access. They want to know you'll say no calmly and explain why.
- 3
Technical panel
What happens
Hands-on depth. You may read an execution plan, explain a deadlock graph, design a backup schedule for a stated recovery target, or write SQL live. Senior engineers and sometimes a developer sit in.
- 4
Scenario or take-home
What happens
A broken or slow database to diagnose, or a written plan for a migration or failover. They're grading your order of operations as much as the fix.
Questions you're likely to get
1.Walk me through how you'd restore a production database to a point just before someone ran a bad delete.
Why they ask
Point-in-time recovery is the job. They want proof you've done it for real, not just read about it.
How to answer
- Stop the bleeding first: confirm the time of the delete from logs or the application team, and pause jobs that write to the affected tables
- Restore the last full backup plus differentials and log backups (or WAL archives) to a separate server, stopping just before the bad transaction
- Pull the missing rows back into production rather than overwriting the whole database, so you don't lose good writes made since
- Close with what you changed afterward, such as tighter permissions or a delete guard in the deploy process
2.How do you decide on a backup strategy for a new system?
Why they ask
Backups nobody has tested are a guess. They want to hear you start from the business, not the tool.
How to answer
- Ask the owners how much data they can afford to lose and how long they can be down (RPO and RTO)
- Pick full, differential and log backup frequency to match those targets, and store copies off the server and off the site
- Schedule regular test restores and time them, because a restore you haven't timed is a promise you can't keep
- Monitor backup jobs and alert on failures, not just on success emails nobody reads
3.A query that ran fine last week now takes forever. What do you do?
Why they ask
This lands on your desk more than anything else. They want a calm, repeatable method.
How to answer
- Get the actual execution plan and compare it with an older one from Query Store or pg_stat_statements if you have it
- Check for stale statistics, a parameter sniffing problem, a missing or dropped index, or data growth that tipped the plan
- Look at waits and blocking at the same time, since slow sometimes means stuck behind another session
- Fix the cause, test on a copy, then deploy through normal change control rather than hot-patching production
4.Explain the difference between a clustered and a non-clustered index, and when you'd pick each.
Why they ask
It's a fundamentals check. A fuzzy answer here makes the panel doubt everything else.
How to answer
- A clustered index defines how the table's rows are physically ordered, so a table only gets one
- Non-clustered indexes are separate structures pointing back to the rows, and you can have several
- Choose a narrow, unique, steadily increasing clustered key where you can, to avoid page splits
- Mention the cost side: every extra index slows inserts and updates and takes space
5.Tell me about a deadlock you tracked down.
Why they ask
Deadlocks show whether you can read evidence and work with developers instead of blaming them.
How to answer
- Say how you captured it, such as the system_health session in SQL Server or deadlock logging in PostgreSQL
- Describe the two sessions, the resources they held and the order they took locks in
- Explain the fix, often making both code paths touch tables in the same order or adding a better index
- Note that you walked the developers through the graph so it didn't come back
6.How have you set up high availability, and what happened the first time it actually failed over?
Why they ask
Plenty of people have configured replication. Fewer have watched it fail over at night and dealt with the fallout.
How to answer
- Name what you ran: Always On availability groups, PostgreSQL streaming replication with Patroni, Oracle Data Guard, or a managed Multi-AZ setup
- Explain synchronous versus asynchronous replication and the data loss trade-off
- Tell the real failover story, including anything that broke, such as connection strings, logins or jobs that only lived on the old primary
- Say what you added to the runbook afterward
7.A developer asks for write access to production to fix data by hand. How do you respond?
Why they ask
DBAs guard the data and still have to be easy to work with. This checks both.
How to answer
- Say no to standing access, but offer a fast path so the fix still happens
- Have them write the script, review it with a transaction and a row count check, and run it yourself or through the approved deploy tool
- Take a backup or snapshot of the affected rows first
- Log the change in the ticket so there's a record
8.How would you plan a migration from an on-premises database to a cloud service?
Why they ask
Lots of teams are moving databases. They want to see that you plan for cutover and rollback, not just the copy.
How to answer
- Inventory what the database depends on: agent jobs, linked servers, logins, features the managed service doesn't support
- Pick a method, such as native backup and restore, AWS DMS, or replication, based on how much downtime is allowed
- Run a full rehearsal on a copy and time it
- Write the cutover steps and a rollback plan with a clear go or no-go point
9.What do you monitor, and how do you keep alerts from turning into noise?
Why they ask
An on-call DBA who ignores alerts is worse than no alerts. They want judgment.
How to answer
- Cover the basics: backup success, replication lag, disk and log space, blocking, long-running jobs and failed logins
- Name the tools you've used, such as SolarWinds, Datadog, Redgate Monitor or Grafana with Prometheus
- Only page for things someone must act on now, and send the rest to a daily report
- Tune or delete any alert that fires without anyone doing something about it
10.Tell me about a time you made a mistake in production.
Why they ask
Everyone who's done this job has one. Honesty and what you changed matter more than the mistake.
How to answer
- Pick a real one with real impact, like a maintenance job run on the wrong server
- Say how fast you told people and how you fixed it
- Explain the guardrail you added, such as color-coded connections in SSMS or a confirmation step in scripts
- Keep it short and don't blame anyone else
11.You get paged at night because the transaction log is almost full. Walk me through it.
Why they ask
It's a classic on-call problem with a wrong answer that's tempting when you're tired.
How to answer
- Check why the log can't clear first, such as a failed log backup, a long open transaction or a stuck replica
- Fix that cause, for example by running the log backup or finding the open session
- Add space only if needed to buy time
- Never switch the recovery model or truncate the log without understanding that it breaks the backup chain
12.How do you handle a week where several teams all say their request is urgent?
Why they ask
DBAs sit between many teams. They want to see how you prioritize without making enemies.
How to answer
- Rank by risk to data and customers first, then by deadline
- Tell each requester where they are in the queue and when to expect an answer
- Bring real conflicts to your manager with a suggested order rather than guessing
- Mention something you automated to stop the same request coming back
Mistakes that sink good candidates
Talking about backups without ever mentioning that you test restores
Answering tuning questions with a tool name instead of a method
Bad-mouthing developers, since you'll be working next to them every day
Claiming deep expertise in every engine on the posting when you've only run one in production
Need more Database Administrator interviews to prep for?
HeroApply applies to Database Administrator jobs that match you, every day. 250 jobs are open today.