IT Manager Interview Questions

I maintain a structured IT demand backlog and review it monthly with key business stakeholders. Every incoming request gets assessed on three dimensions: business impact (what breaks or improves if we do or do not do this?), urgency (is there a deadline, compliance requirement, or operational risk driving timing?), and level of effort (how long will it actually take?). I categorise work into three buckets: run (keeping the lights on), grow (improving existing capabilities), and transform (strategic change). Run work takes priority by default because downtime and outages affect everyone immediately. For grow and transform work, I use a scoring matrix and present the ranked list to the steering committee quarterly so that prioritisation decisions are owned by the business, not just IT.

I maintain a vendor register with four key data points for every critical vendor: contract expiry date, SLA performance, escalation contacts, and renewal owner. I review SLA performance monthly and hold quarterly business reviews with critical vendors. I also make sure we are not overly dependent on any single vendor for a critical service: every tier-one vendor should have a documented exit plan and a tested alternative. Before renewing any significant contract I run a light competitive review, even if I intend to renew, because it gives me pricing leverage and keeps the vendor relationship honest. I also involve procurement and legal early in any vendor negotiation.

I treat security as a business risk, not a technical department responsibility. I maintain a risk register with probability, impact, and mitigation status for every identified IT risk, and I review it quarterly with the exec team. My security framework covers four layers: perimeter security (firewalls, intrusion detection), identity and access management (least privilege, MFA everywhere), data protection (encryption at rest and in transit, backup and recovery testing), and awareness (regular phishing simulations and staff training). I also conduct an annual penetration test and address all critical findings within 30 days. The most common security failure I see is organisations that invest in technical controls but neglect the human layer. Most breaches start with a phishing email, not a firewall exploit.

We experienced a full outage of our customer-facing platform on a Wednesday afternoon caused by a failed database migration. The system was down for 90 minutes. I activated our incident response process immediately: I assigned an incident commander, set up a dedicated Slack channel, and established a 15-minute update cycle for stakeholder communication. I kept the CEO and customer success lead informed with plain-language updates rather than technical logs. The root cause was a migration script not tested against production data volumes. Once restored, I ran a blameless post-mortem within 48 hours and identified three process gaps: no dry-run against production-scale data before migrations, no rollback plan documented before the change window, and stakeholder communication started 20 minutes late. All three were addressed within a week. Uptime in the following 12 months was 99.97%.

Our CEO wanted to migrate our entire data infrastructure to a new cloud platform within six weeks, driven by a conversation at a conference. The timeline was unrealistic: a proper migration would take six months, require significant retraining, and carry a high data integrity risk if rushed. I prepared a one-page brief for the CEO: a summary of what the migration would actually involve, the risk of the six-week timeline, and a phased plan that delivered the first capability improvement within eight weeks while managing risk properly. I presented both timelines side by side with their risk profiles. The CEO agreed to the phased plan. The migration completed successfully in five months.

When I joined my previous company, IT was entirely reactive: the team spent 80% of their time on support tickets with no capacity for improvement work. I found that 40% of ticket volume was caused by three recurring issues: legacy printer infrastructure, a poorly configured VPN, and an onboarding process that created access issues for new starters. I fixed all three root causes in the first quarter. Ticket volume dropped by 38%, which freed capacity for a self-service IT portal that reduced email requests by 60%, and a device management rollout that reduced new-starter setup time from 4 hours to 45 minutes. By month six, the team had shifted from 80% reactive to 50% proactive work.

I maintain a three-year infrastructure roadmap that aligns with the business growth plan. Every six months I review current utilisation across compute, storage, and network, and I model forward demand based on headcount forecasts, product roadmap, and expected transaction volume. I set utilisation thresholds that trigger a review: if any tier-one system hits 75% capacity, I start planning the next increment. For cloud resources I use auto-scaling where possible to avoid over-provisioning, but I still model cost at scale to avoid bill shock. For on-premises infrastructure I build in a 20-25% buffer. I review the roadmap against actual spend quarterly and present a written summary to the CFO so that infrastructure investment is visible as a business decision.

I use a three-tier change classification: standard changes (pre-approved, low-risk, can be applied any time), normal changes (require CAB review, applied during a change window), and emergency changes (bypass normal process but require post-implementation review within 24 hours). Every change has a risk assessment, a rollback plan, and a defined test approach before it goes to the CAB. I hold a weekly change advisory board meeting of 30 minutes covering the upcoming week's schedule. I also maintain a change blackout calendar for critical business periods. The biggest improvement I have made to change processes is making rollback plans mandatory: it forces engineers to think through the failure scenario before the change, not during it.

I structure the IT budget into three categories: maintain (keeping existing systems running, typically 50-60% of IT spend), improve (efficiency gains and capability enhancements, typically 30%), and innovate (new capabilities that support growth, typically 10-20%). I present this split to the exec team at budget time because it helps them understand that most IT spending is a cost of doing business. I also track value delivered against the improve and innovate budget: for every significant project I document the expected business outcome and report actual versus expected at project closure. IT teams that cannot articulate their business contribution tend to get their budgets cut first.