Database administrator interview questions and how to answer them

Remote DBA interviews are mostly about operations, not syntax. Expect a screening call, one or two technical rounds where you talk through backups, replication, performance and real incidents (sometimes with a live query plan to read), and a final round on how you work with developers and handle on-call. Some employers add a practical task, such as tuning a slow query or reviewing a migration.

The questions below come up again and again. Answers are mostly PostgreSQL and SQL Server flavoured; if you're interviewing for MySQL or Oracle, map each one to that engine.

Updated October 2026 by the WorkRemote careers team

On this page
  1. About the role and your experience
  2. Technical questions
  3. Behavioural questions
  4. Situational questions
  5. Remote work questions
  6. Remote interview tips
  7. FAQs

About the role and your experience

Openers that check you understand the job and have done the work.

  1. How do you prove that your backups work?

    Why they ask

    Untested backups are the classic DBA failure. This shows whether you think like an operator.

    How to answer

    Describe regular, automated restore tests, how you measure restore time against the recovery targets, and how you'd alert on failure.

    Show a sample answer

    I schedule automatic restore tests: a job restores last night's backup to a scratch server every week, runs a few checks on row counts and recent data, then records how long it took. That gives us a real recovery time to compare with what the business expects. If a backup or a restore test fails, it alerts the same way as a production problem.

Technical questions

What you know and how you'd do the work, often with a live task or test.

  1. Walk me through how you'd restore a database to the state it was in at 2:15pm yesterday.

    Why they ask

    Point-in-time recovery is the DBA's most important skill. They want to know you've actually done it.

    How to answer

    Name the pieces: a base or full backup from before the target time plus the logs after it. Describe the restore steps for your engine and say you'd restore to a separate server first.

    Show a sample answer

    In PostgreSQL I'd take the latest base backup from before 2:15pm, restore it to a new server, set restore_command to fetch the archived WAL, set recovery_target_time to 2:15pm, create a recovery.signal file and start it. It replays WAL up to that point. I'd restore to a separate server rather than over production, check the data with the team and then decide whether to switch over or just copy back the rows we lost. With pgBackRest the same thing is one restore command with a target time.

  2. What are SQL Server's recovery models and how do they affect backups?

    Why they ask

    A standard SQL Server question. Getting it wrong means you might not be able to recover to a point in time.

    How to answer

    Name SIMPLE, FULL and BULK_LOGGED and say which allows log backups and point-in-time restore.

    Show a sample answer

    SIMPLE truncates the log automatically, so there are no log backups and you can only restore to a full or differential backup. FULL keeps the log until you back it up, which allows point-in-time restores but means you must schedule log backups or the log grows until the disk fills. BULK_LOGGED reduces logging for bulk operations, but you may not be able to restore to a point in the middle of one.

  3. What does EXPLAIN ANALYZE do, and what's the risk of using it?

    Why they ask

    Reading plans is core to tuning, and the risk catches people out.

    How to answer

    Explain that it runs the query and shows the real plan with actual rows and timings next to the estimates. Then mention that it executes data-changing statements too.

    Show a sample answer

    EXPLAIN shows the planner's estimated plan. EXPLAIN ANALYZE actually runs the query and shows real row counts and time for each step, so I can see where estimates are wrong and where the time goes. The risk is that it really executes, so for an UPDATE or DELETE I wrap it in BEGIN and ROLLBACK. On a slow query in production, I also remember that running it means waiting for the slow query.

  4. You have an index on (customer_id, created_at). Will a query filtering only on created_at use it?

    Why they ask

    Composite index column order is a basic tuning concept many developers get wrong.

    How to answer

    Explain the leftmost prefix rule, then add the modern nuance about skip scans.

    Show a sample answer

    Usually not efficiently. A B-tree on (customer_id, created_at) is sorted by customer first, so a filter on created_at alone can't jump straight to the rows. PostgreSQL 18 added skip scan, which can use it when customer_id has few distinct values, and MySQL 8.0 has a similar skip scan, but I wouldn't rely on it. If that query matters, I'd add an index starting with created_at or check if the existing one should be reordered.

  5. What is VACUUM in PostgreSQL and why does it matter?

    Why they ask

    Autovacuum problems cause bloat, slow queries and, in the worst case, transaction ID wraparound. Every PostgreSQL DBA must know this.

    How to answer

    Explain MVCC leaves dead row versions, VACUUM makes that space reusable and protects against transaction ID wraparound, and the difference with VACUUM FULL.

    Show a sample answer

    Because of MVCC, an UPDATE or DELETE leaves the old row version behind. VACUUM marks that space as reusable, updates the visibility map and freezes old transaction IDs so we don't hit wraparound. Autovacuum does this automatically, but on busy tables I often tune it to run more often. VACUUM FULL rewrites the whole table and returns space to the operating system, but it takes an exclusive lock, so I'd avoid it on a busy production table and look at pg_repack instead.

  6. Explain the difference between synchronous and asynchronous replication.

    Why they ask

    Replication choices decide how much data you can lose in a failover.

    How to answer

    Explain when a commit is confirmed in each mode, and the trade-off between data safety and latency.

    Show a sample answer

    With asynchronous replication, the primary confirms a commit as soon as it's written locally, and the replica catches up shortly after. It's faster, but if the primary dies you can lose the last few transactions. With synchronous replication, the primary waits for at least one replica to confirm before telling the application the commit succeeded, so no confirmed data is lost, but every write is slower and if the synchronous replica goes down, writes can stall. Many teams run one synchronous replica nearby and others asynchronous.

  7. A developer needs a new index on a 500-million-row table that's busy all day. How do you add it?

    Why they ask

    Online changes without downtime are daily DBA work in busy systems.

    How to answer

    Name the online option for your engine and its caveats, and say you'd test and schedule it.

    Show a sample answer

    In PostgreSQL I'd use CREATE INDEX CONCURRENTLY, which doesn't block writes. It takes longer, can't run inside a transaction block, and if it fails it leaves an invalid index I'd need to drop and retry. In SQL Server Enterprise edition I'd use WITH (ONLINE = ON). Either way I'd test on a copy first to estimate the time and disk needed, and run it at the quietest time for the users, not just the quietest time in Lagos.

  8. What causes a deadlock, and how do you deal with them?

    Why they ask

    Deadlocks show up in every busy application. They want to know you can find and prevent them.

    How to answer

    Explain two transactions each holding a lock the other needs, how the database resolves it, and how to find and prevent the pattern.

    Show a sample answer

    A deadlock is when transaction A holds a lock B needs, and B holds a lock A needs. The database detects it and cancels one of them. I'd find the queries involved from the logs, the deadlock graph in SQL Server or the deadlock details in the PostgreSQL log, and usually fix it by making both code paths lock rows in the same order, keeping transactions short and adding indexes so updates lock fewer rows.

  9. How do you set up access for a new application that needs to read and write one schema?

    Why they ask

    Least privilege is basic security, and over-privileged accounts cause real breaches.

    How to answer

    Describe a dedicated role, grants on only what's needed, no superuser or owner rights, secrets stored properly and logging.

    Show a sample answer

    I'd create a dedicated login role for that application, grant USAGE on the schema and only SELECT, INSERT, UPDATE and DELETE on its tables, with default privileges so new tables are covered. No superuser, no ownership of the tables and no access to other schemas. The password goes into the team's secrets manager, not a config file in the repo, and connections go over TLS.

  10. We're moving an on-premises SQL Server to Azure. How would you choose between Azure SQL Database and Managed Instance?

    Why they ask

    Cloud migrations are a large part of remote DBA work, especially in Microsoft shops.

    How to answer

    Talk about compatibility needs (SQL Agent, cross-database queries, CLR), how much control they need, and how you'd migrate with little downtime.

    Show a sample answer

    Managed Instance is closer to full SQL Server, with SQL Agent jobs and cross-database queries, so it suits a lift-and-shift of an existing estate. Azure SQL Database suits a single database for a newer app that doesn't need those features. I'd run an assessment of the current databases for compatibility issues first, then migrate with an online method such as Azure Database Migration Service so the cutover window is short, and test the restore and failover on the new platform before go-live.

Behavioural questions

Past situations. Answer with a real example: what happened, what you did, what changed.

  1. Tell me about a database incident you caused or handled, and what you changed afterwards.

    Why they ask

    Every DBA has broken something. They want honesty and evidence that you learn.

    How to answer

    Tell a real story briefly: what happened, how you found and fixed it, how you communicated, and the process change you made.

    Show a sample answer

    At a Lagos fintech I ran a migration that added a column with a default to a large table on an older PostgreSQL version. It locked the table and payments failed for about four minutes. I cancelled it, told the team in the incident channel and re-ran it later in smaller steps. Afterwards I added a migration checklist to our pull request template: table size, lock type and a test run on a copy of production.

  2. How do you work with developers who want to move fast?

    Why they ask

    DBAs who only say no slow teams down. They want someone who protects the database and helps the team ship.

    How to answer

    Talk about reviewing migrations early, giving safer alternatives, writing guidelines and automating checks.

    Show a sample answer

    I try to get involved early instead of being a gate at the end. I review migrations in pull requests, and when something's risky I suggest a safer version, like adding the index concurrently. I've also written a short guide for developers on safe schema changes and added automated checks in CI so the obvious problems get caught before I even see them.

Situational questions

Hypotheticals about problems you'd meet in the job.

  1. A query that ran in 200 milliseconds yesterday takes 30 seconds today. How do you investigate?

    Why they ask

    Plan changes and regressions are common incidents. They want a structured approach.

    How to answer

    Check whether something changed (deploy, data volume, statistics, plan), whether it's waiting on locks, and compare plans. Fix the cause, not just the symptom.

    Show a sample answer

    First I'd check if it's slow or blocked: in PostgreSQL I'd look at pg_stat_activity and locks to see if it's waiting. If it's really slower, I'd compare the plan now with the expected one. Common causes are stale statistics after a big data load, so I'd run ANALYZE on the table, a new deploy changing the query, or data growth pushing the planner to a different plan. In SQL Server I'd also check Query Store for a plan change and parameter sniffing.

  2. Someone ran a DELETE without a WHERE clause on a production table. What do you do?

    Why they ask

    Shows how you act in a real data-loss incident: calm, fast and in the right order.

    How to answer

    Stop further damage, communicate, work out the exact time, then recover from backups to a separate server and restore only what's needed.

    Show a sample answer

    First I'd make sure it's not still running or about to be repeated, and tell the incident channel what happened and that I'm on it. I'd find the exact time from the logs. Then I'd do a point-in-time restore to a separate server, to just before the delete, and copy the missing rows back into production, rather than rolling the whole database back and losing everyone else's changes since. Afterwards I'd write it up and suggest fixes like removing direct write access to production for that account.

  3. You're on call and get paged at 2am: the database disk is 92% full. What do you do?

    Why they ask

    On-call judgement matters. A full disk can take the database down.

    How to answer

    Buy time safely first, then find the cause. Mention the usual suspects for your engine.

    Show a sample answer

    First I'd buy time: on a cloud database I'd increase the storage, and on a server I'd check for files I can safely clear, never the WAL or transaction log directories by hand. Then I'd find what's growing. In PostgreSQL the usual causes are WAL piling up because archiving is failing or an old replication slot is holding it, a huge temp file from a bad query, or table bloat. In SQL Server, often a transaction log that isn't being backed up. Once it's stable I'd write it up and add an alert at 80%.

Remote work questions

How you'll work from Nigeria with a team elsewhere: hours, power, internet, communication.

  1. This role includes on-call for a US team. How do you make sure you're reachable and reliable?

    Why they ask

    On-call from Nigeria raises fair questions about power, internet and time zones.

    How to answer

    Give specifics on backup power, connectivity, alerting and how you'll manage sleep.

    Show a sample answer

    US Eastern is five or six hours behind Lagos, so their evening incidents are my night. My laptop and router run on an inverter with solar that lasts through the night, and I have fibre plus a MiFi on a different network. PagerDuty alerts go to my phone at full volume. On on-call weeks I keep my evenings light, and if I'm ever going to be unreachable I arrange cover in advance and tell the team.

Remote interview tips

Have a lab to screen-share. A running Docker setup with PostgreSQL and a replica, or a SQL Server instance with a sample database, lets you show a plan or a restore live if asked.

Talk through your reasoning. On scenario questions, say what you'd check first and why. Interviewers want to hear a safe order of actions more than a perfect answer.

Bring a real incident story. Have one incident you handled and one mistake you made, each with a clear fix and lesson. DBA interviews almost always ask.

Write times in both zones. Reply with "10am EST / 4pm WAT" or "2pm BST / 2pm WAT", and double-check around the March, October and November clock changes in the UK and US.

Be ready for the trust questions. Expect questions on how you handle production access, secrets and personal data. Answer with specifics: least privilege, secrets managers, audit logs and never copying production data to a personal laptop.

Questions people ask

What questions are asked in a DBA interview?

Mostly backups and point-in-time recovery, replication and failover, indexing and query plans, locking and deadlocks, security and access, plus scenarios like a full disk or an accidental delete. Expect at least one question about a real incident you handled.

Do DBA interviews include a practical test?

Often. Common tasks are reading an execution plan and suggesting a fix, tuning a slow query, reviewing a schema migration for risks, or describing a restore step by step. Some employers ask you to share your screen in a lab.

Which database should I talk about in an interview?

The one in the job ad, mapped from what you know. If you know PostgreSQL and they run SQL Server, explain the concept, then say how it works in each engine. Honesty about which one you've used in production is better than bluffing.

Do remote DBA interviews ask about DevOps skills?

Increasingly, yes. Many remote roles expect Terraform, CI/CD, Linux scripting and monitoring with Prometheus, Grafana or Datadog, and some are titled database reliability engineer or platform engineer instead of DBA.

Updated October 2026 by the WorkRemote careers team

Share or discuss this guide