Database Administrator (DBA) interview questions

I've been a DBA for nine years. Started supporting Oracle 11g in production at an Indian banking IT services company, then moved into a mixed environment with SQL Server and PostgreSQL, and for the past five years I've been senior DBA at an Omani bank running primarily Oracle Exadata for core banking, with PostgreSQL on the digital-channels side and SQL Server for the data warehouse. I hold Oracle Certified Professional 19c and AWS RDS Specialty. My work splits roughly 50/50 between BAU (performance tuning, backups, patching) and project delivery (migrations, upgrades, new database builds).

Start with the execution plan. AWR if it's a recurring slow query, or autotrace if it's ad-hoc. Look at the plan for full table scans on large tables, missing indexes, suboptimal join orders, and wrong cardinality estimates. Then verify with actual stats: are the table statistics current? Often the optimiser is making bad decisions because statistics are stale. Index strategy: only add an index if the cost-benefit makes sense; indexes have write cost too. For complex queries I'll sometimes use a query rewrite (CTE or subquery factoring) to give the optimiser better choices. Last resort: hints. Generally hints are a smell that something is wrong elsewhere, but they're useful when you need to force a known-good plan.

For core banking: nightly RMAN level-0 full backup, daily level-1 incrementals, archive log backups every 30 minutes. Backups go to local NAS and replicate to the DR site overnight. Retention: 35 days operational, monthly snapshots for 7 years for regulatory. RPO target 30 minutes via archive logs, RTO target 4 hours for major recovery. I test recovery quarterly: restore a copy of production to a sandbox and run validation queries. The test isn't optional; you discover gaps in your backup strategy only when you actually try to recover. Documentation includes runbooks for the on-call DBA so recovery isn't person-dependent.

Audits in banking are intense. My pre-audit checklist: account inventory (every account justified, no orphans), privilege review (least privilege, no DBA shared accounts in production), encryption verification (TDE on for at-rest, network encryption in transit), audit-log review (DDL and DML audit captures who-changed-what), and patching status. I keep evidence ready: screenshots, scripts, output. During the audit I'm honest about gaps; auditors respect honesty far more than discovered cover-ups. After: any audit finding gets a fix plan with owner and date, tracked in a register reviewed monthly until closed.

On-call is part of the role. I run a 1-in-4 rotation with three other DBAs. The key to sustainable on-call is preparation: runbooks for common issues, monitoring tuned to alert only on real problems, and a culture where the team can hand off cleanly. Most pages I get are resolvable within 20 minutes. The 5% that aren't, I escalate quickly to the senior DBA without ego; better to escalate early than make the wrong fix at 3am. I also push back when on-call becomes always-on; if we're getting paged every night, the problem is the system, not the DBA's stamina.

For a senior DBA role in Oman banking I'd target OMR 1,500 to 1,900 total package depending on the on-call expectations and the seniority of the database estate. Banking DBA roles typically carry a premium for the regulatory exposure and 24x7 requirements. I'd expect a separate on-call allowance on top, around OMR 200 per on-call week. I'm on 60 days' notice from my current employer. Beyond pay I care about the platform; I'd take a slightly lower role on Exadata or RDS over a higher-paid role on ageing on-prem kit.