Questions to Ask in an IT Interview
For candidates interviewing for a general information technology job, whether support technician, systems or network administrator, IT specialist or IT manager, who want good questions ready for the end of the interview. The list follows the conversation: the job and the team, the systems and their budget, on-call and ticket load, security, then training and where the role leads. A short last group is for a manager interviewing an IT candidate, and every question has a note on what a good or a worrying answer sounds like.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
The job
What does the IT environment look like: the servers, the network, the cloud services and the devices people work on?
Why ask it
A good answer is an inventory you could sketch on paper: which operating systems, where email and files live, who makes the network gear, and which application the whole place stops without. If the interviewer cannot describe it, ask who can, because that person is the one you would be learning from. Whatever they list first is usually what takes most of the team's time.
How many people are in IT, and who covers which area?
Why ask it
Ask for names against areas: network, servers, desktops, phones, the business applications. Where one name covers nearly all of them, that person is stretched, and where an area has no name, it is likely to become yours. Then ask who covers each area when its owner is on vacation.
How does the job split between helping users and looking after the systems behind them?
Why ask it
IT titles are loose, and the same one can mean resetting passwords most of the day at one employer and rarely touching a desktop at another. Ask how last week actually went for whoever does the work now. If the posting described infrastructure and the answer is mostly support requests, believe the answer.
Is this a new position, or would I be replacing someone, and would there be a handover?
Why ask it
A handover with the previous person still in the building is worth weeks of guesswork. If they have already gone, ask what they left behind in notes and who else knows their systems. A new position has no handover at all, so ask who decided it was needed and what they pictured it doing.
What is the IT team's biggest headache right now?
Why ask it
The useful answers are particular: a migration that stalled, a site with a bad connection, a system nobody fully understands. It will probably be on your desk within the first month, so ask what has been tried. If nothing comes to mind, the interviewer may be too far from the daily work to know.
How many users, sites and devices does IT look after?
Why ask it
Set the numbers against the size of the team, since that ratio is the workload. The count of sites matters as much as the count of people. Ask whether the smaller locations have anyone local who can plug in a cable, or whether every fault there means a drive.
Where does IT sit in the organization: under operations, finance, or a technology leader of its own?
Why ask it
In smaller organizations IT often answers to a finance or office manager, which is workable but means you would be the one putting technical risk into plain terms. Ask who would check a technical decision of yours. With a technical lead above you, ask how hands-on they still are.
Is any of the work done by a managed service provider or outside contractors, and where does their part end and mine begin?
Why ask it
An outside provider may run the firewall, the backups, the after-hours line or nearly everything. Find out who manages that relationship, and whether you would have enough access to fix things yourself or would be raising tickets with them. Ask too whether the arrangement is settled or under review, because a job can change shape when a contract ends.
Would I manage people or vendors in this role, and would I have a say in hiring and contracts?
Why ask it
For an IT manager post, ask how many of each, because the answer decides whether you would be leading or only coordinating. Being answerable for a team's results with no voice in who joins it, or in which suppliers stay, is a hard position to do well from. For a hands-on role, skip this one.
How do the rest of the staff think of IT here?
Why ask it
The hopeful answer is that people bring IT in early, before they buy something or move a team. The other kind is that IT hears about things once they are broken or already purchased. Neither is permanent, but a poor reputation is extra work you would inherit along with the systems.
Systems and budget
How much runs on equipment in your own building, and how much is in the cloud or hosted by a provider?
Why ask it
The split tells you which skills the job will actually use: racks, hypervisors and storage, or admin consoles and vendor support lines. Ask which way it is moving. A migration that is half done means keeping both sides running for a while, which is more work than either one alone.
How old is the hardware, from the servers and switches to the laptops on people's desks, and is there a refresh cycle?
Why ask it
A cycle with years attached means replacements are planned and paid for ahead of time. 'We replace things when they die' means part of your week goes to failures and rushed purchases. Ask what is due for replacement this year and whether the money for it is already set aside.
Is anything still running that the vendor no longer supports?
Why ask it
Many organizations have something: an old server, a retired version of an operating system, an application that only runs on one aging machine. Naming it, along with the plan to retire it, is the reassuring answer. 'It works, so nobody touches it' means it becomes your problem on the day it stops.
What does IT use to run all of this: a ticket system, remote management, a way to push software and patches?
Why ask it
Listen for whether these are real products or a shared inbox and a spreadsheet. A place that still walks a USB stick to each machine has plenty of room for someone who likes scripting, as long as the interviewer counts that as part of the job. If you have used one of the tools they name, this is the natural moment to say what you did with it.
What is written down about how things are set up, and where is it kept?
Why ask it
Good signs are a wiki or shared notebook, a network diagram with a recent date on it and a password vault, along with an honest word about which parts are stale. If most of it lives in one person's head, your first months would be spent interviewing that person, so ask whether they are staying.
When something goes down, does an alert tell IT first, or does a user?
Why ask it
Monitoring that reaches someone before the phones ring lets you fix things quietly. Hearing about faults from users means every outage starts with you already behind. If there is little monitoring, ask whether setting it up would be welcome work or one more thing with no money behind it.
Before I change something that people rely on, who needs to know or approve it?
Why ask it
Some places have a change request and a set window, and others have a message to the boss and a quiet evening. Either can work. The answer to worry about is no process at all in a place where a mistake stops the business, because the first bad change would be yours to explain.
Does IT have a budget of its own, or does each purchase need a separate yes?
Why ask it
With its own budget line, IT can plan a year ahead. Asking item by item means the outcome depends on who is asked and what kind of month it has been. Find out who approves spending and roughly how long a routine request takes, since that sets how quickly you could fix anything that costs money.
How does a project get approved here, and what was the last one that got a yes?
Why ask it
A recent example shows the real route: a written case, a quote or two, a meeting, a signature. Listen for who made the argument and how long it took. If the last approved project is hard to recall, expect your own proposals to wait just as long.
What is on IT's project list for the coming year?
Why ask it
A list with owners and rough dates is a plan. A list of things 'we would like to get to' is a wish, and the follow-up is what has kept them from starting. Listen too for a project that explains why they are hiring now, such as a migration that needs another pair of hands.
Is the company planning anything that would land on IT, such as a new office, a move, an acquisition or a wave of hiring?
Why ask it
Each of those is months of IT work that rarely appears in a posting: circuits to order, laptops and accounts by the dozen, another company's systems to fold in. Ask whether the last one came with extra hands or money, or was absorbed by the same team on top of the queue.
What did IT last ask for and not get?
Why ask it
The refused request shows where the ceiling is. The reason matters more than the item: too expensive, bad timing, or nobody could explain why it was needed. That last one is something a good hire can change, and the first two tell you how far the organization will go.
Workload
Who answers when something breaks at night or on a weekend, and how often would that be me?
Why ask it
A named rotation shared among several people is the answer you can plan a life around. 'Whoever picks up' usually turns out to be the newest or the most willing person. If you would be the only one, ask what happens when you are sick, traveling or simply asleep.
What gets someone called after hours here: a real outage, or anything an executive cannot open?
Why ask it
A short written list of what counts as an emergency protects your evenings. Without one, every request from a senior person becomes urgent by default. Ask for the last two or three calls as examples, since they describe the habit better than any policy.
Is after-hours work paid, given back as time off, or treated as part of the salary?
Why ask it
This varies by employer, by how the role is classified and by where you are, so ask how it works there and do not assume. A clear rule that people really do use is the good answer. Whatever you are told, ask for it to appear in the written offer.
When is maintenance done: is there a regular window, and does it fall on nights or weekends?
Why ask it
Planned late work is a separate thing from being on call, and candidates often forget to ask about it. Find out how many evenings a month it comes to, and whether someone who patched until midnight is expected at their desk at eight. Being able to do it from home changes the picture a good deal.
Roughly how many requests does IT get in a week, and does every one of them become a ticket?
Why ask it
A number, even a rough one, means someone is counting. When requests arrive by hallway, email and text with no record, nobody can show how busy the team is, which makes it hard to argue for help. Ask whether you would be free to insist on tickets and whether management would back you.
Which request keeps coming back without ever being fixed for good?
Why ask it
Most teams can name one straight away: the printer on the second floor, the application that drops its connection, the weekly lockouts. It points to a root cause nobody has had time to chase. Solving it early is one of the quicker ways for a new hire to earn goodwill, so ask what has stood in the way.
Tell me about the last serious outage: what broke, who was called and how long did it take to recover?
Why ask it
The story shows more than any policy would: how the fault was noticed, whether the backups or the spare held, who made the decisions. Listen to the tone as well. A calm account that ends with something being changed is a good sign, and one that ends with a person being blamed is not.
How quickly do people expect an answer from IT, and is that written down anywhere?
Why ask it
Agreed response times give you something to point to when two people both want you now. Where nothing is written, the expectation tends to be 'immediately', set by whoever complains loudest. Ask what happens today when a request cannot be dealt with the same day.
How is time kept free for project work when requests keep arriving?
Why ask it
Good answers are practical: one person takes the queue each day, or certain afternoons are closed to walk-ups. 'We fit projects in when it is quiet' usually means they slip, and you would be judged on them anyway. Ask how the last project fared against its date.
How many days would I need to be in the building, and would I travel between sites?
Why ask it
Cabling, hardware and new starters need hands, so some presence is a fair expectation in most IT jobs. What you want is the pattern: which days, which sites, and whether your own car and time are involved. If travel is regular, ask how mileage and travel time are handled there.
Security
Who is responsible for security: this role, a separate team or an outside provider?
Why ask it
In a small department, security usually falls to whoever runs the systems, with no title to say so. Get it broken down: the firewall, mail filtering, staff awareness training, responding when something goes wrong. If the answer is that everyone is responsible, ask whose name goes on the form when an auditor or insurer sends questions.
If a server or a shared drive were lost tonight, how would it be recovered, and has that ever been tried?
Why ask it
You are listening for three things: what is backed up, where the copies are kept, and whether anyone has restored from them. A backup nobody has tested is a hope. If testing has not happened, offering to make it an early task is a reasonable thing to say in the interview.
Who keeps everything patched, including the things that are easy to forget, such as switches, firewalls and printers?
Why ask it
Workstations and servers usually have a tool and a schedule. Network gear and firmware often have neither, and those are the gaps you would inherit. 'When we get to it' is common and honest, so follow it by asking whether fixing that would be part of the job.
How are administrator accounts and shared passwords kept?
Why ask it
A password vault, separate admin logins and a second sign-in step are what you hope to hear. One shared administrator password that has not changed in years is the worrying version. An interviewer may not want to give a candidate much detail here, which is a fair position and a good sign in itself.
When someone leaves the company, how does IT find out, and how fast is their access closed?
Why ask it
It tests whether HR and IT talk to each other. A checklist started by HR on or before the last day is the good answer. Finding out weeks later, from an account that is still signing in, means there is cleanup waiting and a process for you to build.
Has the organization had a security scare, such as ransomware or a hijacked mailbox, and what did IT change because of it?
Why ask it
Many places have had something, and saying so is to their credit. What followed is the part to listen to: new controls, more budget, a written plan, or nothing at all. An organization that went through one and changed nothing is unlikely to change on your warning either.
Does IT answer to an auditor, a regulator, a cyber insurance form or a customer questionnaire?
Why ask it
Which rules apply depends on the industry and the place, so ask what applies there. Whatever it is, somebody has to gather the evidence each year, and in a small team that is often the person in this job. Ask how long it took last time and who did it.
When a user wants an exception to a security rule, who backs IT up?
Why ask it
Policies hold only when someone senior is willing to say no alongside you. Ask about the last time it came up and who made the final decision. If exceptions go to anyone important enough, you would be enforcing rules on some people that others ignore.
Growth
What would the first month look like: shadowing, a handover, or straight into the queue?
Why ask it
A plan for the first weeks, with access arranged and someone assigned to show you around, means they have thought about your arrival. Waiting days for admin accounts is a small but telling sign of how things run. Ask what you would be expected to handle alone by the end of that month.
Is there a training budget, and what was it last spent on?
Why ask it
The second half is the real question, because a budget nobody draws on is only a line in a spreadsheet. A recent course, conference or exam with a person's name attached shows it is real. If the answer is no, ask whether vendor training or study time during work hours is available.
Which certifications matter for this role, and does the company cover the exam and the time to study?
Why ask it
Some employers need a particular certification for a contract or a vendor partnership, and others simply like to see them. Ask whether any support comes with conditions, such as staying for a set period afterward. Terms differ from one employer to the next, so get them in writing before you sign up for anything.
Where does this role lead: toward a specialty such as networking, cloud or security, or toward managing the team?
Why ask it
A generalist job can open several doors or none, depending on the size of the place. Ask for an example of someone who moved on from it and what they do now. In a very small team the honest answer may be that growth means the role itself getting bigger, which suits some people well.
Would I get to work on the newer parts of the environment, or mainly keep the older ones running?
Why ask it
Your skills in three years will be whatever you spent those years doing. A mix is normal, and somebody has to look after the old systems. The thing to check is whether the new work goes to you, to a senior colleague or to an outside consultant.
Who would review my work, and what would they look at?
Why ask it
Quiet weeks are hard to measure, so ask what the reviewer looks at: uptime, how fast requests close, projects delivered, what users say. If the reviewer is not technical, the last of those will weigh most. Knowing that, you can keep your own short record of the problems you prevented.
A year from now, what would make you say this hire worked out?
Why ask it
The answer is the job description without the padding. It may be a project finished, a backlog cleared, or simply that the interviewer stopped getting calls about IT. Write it down, and if an offer comes, check that the role as described would let you deliver it.
Which part of this environment do you think I would find steepest to learn?
Why ask it
This invites the interviewer to voice a doubt about your experience while you can still respond to it. If they name a system you have not worked with, say how you picked up the last unfamiliar one. Their reply also tells you where to spend your reading time before a second round or a start date.
What happens after today: another interview, a practical test, references?
Why ask it
IT hiring often includes a hands-on step, such as a troubleshooting scenario or a walk through a lab, so ask what form it takes and whether you can prepare. Ask when you should expect to hear, and from whom. It also saves you from wondering whether a week of silence means anything.
For managers
Can you sketch the setup you work on now, as far as you can from memory?
Why ask it
Hand over a pen or a whiteboard. Someone who has run an environment can draw its outline without notes: the sites, the links between them, where the servers and the cloud services sit. Say that you are not after confidential detail. Hesitation over the basics suggests they worked in one corner of it and never saw the whole.
Here is a problem we actually had last month. How would you have gone about it?
Why ask it
With your own incident you know what the cause turned out to be, so you can judge the reasoning and not just the vocabulary. Strong candidates ask you questions before they answer, which is what they would do on the job. Give the same problem to every candidate so the answers can be compared.
What is something you set up that you would do differently now?
Why ask it
It asks for judgment and a little humility at once. A good answer names a real system, what was wrong with the first approach and what living with it taught them. Someone who can think of nothing either has not built much or does not look back at their own work.
What is the last thing you wrote down so that someone else could do it without you?
Why ask it
A runbook, a setup guide for new laptops, a diagram: anything will do, as long as they can say who used it afterward. Candidates who document tend to talk about the reader, and those who do not tend to describe the system again. In a small team this habit is what lets anyone take a week off.
A department head asks why the network was down this morning. What do you tell them?
Why ask it
Listen for plain language: what happened, who was affected, what is being done so it does not repeat. Jargon, blame or a long technical history all miss what the person asked. Much of this job's reputation is made in conversations like this one, so give the answer real weight.
Someone in the office has bought their own software subscription and now wants IT to support it. What do you do?
Why ask it
There is no single right answer, which is why it is useful. You want to hear them ask what the tool is for and what data is in it before deciding, and bring in whoever owns the policy. A flat refusal and a shrugging yes are both warning signs for a role that deals with staff every day.
This job mixes constant interruptions with project work. How have you kept a project moving in a week like that?
Why ask it
Candidates from a pure support desk or a pure project team may not have had to do both, and it is better to find out now. Look for a method they really followed, such as blocking time, batching requests or agreeing a cutoff with their manager. Ask how the project turned out.
Which parts of IT do you want to be doing more of in two years, and which less?
Why ask it
A generalist role suits someone who is content with variety, or who sees it as a route to something you can offer. If what they want less of is most of this job, you have both learned something in time. Be ready to say honestly whether the growth they describe exists in your team.
How to use these questions in an IT interview
Practical guidance for the conversation itself
Before the interview
Work out which IT job this is
The same title covers very different work from one employer to the next. Read the posting for clues: the tools it names, whether users or infrastructure come first in the duties, and how long the 'other duties' line is. Then ask the first few questions under The job early, because the answers decide which of the others are worth your time.
Find out who will be across the table
An IT manager can answer everything under Systems and budget and under Security in detail. An owner, an office manager or someone from HR often cannot, and pressing them on how backups are made helps nobody. With a non-technical interviewer, lead with The job, Workload and Growth, and ask whether you could speak to whoever looks after the systems today.
Pick five and put them in order
Many interviews leave only five or ten minutes for your questions. Choose one from each of the first five groups and put the one that could change your mind at the top. For a lot of people that is the after-hours question, and it is easier to ask in a plain tone during the interview than to find out the answer in the second week.
Use what you can see from outside
The tools named in the posting, the offices listed on the company's site and the size of the staff already describe part of the environment. Build on that. 'The posting mentions three sites. Is there anyone technical at the smaller ones?' shows you prepared and gets a fuller answer than starting from nothing.
In the room
Ask about the last time
'Do you test the backups?' gets a yes. 'When was something last restored?' gets a date or a pause. The same turn works for outages, approvals, training spend and after-hours calls, and it is the quickest way to tell a practice from an intention.
Sound curious, not like an inspector
Questions about old systems, patching and passwords can come across as an audit of the person answering, who may have built what you are asking about. A short reason helps: 'I ask so I know what I would be walking into.' If an answer reveals a gap, ask whether closing it would be part of the job, and keep your verdict to yourself.
Accept that some answers will be thin
A careful employer will not describe its security setup in detail to someone it met an hour ago. Take the general answer and move on. The fuller version can wait until there is an offer, when both sides have more reason to be open.
Treat pay and hours as local
How on-call, overtime, travel and paid training are handled differs by employer, by the kind of contract and by where you live. Ask how each one works there, do not assume it matches your last job, and ask for what you are told to be included in the written offer.
Reading the answers
Count the names
For each area you hear about, note who covers it. One name against everything, or systems that only a departed colleague understood, means the job carries more risk and more hours than the posting says. It can still be a good job for someone who wants the whole environment, as long as the pay and the backing match.
Allow for the size of the team
In a team of one or two, thin documentation, an informal change process and on-call by habit are common, and they do not by themselves mean the place is badly run. What matters there is whether the interviewer knows the gaps and would support closing them. In a large department the same gaps are harder to excuse.
Compare the accounts
If you meet both a manager and someone who does the work, ask each about the weekly split between support and projects, and about calls after hours. Where the two differ, the person doing the work is describing what you would live with.
Notice how IT is talked about
An interviewer who speaks of IT only as a cost to hold down is unlikely to approve much. One who can name something IT made possible in the past year is more likely to fund the next thing. This comes through in the answers about budget and refused requests more than in any direct question.
If you are the one hiring
Ask about what happened
Most of the questions under For managers lean on real events: a system the candidate built, a problem your own team had, a page they wrote for someone else, a project they kept alive. An account of something that happened is easier to test with a follow-up than a hypothetical, and harder to rehearse. The two scenarios, the department head and the unapproved subscription, are there for judgment and plain speaking, so follow each with 'When did you last have to do that?'
Let them ask before they answer
When you describe a fault, a good technician's first move is a question: what changed, who is affected, what has been tried. Count those questions in the candidate's favor and answer them. Someone who jumps straight to a fix in the interview may do the same on your network.
Keep any practical task fair and safe
A short exercise on a spare machine or a test account shows more than a quiz does. Keep it brief, tell candidates beforehand that there will be one, and never run it on live systems or real data. Give everyone the same task so you are comparing people and not luck.
Answer their questions fully
A candidate who asks about backups, after-hours calls and old systems is doing what you would want from them in the job. Give the honest version, including the parts that need work. Someone who accepts with the real picture in front of them starts without an unpleasant surprise.