Why pre-screen IT change managers before the hiring manager interview
Change management fails in two directions and both look like a functioning process. Too loose and changes cause the incidents the process exists to prevent; too tight and teams route around it, so the risky changes happen without any record at all. Neither shows on a resume, because both managers describe running a change advisory board and maintaining a change calendar. A short screen asks what proportion of changes failed, and what they did about the ones that bypassed the process entirely.
What actually matters when screening IT Change Manager candidates
- 01
Execution and reliability
Check volume and cadence of changes they governed: weekly CAB chairing, emergency change approvals, freeze window enforcement, and tooling like ServiceNow, Jira Service Management or BMC Remedy.
- 02
Improving the process
Probe redesigns they drove: standard change catalogues, pre-approved templates, automated CI-linked risk scoring, or shrinking lead time for low-risk changes without raising incident rates.
- 03
Judgement and autonomy
Test how they handle a poorly documented change request landing hours before a peak trading freeze, plus their line between emergency change and full CAB review.
- 04
Communication
Assess how they push back on release engineers and application owners, communicate blackout calendars, and brief senior stakeholders after a change-induced P1 outage.
Pre-screening questions to ask IT Change Manager 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.
Process that prevented incidents
3 questions01What experience do you have with IT change management?
Listen forChange volume per period with the environment described, plus their own authority to approve, defer or reject rather than only coordinate.
Volume unknown, or a role that turns out to be scheduling meetings rather than assessing change risk.
02How do you track and measure the success or failure of a change?
Listen forA failure rate they can name, with backed-out changes counted and incidents traced back to changes that were approved.
Success measured by changes completed on schedule, with no failure rate tracked at all.
03How do you assess the potential impact of a proposed change?
Listen forDependencies traced beyond what the requester declared, with a case where the real blast radius was wider than the submission stated.
Impact taken from the change record as submitted, with no independent check on what else depends on the system.
Improving the process
3 questions04Can you explain your process for implementing change within an organisation?
Listen forA process proportionate to risk, with a lightweight path for low-risk standard changes so teams have no reason to bypass it.
One approval path for everything, or a process so heavy that routine changes wait days for a board.
05Which tools and software have you used for change management?
Listen forNamed platforms with real configuration work, plus how they kept the change record accurate rather than filled in after the fact.
Records completed retrospectively, or a tool nobody updates until an audit is announced.
06How do you manage change in agile development environments?
Listen forChange control adapted to continuous delivery, with pipeline controls treated as the record rather than a board reviewing every release.
Applies a weekly board to teams deploying daily, or no answer for how change control works with automated deployment.
Refusing a change
3 questions07Can you describe a time a change did not go as expected? How did you handle it?
Listen forA specific failure with the back-out decision, how quickly it was made, and what the post-implementation review changed afterwards.
No change that failed, or a failure resolved by fixing forward with no back-out plan available.
08How would you handle a critical problem arising from a change that was implemented?
Listen forRestoring service first with a defined back-out point, and a review afterwards that examined the assessment rather than blaming the implementer.
Debugging in production with no back-out, or reviews that conclude with an individual at fault and no process change.
09What techniques do you use to manage resistance to change in an organisation?
Listen forAt least one case where the resistance was justified and the process changed, alongside a case where they held the requirement.
Treats all resistance as non-compliance, or has never adjusted the process in response to a legitimate objection.
Explaining risk
3 questions10How would you communicate a major technology change to non-technical stakeholders?
Listen forCommunication framed around what the audience will experience and when, with the fallback stated rather than a technical description.
Communicates the technical detail, or notifies stakeholders only after the change window has been agreed.
11Can you describe balancing several stakeholders' perspectives on a change?
Listen forA real conflict between delivery urgency and operational risk, with what was traded and who made the final call.
Conflicts resolved by whoever is most senior, or no example of holding a position against delivery pressure.
12Tell me about a time you used data to support a proposed change to the process.
Listen forIncident or failure data used to argue for a specific process change, with whether it was accepted and what happened afterwards.
Process changes argued on principle alone, or data collected but never used to change anything.
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.
Execution and reliability
35%5Names weekly change volumes, chaired CAB personally, and cites change failure rate or unauthorised change counts they tracked.
Improving the process
25%5Describes a specific policy or workflow change with before and after figures for lead time, backout rates or failed changes.
Judgement and autonomy
25%5Rejects or conditionally approves with clear reasoning: test evidence, backout plan, blast radius, and named accountable owner.
Communication
15%5Holds firm on evidence requirements while staying constructive; writes plain post-implementation reviews that assign actions, not blame.
A process too tight gets routed around, and the risky changes then happen with no record. A one-way video screen asks about the changes that bypassed the board.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for an IT change manager take?
Ten to fifteen minutes across eight to ten questions, answered async. Enough to establish change volume and failure rate, hear one change that caused an outage, and check how they handle emergency changes.
How much should framework certification count?
It confirms shared vocabulary and is often expected. It says nothing about whether their process was followed. Ask about changes that bypassed the board, because a process teams work around is the more common failure and no certification prevents it.
Evaluating answers
What is the strongest signal when screening an IT change manager?
A change failure rate they can name. Managers who ran a real process measure it and can say what proportion were backed out. Anyone who describes the process without a number has been administering approvals rather than managing risk.
How do I judge their handling of emergency changes?
Ask what happens at two in the morning during an incident. The workable answer has a defined emergency path with retrospective review, not a suspension of process. Managers with no emergency path either block incident response or have no record of what was changed.
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
