4) Technical and professional questions (where offers are won)
This is the part where interviewers separate “can run scripts” from “can run production.” Expect them to probe your depth in backup/restore, HA/DR, performance, security, and cloud operations. If the role is labeled SQL DBA or Oracle DBA, they’ll go deeper into that ecosystem—tooling, internals, and the ugly edge cases.
Q: Explain your backup strategy for a mission-critical OLTP database. How do you prove restores work?
Why they ask it: Backups are meaningless until you’ve restored under pressure.
Answer framework: “RPO/RTO-first” (define targets → design backups → test restores → monitor).
Example answer: “I start by confirming RPO and RTO with the business, not guessing. Then I design full + differential + log backups (or snapshots plus logs, depending on platform) and store them in separate fault domains with encryption. The proof is automated restore testing: nightly restores to a non-prod environment, plus periodic point-in-time restore drills. I monitor backup success, duration, and restore time trends so we catch drift before an emergency.”
Common mistake: Listing backup types without mentioning restore testing and measurable RPO/RTO.
Q: How do you troubleshoot a sudden spike in query latency? What do you check first?
Why they ask it: They want a disciplined triage order, not random tuning.
Answer framework: “Top-down triage” (platform health → waits/locks → query plans → data changes).
Example answer: “First I check platform signals: CPU steal, memory pressure, storage latency, network, and whether we had a deployment. Next I look for blocking and deadlocks—often the fastest win is identifying a single session holding locks. Then I review top waits and the worst offenders by duration and reads, and compare execution plans to yesterday to see if stats or parameter sniffing changed behavior. If it’s data growth, I validate indexes and stats maintenance. I only change indexes after I’ve identified the dominant bottleneck.”
Common mistake: Jumping straight to ‘add an index’ without confirming the bottleneck or plan regression.
Q: What’s the difference between high availability and disaster recovery, and how have you implemented both?
Why they ask it: They’re testing architecture thinking and risk tradeoffs.
Answer framework: Compare–Contrast + one concrete implementation.
Example answer: “High availability is about minimizing downtime for common failures—node loss, instance crash—usually within a region. Disaster recovery is about surviving regional loss or major corruption, so it’s a different fault domain and often a different runbook. In one environment we used synchronous replication for HA within the region and asynchronous replication to a second region for DR, with quarterly failover tests. We documented cutover steps, DNS/app config changes, and data validation checks.”
Common mistake: Treating HA and DR as the same thing because ‘we have replicas.’
Q: For a SQL DBA role: how do you handle index maintenance and statistics to avoid regressions?
Why they ask it: SQL Server performance lives and dies on stats, fragmentation, and plan stability.
Answer framework: “Policy + exceptions” (baseline policy → thresholds → workload-aware scheduling).
Example answer: “I set a baseline policy: update stats with a sensible sampling strategy, rebuild or reorganize based on fragmentation and page count thresholds, and schedule around peak workload. But I’m careful with blanket rebuilds—they can bloat logs and hurt the buffer cache. I prefer targeted maintenance driven by usage and performance data, and I validate with Query Store to catch regressions. If we see parameter sniffing issues, I’ll consider plan guides, recompile hints, or query rewrites—case by case.”
Common mistake: Saying ‘rebuild all indexes weekly’ like it’s a universal best practice.
Q: For an Oracle DBA role: how do you approach performance tuning—AWR/ASH, wait events, and SQL plan management?
Why they ask it: Oracle tuning has its own language; they want to know you speak it.
Answer framework: “Evidence chain” (symptom → AWR/ASH → top waits → SQL IDs → plan actions).
Example answer: “I start with the symptom window and pull AWR to see top wait events and load profile changes. Then I use ASH to pinpoint which sessions and SQL IDs drove the spike, and whether it’s CPU, I/O, or contention. For the worst SQL, I review execution plans and cardinality estimates, and I’ll fix stats, indexes, or rewrite the SQL. If plan instability is the issue, I’ll use SQL Plan Baselines/SPM to stabilize while we work on a durable fix.”
Common mistake: Talking only about ‘adding indexes’ without referencing Oracle’s diagnostic workflow.
Q: How do you design role-based access control for databases in a way that passes audits?
Why they ask it: In the US, audits and least privilege are constant—especially in finance/healthcare.
Answer framework: “Least privilege + separation of duties” (roles → grants → review → evidence).
Example answer: “I start with job functions and build roles around them—read-only, app service accounts, data engineering, and break-glass admin. I avoid direct grants to users and keep privileges in roles so reviews are clean. For audits, I maintain an access review cadence, log admin actions, and ensure secrets are managed via a vault rather than shared passwords. I also document how emergency access is requested, approved, and time-boxed.”
Common mistake: Saying ‘only DBAs have admin’ without explaining how you control and evidence access.
Q: What US regulations or standards have influenced how you run databases (HIPAA, SOX, PCI DSS, SOC 2)?
Why they ask it: They need to know you can operate inside compliance constraints.
Answer framework: “Control → implementation → evidence” (what control requires, how you implement, how you prove).
Example answer: “In a PCI DSS environment, we treated cardholder data as a separate trust zone: encryption at rest and in transit, strict access controls, and detailed logging. We implemented key rotation policies and ensured backups were encrypted and access-controlled. The key part was evidence—access reviews, change approvals, and log retention that matched the standard. I’m not a compliance officer, but I know how to translate controls into database configurations and audit artifacts.”
Common mistake: Name-dropping standards without explaining what you actually changed in the database environment.
Q: What’s your approach to patching and upgrades with minimal downtime?
Why they ask it: Unpatched databases are a security and reliability risk; upgrades are where careers go to die.
Answer framework: “Assess → rehearse → execute → validate” with rollback.
Example answer: “I start by mapping versions, dependencies, and feature usage, then I read release notes for breaking changes and security fixes. I rehearse the upgrade on a staging environment with production-like data and measure downtime steps. For execution, I prefer rolling upgrades or replica-based cutovers when the platform supports it. Afterward, I validate application smoke tests, replication health, and performance baselines, and I keep a rollback plan that’s realistic—not just ‘restore from backup.’”
Common mistake: Treating upgrades as a single maintenance window task without rehearsal and validation.
Q: How do you monitor databases—what signals matter, and what alerts are noise?
Why they ask it: They want someone who reduces pager fatigue while catching real risk.
Answer framework: “Golden signals + SLOs” (latency, errors, saturation, traffic) mapped to DB metrics.
Example answer: “I tie alerts to user impact and failure modes: replication lag thresholds, backup failures, storage capacity runway, sustained lock waits, and rising error rates. I avoid alerting on every CPU spike; I alert on sustained saturation plus latency impact. I also build dashboards for trends—growth, top queries, and index usage—so we can plan capacity instead of discovering it at 99% disk.”
Common mistake: Listing a hundred metrics without explaining which ones wake you up at night and why.
Q: Tell me about a time you had to migrate data with near-zero downtime. What was your cutover plan?
Why they ask it: Migrations are common in US companies (cloud moves, vendor changes, re-architecting).
Answer framework: “Parallel run” (replicate → validate → cutover → backout).
Example answer: “We migrated a customer database to a new cluster with minimal downtime by setting up logical replication and running both systems in parallel. We validated row counts and checksums, then did an application cutover during a short maintenance window after draining writes. We kept the old system in read-only mode as a backout option and monitored error rates and latency closely for the first 24 hours. The key was rehearsing the cutover steps and having a clear go/no-go checklist.”
Common mistake: Saying ‘we used a tool’ without explaining validation, cutover, and backout.