Use this guide to prepare for IT Service Manager interviews, with a focus on recovery, incident, governance. Explain your reasoning and connect it to experience you can substantiate.
These preparation themes come from the questions in this role’s bank. They help you organise your examples; individual employers may assess different things.
Recovery
Incident
Governance
WIP limit
Workflow definition
Pull system
A useful preparation sequence
Choose your experience level and the round you expect.
Answer one question in your own words before opening its guide.
Compare your reasoning, evidence and trade-offs; adapt the answer to your experience.
Practise the follow-up, then revisit one answer you want to improve.
Representative questions and answer guidance
Open any question to read its answer. The complete guidance is included on this page.
Behavioural · Senior
1. Describe a recurring service issue you eliminated rather than repeatedly escalated.
Answer guide
Choose a real recurring issue you owned, such as repeated outages, repeat tickets or missed targets. Start with the trend, showing how often it happened and what it cost users. Explain how you led the root cause work with the right teams, and what you found. Describe the permanent action, and how you got funding or agreement for it. Finish with proof it stayed fixed, such as a lower ticket count for several months, and what you would do differently.
Key points
Show trend, root cause, action and sustained measure.
2. How do you distinguish incident restoration from permanent problem resolution?
Answer guide
Restoring service and fixing the cause are different jobs. Incident management aims to bring the service back as fast as possible, using a restart, a rollback or a workaround, even if the cause is unknown. Once users are working again, the incident closes. Problem management then looks for the real cause using root cause analysis. It ends with a permanent fix or a known error record, and actions to stop a repeat, such as a change, a monitor or a process update. Track each action to completion.
Key points
Explain service recovery, workaround, RCA and prevention.
3. Which service metrics would you use to spot deterioration before SLA breach?
Answer guide
Use early warning signs, not just the final SLA result. Look at a rising ticket backlog, ageing tickets, first response time, reopen rate and repeat incidents. Watch monitoring signals such as error rates and slow response times, and user impact measures like people affected and complaints. Keep the number of measures small so people actually read them. Check the data is accurate and timely, or people will stop trusting it. Set warning limits below the SLA line, and agree who acts when they trigger.
Key points
Use leading indicators, user impact and signal quality.
4. A board has ten items in progress and nothing finishing. What would you do?
Answer guide
Ten items in progress and none finishing means work is queued or blocked, and starting more will only lengthen the wait. I would make blockers visible first, then set or tighten a WIP limit so the team must finish before pulling new work. People swarm on the oldest or nearly done items, and I look for the bottleneck, such as a review or test stage with too little capacity, and address that. Afterwards I watch whether throughput rises and cycle time falls, since the limit is an experiment and may need adjusting.
What this question explores
Whether you respond to stalled flow by limiting WIP, swarming and fixing the bottleneck instead of starting more.
Common mistakes
Telling people to work harder or adding more items to keep everyone busy.
Setting a WIP limit and then ignoring it whenever a new request arrives.
Practise a follow-up
How would you choose the initial WIP limit for a team?
What would you do when a WIP limit is breached repeatedly?
5. What must a Kanban team make explicit about its workflow?
Answer guide
A Kanban team makes its process visible so that flow can be managed. That means defining the types of work item it handles, where work starts and finishes, the steps or states in between, and the policies for moving an item along, such as what ready means for testing. It also sets limits on work in progress and any service expectations, for example a target time for urgent fixes. When these are explicit and shown on the board, everyone can see bottlenecks and agree on improvements instead of arguing from opinion.
What this question explores
Whether you know the explicit policies that make a Kanban system visible and improvable.
Common mistakes
Saying Kanban is just a board with columns and sticky notes.
Leaving policies unwritten so every person moves cards according to habit.
Practise a follow-up
What does a WIP limit do for a team that has never used one?
How would you choose the columns for a support team's board?
In a push model work is assigned as soon as it arrives or is planned, whether or not the team has room, so queues build and people juggle too many things. In a pull system, a person or team takes new work only when there is capacity downstream and the item meets the agreed policy for being ready. This limits overcommitment, exposes bottlenecks and shortens waiting time. Assignment becomes less about a manager allocating tasks and more about the team choosing the next most valuable item within agreed rules, such as oldest first or by class of service.
What this question explores
Whether you understand how capacity and policy, not arrival, decide when work starts.
Common mistakes
Describing pull as people simply choosing tasks they like, with no rules.
Thinking a manager assigning everything up front is still a pull system.
Practise a follow-up
How does a pull system deal with urgent requests?
What could go wrong if the team pulls without clear readiness policies?
7. Urgent requests keep bypassing normal work. How do you prevent collapse of the queue?
Answer guide
If urgent requests bypass the system, the queue collapses because normal work stops moving and no one can forecast. I would define explicit expedite criteria, such as a real customer or legal impact with a clear cost of delay, limit how many can be in flight at once, and reserve a defined share of capacity for them. Then I measure what expedites displace and how often they arrive. Frequent expedites usually point to an underlying issue, such as weak incident prevention or unclear prioritisation, and that root cause should be addressed with the people who own it.
What this question explores
Whether you protect flow with explicit expedite policies and treat frequent urgency as a symptom.
Common mistakes
Allowing anyone to mark work urgent, so most of the board becomes expedited.
Accepting every urgent request without showing the impact on planned work.
Practise a follow-up
How would you agree expedite criteria with stakeholders who each think their work is urgent?
What would you do if the expedite lane is always full?
Lead time usually runs from the customer's request to delivery, while cycle time usually runs from when work starts to when it finishes. Lead time therefore includes waiting in the backlog, and cycle time shows how long the team takes once it begins. Organisations use the words differently, so the first step is to state the start and end points for each measure and apply them consistently. Otherwise numbers from two teams are not comparable. For example, a request may wait three weeks and then take two days, which the two measures describe very differently.
What this question explores
Whether you can define the two measures precisely and insist on consistent start and end points.
Common mistakes
Using the terms as synonyms without stating where the clock starts and stops.
Reporting an average only, hiding wide variation in individual items.
Practise a follow-up
Which measure would you use to forecast delivery for a new request?
How do you deal with items that pause while waiting for a customer?
9. What does throughput tell you that a utilization report may not?
Answer guide
Throughput counts finished items per period, so it shows what the system actually delivers, while a utilisation report shows only how busy people were. A team can be fully utilised and deliver little, because work sits in queues or gets redone. Throughput becomes more informative when read with item size, quality signals such as escaped defects, and the age of work in progress. I would not set targets that reward raw counts, since people can split items to inflate the number. For forecasting, a range of past weekly throughputs is more honest than one average.
What this question explores
Whether you prefer output-based flow measures to activity measures and know how they can be gamed.
Common mistakes
Treating high utilisation as proof of a productive team.
Turning throughput into an individual target, which encourages tiny or low-value items.
Practise a follow-up
How would you use throughput history to forecast a backlog of 40 items?
What would you look at if throughput is steady but customers are unhappy?
10. One item is far older than the team's usual cycle time. What would you inspect?
Answer guide
An item much older than the usual cycle time is a warning that something is stuck, so I look at why: a blocker, a dependency on another team, repeated rework or hidden waiting between stages. Then the team decides whether to swarm to finish it, split off the remaining part, or escalate the blocker to someone who can remove it. Aging work in progress is a useful daily signal because it flags risk before an item is late. I keep tracking its age until it is done and look for a pattern across similar items in the retrospective.
What this question explores
Whether you use item age as an early warning and take a concrete action rather than waiting.
Common mistakes
Ignoring the item until the customer complains because it is only one ticket.
Blaming the person holding the item without looking at the queues and dependencies.
Practise a follow-up
What percentile of past cycle times would you use to decide an item is at risk?
How would you make aging visible on the team board?
11. How would you communicate delivery predictability with historical flow data?
Answer guide
I would take the cycle times of recently completed items and describe them as a distribution, then say something like: about eighty-five percent of items finished within twelve days. That is a service level expectation with a stated probability, more honest than a single promise date. I explain the exceptions, such as large or blocked items, and revise the expectation when the work or the system changes. The conversation with stakeholders moves from will you hit the date to how likely is it and what can we do to improve the odds. The figures here are illustrative, since they depend on the team's own data.
What this question explores
Whether you can give probabilistic delivery forecasts from real flow data and explain them plainly.
Common mistakes
Promising a fixed date from a single average with no mention of uncertainty.
Using data from a different team or an old period as if it still applied.
Practise a follow-up
How much historical data would you want before trusting the distribution?
What would you tell a stakeholder who wants a hundred percent certainty?
Yes. Scrum provides the accountabilities, events and artefacts, and Kanban practices can help the team inside them. The team can visualise its workflow on a board, limit work in progress so items finish within the Sprint, and use flow metrics such as cycle time and aging to spot problems earlier than the Sprint Review would, which supports the Sprint Goal. What should not happen is dropping Scrum's events and roles and still calling it Scrum. The two fit together when each practice has a clear purpose.
What this question explores
Whether you can combine Kanban flow practices with Scrum without losing Scrum's structure.
Common mistakes
Saying they are incompatible and a team must choose one or the other.
Adopting a board and calling it Scrum while dropping the Scrum events.
Practise a follow-up
How would a WIP limit fit into a Sprint Backlog?
Which flow metric would you bring to the Sprint Retrospective?
Choose one answer containing an example or practical sequence. Explain what you would actually do, what you would check and when you would ask for help. Keep claims about your experience honest.
For technical or regulated work, check current documentation and applicable local requirements alongside this practice material.