Database Engineer interview questions and practice.
Engineers database platforms with automation, cloud services and reliability practices rather than manual administration.
No card for the taster. Full interviews are paid one at a time. Nothing renews.
Last reviewed
This page is still being written: no authored question bank for this competency family. The role is fully supported in the interview itself; only the published question bank is outstanding.
What interviewers for Database Engineer actually ask
The question bank for this role is still being written. These are the first three competencies in the model the interview is scored against.
Diagnoses slow queries and database bottlenecks from execution plans, wait statistics and metrics, and fixes them at the right layer (index, query, schema, configuration).
Designs and tests backup and recovery to meet RPO/RTO, operates high-availability and replication, and can recover from corruption, deletion or site loss.
Controls access with least privilege, encrypts and audits sensitive data, and supports compliance with POPIA/GDPR and audit requirements.
What they are really assessing
Interviewers rarely score whether you seemed nice. They score against a model like this one, usually without telling you it exists. Each competency has a weak, adequate and strong shape, and the difference is almost always the level of specific detail you volunteer without being asked.
Query & database performance tuning
Diagnoses slow queries and database bottlenecks from execution plans, wait statistics and metrics, and fixes them at the right layer (index, query, schema, configuration).
- Weak
- Performance fixes are 'add an index' or 'add RAM'; cannot read an execution plan or explain waits, locking or parameter sniffing.
- Adequate
- Reads plans and wait stats, has fixed slow queries with indexing or rewrites, but cannot give before/after numbers or explain when not to add an index.
- Strong
- Gives a specific case: the symptom, the plan or wait analysis, the root cause (missing index, implicit conversion, blocking, bad statistics), the fix chosen over alternatives, and measured improvement.
Backup, recovery & high availability
Designs and tests backup and recovery to meet RPO/RTO, operates high-availability and replication, and can recover from corruption, deletion or site loss.
- Weak
- Backups exist but restores have not been tested; cannot state RPO/RTO or describe a real recovery; HA is 'we have a replica'.
- Adequate
- Tests restores periodically, operates HA (Always On, Patroni, replication) and has performed a point-in-time recovery, but failover has not been exercised under load.
- Strong
- Describes a real recovery (corruption, accidental delete, failed failover) with timeline and data loss, the restore drill programme, and how the HA design and monitoring changed as a result.
Database security & data protection
Controls access with least privilege, encrypts and audits sensitive data, and supports compliance with POPIA/GDPR and audit requirements.
- Weak
- Applications connect as sysadmin; developers have production access; cannot describe auditing or encryption of personal data.
- Adequate
- Applies role-based access, encryption at rest and in transit, and auditing, but access reviews are irregular and masking in non-production is incomplete.
- Strong
- Describes tightening access with measured reduction in privileged accounts, masking or anonymising personal data for non-production, and handling an audit or data subject request with evidence.
Schema design & safe change management
Advises on data modelling and indexing, and deploys schema and data changes to production safely with review, testing and rollback.
- Weak
- Runs whatever scripts developers send; cannot describe a schema change that locked a table or broke an application, or how to make changes online.
- Adequate
- Reviews changes for locking and performance, uses migration tooling and rollback scripts, but large table changes still cause downtime.
- Strong
- Describes an online schema change on a large table with the technique used, a change they blocked and why, and how they built a review and deployment process that reduced incidents.
Monitoring, capacity & automation
Keeps databases observable, forecasts growth and resource needs, and automates routine administration.
- Weak
- Finds out about problems from users; disk full incidents recur; routine tasks are manual.
- Adequate
- Has monitoring and alerting on key metrics and forecasts storage growth, and has scripted routine tasks, but alerts are noisy and capacity planning is short-term.
- Strong
- Describes a monitoring redesign that caught issues earlier with reduced noise, a capacity forecast that drove a decision before an outage, and automation with measured time saved.
Incident handling & root-cause analysis
Restores database service quickly under pressure, communicates clearly, and drives root-cause fixes rather than repeating firefights.
- Weak
- Incidents are resolved by restarting the instance; cannot describe root cause or a follow-up that prevented recurrence.
- Adequate
- Follows an incident process and finds root cause for most incidents, but follow-up actions are not always completed and communication is uneven.
- Strong
- Gives a specific incident with timeline, the mitigation decision and its trade-off, the root cause, stakeholder updates, and the completed action with evidence it prevented recurrence.
Partnering with developers & application owners
Works with developers as a partner: reviews designs early, explains database behaviour, and enables safe self-service rather than gatekeeping.
- Weak
- Sees developers as the source of problems; interactions are refusals or after-the-fact fixes; cannot describe teaching a team to write better queries.
- Adequate
- Reviews designs when asked and explains performance issues, but engagement is reactive.
- Strong
- Describes getting involved early in a design with a measured effect, training or tooling that reduced bad queries, and a disagreement with developers resolved with evidence.
Reading the questions is the easy half. Try answering three of them out loud, to someone who follows up.
Try 5 minutes freeWhat your 30 minutes covers
The same shape as a real first-round interview, pitched at mid-level Database Engineer and scored throughout.
Warm-up, then Motivation & fit
Build rapport, settle nerves, and get a short walk-through of your background. Why this role, why this employer, and what you are actually looking for.
Your experience
Two or three real situations from your CV in depth: context, what you did, what happened, what you would change.
Pitched at mid-level scope: owns a set of database environments: performance, availability, security, changes and incidents.
Role-specific questions
The core competencies and domain knowledge for the role, with follow-ups on anything vague.
Drawn from this role's domain: reading an execution plan and fixing a slow query, index design: when to add, when not to, and covering indexes and diagnosing blocking, deadlocks and lock escalation, and the rest of the competency model.
Your questions, then Wrap-up
Your questions for the interviewer, and yes, they are assessed. Next steps and a clean finish.
What changes with seniority
The questions barely change between levels. What changes is the answer they will accept.
| Junior | Mid | Senior | |
|---|---|---|---|
| Scope of ownership | Owns routine administration (backups, user access, basic tuning) with review; first response to alerts. | Owns a set of database environments: performance, availability, security, changes and incidents. | Owns database architecture and standards across the organisation; accountable for availability, performance, security and capacity. |
| Tolerance for ambiguity | Handles defined tasks and escalates unusual situations promptly. | Diagnoses unfamiliar problems independently and plans changes with risk assessment. | Designs solutions from business needs; makes platform and HA decisions with incomplete information. |
| People leadership | No formal leadership. | Mentors juniors and reviews their changes. | Technical lead for DBAs, runs on-call, mentors, reviews designs. |
| Who they deal with | Own team, developers, service desk. | Development teams, application owners, infrastructure, security. | IT and development leadership, security, auditors, vendors. |
What your report would say
Every competency above scored from your own answers, the sentence that cost you quoted back, and your weakest answers rewritten the way a strong Database Engineer would have said them.
- Describes tightening access with measured reduction in privileged accounts, masking or anonymising personal data for non-production, and handling an audit or data subject request with evidence.
The format, not a result. Scores on your report come from what you actually said.
Is the AI interviewer realistic? See a full sample report