Why pre-screen disaster recovery analysts before the interview
Plans in this discipline are usually written once and confirmed annually by asking whether anything changed. Meanwhile a dependency moves, a backup job silently fails for six weeks, and the recovery objective nobody measured turns out to be four times longer than the business assumed. Analysts worth hiring test restores. A short screen asks when they last restored a system from backup and how long it took.
What actually matters when screening IT Disaster Recovery Analyst candidates
- 01
Technical depth
Check command of RTO and RPO tiering, BIA methodology, replication technologies (Zerto, VMware SRM, Azure Site Recovery), backup tooling like Veeam, and ISO 22301 or NIST SP 800-34 structures.
- 02
Real incidents and findings
Probe real invocations and exercises: tabletop versus full failover of a production datacentre, ransomware recovery from immutable backups, findings logged, and post-exercise gap remediation they owned.
- 03
Risk judgement
Assess how they rank application criticality against dependency mapping, single points of failure, cloud region concentration, and third-party SaaS recovery commitments buried in vendor contracts.
- 04
Getting things fixed
Look for evidence they drove DR plan updates through change control, chased infrastructure owners for runbook accuracy, and satisfied auditors or regulators such as DORA, FFIEC, or internal audit.
Pre-screening questions to ask IT Disaster Recovery Analyst candidates
12 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Recoveries they ran
3 questions01Have you ever had to execute a recovery plan during a real crisis?
Listen forA real incident with what worked and what did not, and the actual recovery time achieved.
Only exercises described, or an incident where their role was purely observational.
02Can you discuss a time when your recovery planning prevented significant data loss?
Listen forA specific case with the data at risk quantified, and the preparation that made recovery possible.
Prevention claimed generally, or no incident where the plan was actually needed.
03What steps would you take to recover data after a system failure?
Listen forA clear sequence including verifying the restore and confirming data integrity before returning service.
Service restored before data is verified, or no check that the restored data is complete.
Objectives measured
4 questions04How do you approach creating a disaster recovery plan for an organisation?
Listen forRecovery time and data loss objectives agreed with the business, then tested against reality.
Objectives set by the technology team, or targets never validated by an actual test.
05How do you assess the impact of different types of disaster on infrastructure?
Listen forScenarios covering data centre loss, ransomware and supplier failure, with different responses for each.
One generic scenario planned for, or ransomware not treated differently from hardware failure.
06How do you ensure all critical systems are covered in a plan?
Listen forDependencies mapped including authentication, network and third parties, then verified during actual exercises.
Coverage based on an application list, or shared dependencies missed until a test failed.
07Can you describe your experience with business continuity planning?
Listen forBusiness processes considered alongside systems, with manual workarounds defined where they exist.
Continuity treated as a technology problem, or no involvement from the business in planning.
Restores tested
2 questions08What strategies do you use to test recovery plans?
Listen forReal restores performed on a schedule, escalating from component tests to full failover exercises.
Testing limited to tabletop discussion, or exercises that never involve an actual restore.
09What processes should be in place to ensure backup and recovery succeed?
Listen forBackup completion monitored and restores sampled, with immutable or offline copies against ransomware.
Backup job success treated as proof, or all copies reachable from the production network.
People know their part
3 questions10Do you have experience training staff on recovery procedures?
Listen forThe people who would execute the plan trained and rehearsed, including out-of-hours coverage.
Plans held by one person, or procedures nobody else has ever practised.
11Have you worked with third-party vendors on recovery planning or execution?
Listen forVendor commitments verified against contracts, with their recovery capability tested rather than assumed.
Supplier assurances accepted without evidence, or vendor recovery times never confirmed.
12How would you communicate a recovery plan to non-technical staff?
Listen forClear actions per role written for use under pressure, available when systems are unavailable.
Plans stored only on the systems they cover, or documents too long to use during an incident.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
Technical depth
35%5Names replication and backup stacks they configured, explains tier assignments with actual RTO or RPO figures, and cites the standard framing their plan.
Real incidents and findings
30%5Describes specific failovers or outages by system and date, with measured recovery times, documented gaps, and the corrective actions closed afterwards.
Risk judgement
20%5Separates business-critical from merely urgent, evidences dependency mapping, and challenges vendor RTO claims rather than accepting stated SLAs at face value.
Getting things fixed
15%5Shows plans kept current against real change activity, stale runbooks fixed with named owners, and audit findings closed on schedule.
A backup that has never been restored is a hope. A one-way video screen asks when they last proved one.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for this role take?
Fifteen minutes across eight to ten questions, answered async. Enough to establish real recoveries, test their planning method, and check how often they actually exercise a restore.
How technical does this role need to be?
Technical enough to verify a restore rather than accept a green backup report. An analyst who only collects assurances from system owners will document a plan that has never been proven.
Evaluating answers
What is the strongest signal when screening this role?
When they last restored something and how long it took. Analysts who test know the number and where it exceeded the objective. Anyone quoting only backup success rates has tested nothing.
How do I judge their dependency mapping?
Ask what they discovered during a test. Real answers involve an unlisted dependency or a credential nobody had. Anyone whose tests all went smoothly has run a documentation review.
Go deeper on this role
Sanat has been hiring since 2012 and watching the recruitment industry change up close ever since, and turned that screening process into Hirevire's video screening platform. LinkedIn
