Free database administrator (DBA) interview questions for small businesses: 6 sets on backups, security, and tuning, plus a scorecard. Download as DOCX.
40 interviewer questions across five competency sets, each with what a strong answer sounds like, plus a 1-to-5 scorecard and a red-flag checklist. Built for small businesses hiring a DBA without an HR department or a second database person. Download as DOCX.
The first time I sat across from a database administrator candidate, I had no business grading half of what he said. He talked about replication topologies for ten minutes, I nodded, and I very nearly hired him. Then somebody suggested I ask when he had last restored a backup. He had not, in four years. That one question changed the whole conversation, and it changed how I interview for technical roles I cannot personally do.
At FirstHR, we build for small businesses hiring without an HR department, where the owner is often the only interviewer and there is no second database person to check the answers. This page gives you 40 employer-side questions across five competency sets, each with what a strong answer sounds like, plus a scorecard and a red-flag checklist. The matching database administrator job description covers the posting side.
TL;DR
Interview a DBA on five things: platform fit, backup and recovery, performance method, security and access, and behavior under pressure. The single highest-value question needs no technical background: how do you know a backup would actually restore? Weight recovery and security above tuning for a sole DBA, ask every candidate the same core questions, and score each area 1 to 5 with written evidence. Download six question sets and the scorecard as DOCX.
What a DBA Actually Owns
A database administrator keeps your existing databases available, fast, secure, and recoverable. That means backups and tested restores, access control, patching, monitoring, capacity, and performance tuning. It does not usually mean building the data model or the reporting pipelines, which is why the interview should follow the problem you actually have rather than a generic technical script.
The distinction matters when you write the questions. If your pain is downtime, slow queries, or a backup nobody has ever restored, you want a DBA. If your pain is that data sits in five systems and nobody can report across them, the questions on our data engineer interview questions page fit better. If the work is mostly building schemas and queries inside the database, start from the database developer job description instead.
Responsibility
DBA
Database Developer
Data Engineer
Owns backups, restores, and recovery objectives
Grants and reviews database access
Patches the engine and monitors uptime
Writes schemas, queries, and stored procedures
Builds pipelines between systems for analysis
At a small business one person frequently covers parts of all three, and that is fine as long as you know which part is the reason you are hiring. Decide that first, then weight the question sets accordingly. For a sole DBA, recovery and security outrank everything else.
The Six Question Sets
The 40 questions below are grouped into five competencies plus a scorecard. A strong candidate should hold up across all five, not only on the platform trivia they have rehearsed. Ask at least four questions from every set you use, and use the same sets for every candidate for the role.
Experience and Environment
Does their history match yours?
Which platforms they have run, at what scale, alone or on a team, on premises or managed cloud. Filters out strong candidates who are strong somewhere else.
Backup and Recovery
The set that matters most
Restore testing, recovery objectives, point in time recovery, and protecting backups. Everything else can be fixed next week; a failed restore cannot.
Performance and Troubleshooting
Method, not trivia
How they diagnose a slow morning, find expensive queries, and choose between tuning, indexing, and hardware. You are grading the sequence.
Security and Access
They hold every key
Least privilege, individual accounts, masking personal data in test copies, patching, and offboarding. A casual answer here is disqualifying.
Behavioral and On-Call
How they act at 2 a.m.
STAR questions on outages, saying no, inheriting a mess, and explaining risk to a non technical owner who has to make the call.
Scorecard and Red Flags
Score, do not guess
A 1 to 5 rubric per competency plus an eight point red flag checklist, so the decision rests on evidence instead of on who interviewed most confidently.
Weight the Sets to Your Actual Risk
Hiring your only DBA: weight backup and recovery and security highest, then behavioral. Adding a DBA to an existing technical team: weight performance and environment fit. Hiring a fractional or contract DBA: weight recovery, security, and communication, and skip the deep platform history. Running mostly on managed cloud services: keep every recovery question, since managed backups still need tested restores, and trade some engine-internals depth for cloud and access questions. When in doubt, start with the experience set and the recovery set.
40 Questions and a Scorecard to Download
Download all six as a single Word document or copy individual sets. Each set follows the same structure: how to use it, the questions with good-answer notes, what a strong answer sounds like, and space for notes. The last file is the scorecard and red-flag checklist.
Download All 6 DBA Interview Files
Experience, recovery, performance, security, behavioral, and a 1-to-5 scoring rubric with red flags. All in one DOCX.
Set 1: Experience and Environment Questions
Which platforms they have administered, at what scale, alone or as part of a team, on premises or in managed cloud services. Start here so you know what you are comparing.
Experience and Environment Questions
DBA INTERVIEW: EXPERIENCE AND ENVIRONMENT
Candidate: __
Business: __
Interviewer: __
Date: _
HOW TO USE THIS SET
Start here with every candidate. These questions map what the person has
actually run against what you actually run. Most bad DBA hires at a small
business are not incompetent; they are experienced somewhere else, on a
platform or a scale that has nothing to do with yours. Ask all of these.
QUESTIONS TO ASK
1. Which database platforms have you administered, and which are you strongest
in today?
(Good answer: names specific engines such as PostgreSQL, MySQL, SQL Server,
or Oracle, and is honest about which one they have run in production most
recently.)
2. Describe the largest environment you have owned: how many instances, how
much data, how many users?
3. Were you the only DBA, or part of a team? What did you personally own?
(Good answer: distinguishes clearly between what they did and what the team
did. Vagueness here is a warning sign.)
4. Was the environment on premises, cloud managed, or a mix? Which cloud?
(Good answer: knows the difference between running the engine themselves and
using a managed service, and what each one takes off their plate.)
5. Walk me through a normal week in your last DBA role.
6. What has been automated in your environments, and what did you still do by
hand?
7. What part of database administration do you like least, and how do you keep
it from slipping?
8. What would you need from us in the first 30 days to be effective?
WHAT A STRONG ANSWER SOUNDS LIKE
A strong candidate is precise and self-aware. They name versions, sizes, and
tools, they separate personal ownership from team ownership, and they say
plainly what they have not done. A candidate who has been one of eight DBAs on
a single large platform may be excellent and still be wrong for a business
where one person owns everything. Listen for breadth plus honesty about gaps.
Weak answers stay generic ("I have worked with all the major databases"),
inflate scale without numbers, or claim strength everywhere.
NOTES
[Record platforms, versions, scale, and what they personally owned.]
Set 2: Backup, Recovery, and Availability Questions
Restore testing, recovery objectives, point-in-time recovery, replication, and protecting backups from ransomware. The most important set on this page and the one generic lists skip.
Backup, Recovery, and Availability Questions
DBA INTERVIEW: BACKUP, RECOVERY, AND AVAILABILITY
Candidate: __
Interviewer: __
Date: _
HOW TO USE THIS SET
This is the set that matters most and the one generic question lists skip.
Everything else a DBA does can be fixed next week. A failed restore cannot.
Ask at least four of these of every serious candidate, and push for specifics.
QUESTIONS TO ASK
1. Walk me through your backup strategy for a business database.
(Good answer: full plus incremental or log backups, an offsite or separate
copy, defined retention, and automated verification.)
2. How do you know a backup would actually restore?
(Good answer: they test restores on a schedule. "The job reports success" is
not an answer. This is the single best question on this page.)
3. Tell me about a time you had to restore production data. What happened?
4. How do you decide recovery time objective and recovery point objective, and
who signs off on them?
(Good answer: treats RTO and RPO as a business decision they help the owner
make, not a number they invent alone.)
5. Someone deletes rows they should not have and nobody notices for two days.
What are your options?
(Good answer: point-in-time recovery, restoring to a side copy, and
reconciling rather than rolling the whole database back.)
6. How do you protect backups from ransomware?
(Good answer: copies that the database account cannot reach or overwrite,
plus tested restores.)
7. What high availability or replication have you set up, and what failed
over badly?
8. How do you document a recovery procedure so someone else could run it?
WHAT A STRONG ANSWER SOUNDS LIKE
A strong candidate talks about restores, not backups. They have a tested
procedure, they know how long a full restore takes because they have timed it,
and they can describe a real recovery they ran, including what went wrong.
They translate RTO and RPO into plain business terms: how much data you can
afford to lose and how long you can afford to be down.
Red flag: a candidate who has never personally tested a restore, or who cannot
say how long one would take.
NOTES
[Record the restore story, the RTO/RPO answer, and how they test.]
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
Set 3: Performance, Tuning, and Troubleshooting Questions
How they diagnose a slow morning, find the expensive queries, choose between tuning and hardware, and explain the tradeoff to somebody who does not write SQL. You are grading the sequence.
Performance, Tuning, and Troubleshooting Questions
DBA INTERVIEW: PERFORMANCE, TUNING, AND TROUBLESHOOTING
Candidate: __
Interviewer: __
Date: _
HOW TO USE THIS SET
Performance work is where a DBA saves you money and where a weak one guesses.
These questions test method, not trivia. You are listening for a diagnostic
sequence you could follow along with, even if you are not technical yourself.
QUESTIONS TO ASK
1. The application is slow this morning and it was fine yesterday. Walk me
through your first hour.
(Good answer: measures before changing anything, checks what changed, looks
at waits, blocking, and the queries actually running.)
2. How do you find the queries that are costing the most?
(Good answer: names real tools such as execution plans, slow query logs, or
built in performance views for their platform.)
3. Explain indexing to me as if I run the business and do not write SQL.
(Good answer: a clear analogy, plus the tradeoff that indexes speed reads
and slow writes and cost storage.)
4. When have you added an index and made things worse?
5. How do you decide between tuning a query, adding an index, and adding
hardware?
(Good answer: tuning first, hardware last, with a reason.)
6. How do you handle a developer whose code is the actual performance problem?
7. What do you monitor day to day, and what alerts do you set?
(Good answer: disk space, replication lag, long running queries, failed
jobs, and backup success, with thresholds rather than everything at once.)
8. Describe the hardest database problem you have solved and how you found it.
WHAT A STRONG ANSWER SOUNDS LIKE
A strong candidate follows evidence: measure, isolate, change one thing, then
measure again. They can explain a technical tradeoff to a non technical owner
without either dumbing it down or hiding behind jargon. They admit the times a
change backfired, which is the clearest sign they have actually done the work.
Weak answers jump straight to "we need a bigger server" or list tools without
a method for using them.
NOTES
[Record their diagnostic sequence and how clearly they explained indexing.]
Set 4: Security, Access, and Compliance Questions
Least privilege, individual accounts, encryption, masking personal data in test copies, patching, and what happens the day an employee leaves. A casual answer here outweighs strong technical answers elsewhere.
Security, Access, and Compliance Questions
DBA INTERVIEW: SECURITY, ACCESS, AND COMPLIANCE
Candidate: __
Interviewer: __
Date: _
HOW TO USE THIS SET
A DBA holds the keys to everything your business knows about its customers and
its employees. Ask these of every candidate, and treat a casual attitude toward
access as disqualifying no matter how strong the technical answers are.
QUESTIONS TO ASK
1. How do you decide who gets access to which data?
(Good answer: least privilege by role, requested and approved by someone
other than the DBA, reviewed on a schedule.)
2. How do you handle the shared administrator password problem?
(Good answer: individual accounts, no shared credentials, and an auditable
record of who did what.)
3. What do you do about sensitive fields such as Social Security numbers,
payment data, or health information?
(Good answer: encryption at rest and in transit, masking in non production
copies, and knowing which rules apply to your industry.)
4. How do you refresh a test environment from production safely?
(Good answer: masks or scrubs personal data first. "We just copy it" is a
real red flag.)
5. What do you do on the day someone leaves the company?
6. Walk me through how you would patch a database engine with a known
vulnerability.
7. Have you supported an audit or a security questionnaire? What did you have
to produce?
8. What would you change about our setup in the first 90 days if security were
your only priority?
WHAT A STRONG ANSWER SOUNDS LIKE
A strong candidate treats access as something granted deliberately and reviewed
regularly, not something handed out to keep people from complaining. They
separate the person who requests access from the person who approves it, they
mask personal data before it leaves production, and they welcome oversight of
their own account rather than resenting it.
Red flag: any version of "it is easier if everyone uses the admin login."
NOTES
[Record their answers on least privilege, masking, and offboarding.]
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
Set 5: Behavioral, On-Call, and Communication Questions
STAR-style questions on outages they caused, saying no to a developer, inheriting a database in bad shape, and translating a technical risk into a business decision the owner can make.
Behavioral, On-Call, and Communication Questions
DBA INTERVIEW: BEHAVIORAL, ON-CALL, AND COMMUNICATION
Candidate: __
Interviewer: __
Date: _
HOW TO USE THIS SET
Evaluate answers with the STAR pattern: Situation, Task, Action, Result. At a
small business the DBA is often the only person who understands the data layer,
so how they behave under pressure and how they explain themselves matter as
much as their tuning skill.
QUESTIONS TO ASK
1. Tell me about a time you caused an outage or lost data. What happened next?
(Good answer: owns it, explains the fix, and describes what changed
afterward so it could not recur.)
2. Describe a time you had to say no to a developer or an executive.
3. How have you handled being paged at 2 a.m.? What is a reasonable on-call
arrangement for you?
4. Tell me about a change you made outside a maintenance window and why.
5. Give an example of explaining a technical risk to someone non technical who
then made the decision.
6. Describe a time you inherited a database that was in bad shape. What did you
fix first?
(Good answer: stabilizes backups and access before anything cosmetic.)
7. How do you keep your skills current on your main platform?
8. What questions do you have about how we run the business?
(Good answer: asks about data volume, growth, who else touches the database,
and what the recovery expectations are.)
WHAT A STRONG ANSWER SOUNDS LIKE
A strong candidate takes ownership of failures without drama, gives real
outcomes rather than philosophy, and can translate a technical risk into a
business consequence so the owner can decide. They ask good questions back.
Someone who has never broken anything in a long career is either very junior or
not being straight with you.
Weak answers blame developers, management, or the previous DBA for everything.
NOTES
[Record the STAR examples and how they explained risk to a non technical owner.]
Set 6: DBA Interview Scorecard and Red Flags
A 1-to-5 rubric across six competencies with a line of evidence each, plus an eight-point red-flag checklist. Use it with any set above so the decision rests on the interview rather than on confidence.
DBA Interview Scorecard and Red Flags
DATABASE ADMINISTRATOR INTERVIEW SCORECARD
Candidate: __
Interviewer: __
Date: __
Score each area from 1 (poor) to 5 (excellent) immediately after the interview.
Write one line of evidence from what the candidate actually said. If more than
one person interviews, score independently before anyone discusses.
SCORING AREAS
Platform fit and relevant experience Score: [ 1 2 3 4 5 ]
Ownership and behavior under pressure Score: [ 1 2 3 4 5 ]
Evidence: __
Communication with non technical people Score: [ 1 2 3 4 5 ]
Evidence: __
RED FLAGS CHECKLIST
[ ] Has never personally tested a restore
[ ] Cannot say how long a full restore would take
[ ] Copies production data into test without masking
[ ] Prefers a shared administrator login
[ ] Jumps to bigger hardware before measuring anything
[ ] Cannot explain indexing in plain language
[ ] Blames developers or the previous DBA for every problem
[ ] Will not give references, or references cannot confirm ownership
SUMMARY
Total score: ______ / 30
Overall recommendation: [ ] Strong yes [ ] Yes [ ] No [ ] Strong no
Key strengths: __
Key concerns: __
Interviewer signature: __
Note: A candidate who scores 5 on tuning and 2 on backup and recovery is not a
strong candidate. Weight recovery and security highest for a sole DBA.
Judging Answers If You Are Not Technical
You do not need to grade the database internals; you need to tell a real operator from a confident talker. Every question in these sets was chosen because it produces an answer a non-specialist can evaluate on method, honesty, and clarity. The four habits below are what actually separate candidates.
Grade the sequence, not the vocabulary
You do not need to know what a wait statistic is. You need to hear a method: measure first, find what changed, isolate the cause, change one thing, measure again. A candidate who describes that sequence for a slow morning is showing you how they will behave on a real incident. One who opens with a solution before asking a single diagnostic question is guessing, and guessing on your production database is expensive. Ask them to walk you through the first hour and simply follow along. If you cannot follow it at all, that is information too, because you are the person they will have to explain outages to.
Ask for the plain-language version
The indexing question on this page exists for exactly this reason: explain indexing to me as if I run the business and do not write SQL. A strong candidate reaches for an analogy, then names the tradeoff, that indexes make reads faster while making writes slower and using more storage. This tests two things at once. It confirms they actually understand the concept, because you cannot simplify what you do not know, and it shows whether they can give you the information you need to make a business decision. A DBA who cannot do this will leave you approving changes you do not understand.
Use restore testing as your one hard filter
If you take one question from this page, take this one: how do you know a backup would actually restore? It requires no technical background to grade. A strong answer describes a schedule of test restores, a known duration for a full recovery, and a real story about a restore that did not go to plan. A weak answer says the backup job reports success, which is not the same thing and is the reason businesses discover their backups were useless on the worst possible day. This single question separates candidates faster than any tuning puzzle.
Borrow a technical second opinion
If nobody in the business writes SQL, bring in a trusted contractor, your managed service provider, or a developer you already work with for a 30 minute technical screen, and keep the ownership, security, and communication questions for yourself. Give them your scorecard so their notes come back in the same shape as yours. This is cheap, it is fast, and it is far better than either skipping the technical depth or pretending you can assess it. Score independently, then compare, so their confidence does not simply overwrite your judgment.
Two practical notes. Write down the exact answer to the restore question while it is fresh, because it is the one you will weigh most later. And if you bring in a contractor for a technical screen, give them the same scorecard, then score independently before you compare, so their confidence does not simply replace your judgment.
What to Probe For (and Red Flags)
The listed questions open the door; the follow-ups tell you who you are hiring. Push for the number, the date, the specific incident. A candidate who has genuinely done this work will have those details ready, and one who has watched other people do it will not.
Signals of a real operator
Names versions, sizes, and tools without prompting
Has timed a full restore and knows the number
Separates what they owned from what the team owned
Follow-ups that pay off
"When did you last test that restore?"
"What went wrong the first time you tried it?"
"What would you check before changing anything?"
Fit for a small business
Comfortable being the only person who owns the data layer
Can work with managed cloud services, not just bare metal
Explains a tradeoff to an owner who does not write SQL
Red flags
Never personally tested a restore
Copies production into test without masking
Reaches for bigger hardware before measuring
The most useful follow-up on this page is when did you last do that? Applied to restore testing, access reviews, or patching, it turns a policy statement into a fact you can check with a reference call.
How to Run the Interview
Run it the same way for every candidate: prepare the sets, ask the same core questions, score immediately, and decide from written evidence. The sequence below works whether you are the only interviewer or you are pairing with a contractor for the technical depth.
Step
What to do
1. Define the need
Decide whether the pain is uptime, performance, security, or reporting
2. Pick and weight the sets
Recovery and security first for a sole DBA; performance for a team addition
3. Map the environment
Open with platforms, scale, and what they personally owned
4. Test recovery
Restore testing, recovery objectives, and one real recovery story
5. Grade the method
Walk through a slowdown; listen for measure, isolate, change, measure
6. Probe access
Least privilege, individual accounts, masking, and offboarding
7. Score and reference
Rubric with evidence, then confirm ownership of backups with referees
Score right after each conversation while the wording is still fresh, and keep the completed rubrics with the rest of the hiring record rather than in somebody’s notebook. Those scores are what turn a set of impressions into an interview feedback step you can explain to a co-founder a month later.
Database Administrator Pay
Database administrator pay varies widely by platform, scale, location, and whether the role is full-time or fractional. Use federal wage data as your baseline, then adjust for your market and for how much of the data layer the person will own.
Median $104,620 a Year (BLS OEWS, May 2025)
Database administrators (SOC 15-1242) had a median annual wage of $104,620, about $50.30 an hour, according to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025). The lowest 10 percent earned $60,230 or less and the highest 10 percent $163,320 or more, with the 25th percentile at $79,610 and the 75th at $135,460. Employment of database administrators and architects is projected to grow 4 percent from 2024 to 2034, with roughly 7,800 openings a year (U.S. Bureau of Labor Statistics).
That spread is wide because the occupation covers everything from a junior administrator on a managed cloud service to a specialist running large on-premises systems. Many small businesses do not need a full-time hire at all: a fractional DBA on a monthly retainer, or a managed database service that handles patching and automated backups, often covers the need. Interview a fractional candidate with the same sets, and if the scope is closer to architecture than to operations, benchmark against the senior database engineer scope instead.
Fair, Legal, and Structured Interviewing
Fair, legal, and structured are the same thing in practice. Asking every candidate the same job-related questions and scoring them the same way keeps you compliant, reduces bias, and produces better hires at once. Technical interviews need this more than most, because they drift toward whatever the interviewer enjoys discussing.
Ask about the job, not the person
Federal anti-discrimination law, enforced by the EEOC, prohibits basing hiring decisions on protected characteristics, and questions that probe them create risk even when they are asked as small talk. Avoid age, race, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. Technical interviews drift into this territory in a specific way: asking when someone started working with a given database, or which version they first learned on, can function as a proxy for age. Ask what they have run recently and what they can run for you instead. Keep every question tied to the ability to administer your databases. This is general information, not legal advice.
Ask every candidate the same core questions
A structured interview, where every candidate faces the same questions scored against the same rubric, predicts on-the-job performance better than a free-flowing conversation and reduces the chance that a decision rests on rapport rather than evidence. This matters more than usual for a DBA hire, because technical conversations wander toward whatever the interviewer happens to enjoy talking about, and two candidates end up assessed on completely different material. Pick your sets in advance, ask the same core questions of everyone, and score them the same way. The downloadable sets and scorecard here are built to make that the path of least resistance.
Score independently, then discuss
When more than one person interviews, have each interviewer complete the scorecard alone before the group talks. Otherwise the most technical voice in the room anchors everyone else, which is how a candidate with impressive platform knowledge and no restore-testing habit gets hired. Compare written evidence first, then discuss the gaps. For a sole DBA role, weight backup and recovery and security above tuning when you total the scores, because those are the areas where a mistake is not recoverable. A rubric filled in independently turns a subjective debate into a decision you can explain later.
Handle background checks and access carefully
A DBA will hold access to customer records, payroll data, and employee files, so many businesses run a background check for the role. If you do, follow the applicable federal and state rules for notice, consent, and adverse action, apply the same policy to every candidate for the role, and do not treat the check as a substitute for asking about access discipline in the interview. Reference calls are the higher-value step for this hire: ask specifically whether the candidate personally owned backups and whether restores were tested. This is general information, not legal advice.
Same Questions, Same Rubric, Better Decisions
A structured interview, where every candidate answers the same questions scored against a consistent rubric, predicts on-the-job performance more reliably than an unstructured conversation, and asking the same job-related questions of everyone also keeps you inside the EEOC rules against deciding on protected characteristics. For a DBA hire the practical trap is asking when someone first learned a platform, which can work as a proxy for age.
Two areas deserve a specific note for this role. Because a DBA will hold access to customer records and employee files, businesses often run a background check; if you do, follow the applicable notice and consent rules and apply the same policy to every candidate for the role. And when you ask the security questions above, the federal guidance you are implicitly testing against is the same advice the FTC gives businesses on protecting personal information. This is general information, not legal advice.
Hiring a DBA Without an HR Department
At a large company this hire goes through a recruiter, a panel of database specialists, and a coordinated scorecard. At a small business the owner usually runs the interview alone, for a role nobody else in the building can assess, and the cost of getting it wrong is measured in downtime and lost data. Here is how to close that gap.
You are hiring one person to be the entire data function
A large company splits this role across a team, so a candidate can be excellent at exactly one slice of it. Your hire has to cover backups, security, performance, patching, and the phone call at 2 a.m., usually while also helping developers and answering the owner’s questions. That changes what you interview for. Breadth and judgment beat depth on any single platform, and the honest candidate who says they have never run replication but has recovered a corrupted database twice is often the better hire. Ask the environment questions first so you know what you are actually comparing.
Nobody in the building can grade the technical answers
Most small businesses hiring a DBA have no other database person to lean on, which is why so many of these hires come down to who sounded most confident. The fix is not to fake technical depth. Use the questions that a non-specialist can grade honestly: how do you know a backup would restore, explain indexing in plain language, walk me through your first hour on a slow morning. Then buy 30 minutes of a trusted contractor’s time for the deep technical screen and give them your scorecard so the notes come back comparable.
The interview is step one; access and onboarding are where the risk lives
The day a DBA starts, they receive more access than almost anyone else you employ. That makes the paperwork and the access checklist part of the hire rather than an afterthought: a signed offer, a confidentiality agreement, documented access grants with individual accounts, and policy acknowledgments alongside the standard new hire forms. FirstHR handles that people side for a small business without an HR department: send the offer for e-signature, run the onboarding workflow and access checklist, and keep the signed documents on the employee profile. FirstHR is an onboarding and HR platform, not a database or monitoring tool, so pair it with those. Applicant tracking is coming soon to FirstHR.
One more thing worth doing for this role specifically: make the reference call a real step rather than a formality. Ask referees two narrow questions, whether the candidate personally owned backups and whether restores were actually tested, and you will learn more than another hour of interviewing would produce. Formal recovery planning guidance, such as the NIST contingency planning guide, is a useful reference for what good looks like here.
From Interview to Onboarding
Once you choose someone, this hire has an onboarding step most roles do not: on day one they receive more access than almost anyone else you employ. Treat the access grant as part of the hire. A signed offer letter, a confidentiality agreement, individual accounts documented against a checklist, and the standard new hire paperwork should all land in the same week.
Pick your sets
Choose the question sets that match the role, weight recovery and security highest for a sole DBA, and use the same core questions for every candidate.
Score on the rubric
Complete the 1 to 5 scorecard right after each interview with one line of evidence per area, independently if more than one person interviews.
Check references, then offer
Ask referees whether the candidate personally owned backups and tested restores, then confirm role, pay, and start date in writing with e-signature.
Onboard with access controls
Grant individual accounts against a documented checklist, sign the confidentiality agreement, and set the first 90 day priorities before anything else.
A confidentiality agreement is worth signing before any credential is issued, not after. Set the first 90 day priorities in writing too: for most small businesses that is tested restores, an access review, and a monitoring baseline, in that order. Browse the rest of our hiring templates if you need the posting, screening, or evaluation pieces as well.
FirstHR connects the offer, the confidentiality agreement, e-signatures, the new hire paperwork, and the access-and-policy checklist in one place, and keeps the signed documents and interview records on the employee profile, so a small business can run this hire from one system. FirstHR is an onboarding and HR platform, not a database, monitoring, or security tool, so connect those separately. Applicant tracking is coming soon to FirstHR.
Keep the Hiring Record Together
Completed scorecards, reference notes, the signed offer, and the access checklist belong in one place rather than across an inbox, a shared drive, and somebody's notebook. That record is what lets you explain a hiring decision later, hand the role over cleanly if the person leaves, and prove during an audit that access was granted deliberately. Applicant tracking is coming soon to FirstHR, and the onboarding, e-signature, and document storage pieces are live today.
Key Takeaways
Assess a DBA on platform fit, backup and recovery, performance method, security and access, and behavior under pressure.
Ask how they know a backup would actually restore; it is the highest-value question and any non-specialist can grade the answer.
Grade the diagnostic sequence, not the vocabulary: measure, isolate, change one thing, measure again.
Treat a casual attitude toward access, shared logins, or unmasked production copies in test as disqualifying.
For a sole DBA, weight recovery and security above tuning, because those mistakes are the ones you cannot undo.
Use BLS OEWS data as a baseline: database administrators reported a median of $104,620 a year in May 2025.
Score every candidate on the same 1-to-5 rubric with written evidence, independently, before anyone discusses.
Frequently Asked Questions
What questions should I ask a database administrator in an interview?
Ask across five areas: platform experience, backup and recovery, performance and troubleshooting, security and access, and behavior under pressure. The highest-value questions are how do you know a backup would actually restore, walk me through your first hour when the application is slow this morning, explain indexing as if I run the business and do not write SQL, how do you refresh a test environment from production safely, and tell me about a time you caused an outage. Each of those is gradeable by a non-specialist because you are listening for method and honesty rather than for a correct textbook answer. Open with the environment questions so you know whether the candidate has run something comparable to what you run. This page groups 40 such questions into five downloadable sets, with a sixth file holding the scorecard, and each question carries a note on what a strong answer sounds like.
What is the single most important question to ask a DBA candidate?
How do you know a backup would actually restore. Everything else a database administrator does can be corrected the following week, but a failed restore during a real incident cannot be undone, and it is the failure mode that ends small businesses. A strong answer describes test restores on a schedule, a known duration for a full recovery because they have timed it, and a real story about a restore that did not go to plan and what they changed afterward. A weak answer says the backup job reports success, which only confirms that a file was written. Follow up with how long a full restore would take and who decides how much data the business can afford to lose. No technical background is needed to tell those two answers apart.
How do I interview a DBA if I am not technical myself?
Grade the method rather than the vocabulary. Ask the candidate to walk you through the first hour of a slowdown and listen for a sequence you can follow: measure first, find what changed, isolate the cause, change one thing, measure again. Ask them to explain indexing in plain language, which tests both real understanding and their ability to give you the information you need to make decisions. Use restore testing as a hard filter because it is gradeable by anyone. Then buy 30 to 60 minutes from a trusted contractor or your managed service provider for the deep technical screen, hand them the same scorecard, and have both of you score independently before comparing notes. Keep the ownership, security, and communication questions for yourself.
What are the red flags in a database administrator interview?
The clearest red flags are: never having personally tested a restore, being unable to say how long a full restore would take, copying production data into a test environment without masking personal information, preferring a shared administrator login over individual accounts, reaching for bigger hardware before measuring anything, being unable to explain indexing in plain language, and blaming developers or the previous DBA for every problem. Vagueness about scale and ownership is another one: a candidate who cannot say how many instances they ran or what they personally owned as opposed to what their team owned is usually inflating. A candidate who claims never to have broken anything in a long career is either very junior or not being straight with you. The scorecard on this page includes an eight-point red-flag checklist.
How much does a database administrator cost to hire?
According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), database administrators had a median annual wage of $104,620, roughly $50.30 an hour. The lowest 10 percent earned $60,230 or less and the highest 10 percent earned $163,320 or more, with the 25th percentile at $79,610 and the 75th at $135,460. That spread is wide because it covers everything from a junior administrator on a managed cloud service to a specialist running large on-premises systems. Budget the salary plus benefits and overhead for a full-time hire, and remember that many small businesses do not need one: a fractional or contract DBA on a monthly retainer, or a managed database service that handles patching and backups, often covers the need at a fraction of the cost. This is general information, not financial advice.
Does a small business need a full-time DBA?
Often not. Managed cloud database services handle patching, automated backups, and failover, which removes a large share of the traditional DBA workload, and many small businesses run comfortably with a developer who knows enough database work plus a contractor on call. The signals that you need a dedicated person are real data volume, database performance that is now a business problem rather than an annoyance, regulatory or contractual obligations around customer data, and a recovery expectation that nobody currently owns. A common middle path is a fractional DBA for a set number of hours each month, which buys you the discipline of restore testing and access reviews without a full-time salary. Interview a fractional candidate with the same question sets, weighting recovery, security, and communication highest.
What is the difference between a DBA, a database developer, and a data engineer?
A database administrator keeps existing databases available, fast, secure, and recoverable: backups and restores, access control, patching, monitoring, and performance tuning. A database developer builds inside the database, writing schemas, queries, stored procedures, and the data model an application depends on. A data engineer builds pipelines that move and transform data between systems so it can be analyzed, and usually works with warehouse and streaming tools rather than owning production uptime. The roles overlap at a small business, where one person often does parts of all three, but the interview should follow whichever problem you actually have. If your pain is downtime, slow queries, or an untested backup, you want a DBA. If your pain is that data is trapped in five systems and nobody can report on it, you want a data engineer.
What questions are illegal to ask in a DBA interview?
Avoid any question that probes a characteristic protected under federal law, which the EEOC enforces: age, race, color, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. Technical interviews drift into this in one particular way, so watch for it: asking when a candidate started working with a given database, or which version they first learned on, can operate as a proxy for age. Ask what they have run recently and what they can run for you instead. You may ask whether someone can perform the essential functions of the job, including any on-call expectation stated up front, and whether they are legally authorized to work. Asking the same job-related questions of every candidate is the simplest way to stay both fair and defensible. This is general information, not legal advice.
