IT Interview Questions to Ask Candidates
IT interview questions to ask candidates for an information technology role, whether that is support, systems or network administration, or the one generalist who does everything, written for an IT manager, a business owner or an HR partner who may not be technical themselves. The questions follow the interview: background and certifications, troubleshooting talked through step by step, networks, systems and cloud, security and backups, users and outages, then process and closing. Each note says what a strong or a worrying answer sounds like, in terms a non-specialist can judge.
The questions
Each question, and why to ask it
Background
Walk me through the IT environment you look after now: how many users, how many sites, and which parts are yours alone?
Why ask it
Size and ownership place a candidate faster than a job title does. Someone who really runs the place gives numbers without reaching for them, say ninety people across two offices, and says plainly which parts an outside provider handles. If they cannot say how many people they support, they were probably working a queue someone else managed.
Which certifications do you hold, and what did the most recent one teach you that you have used since?
Why ask it
Certificates such as CompTIA A+, Network+ or Security+, or the ones Microsoft and Cisco issue, show that someone studied and passed an exam, not that they have done the work. The second half of the question separates the two: a good answer names a job they did differently afterwards. If the role depends on a certificate, ask whether it is current and confirm it with the body that issued it.
Pick the three technologies on your resume you know best. What is the hardest thing you have done with each?
Why ask it
An IT resume is often a long list of product names, and this cuts it down to what they can stand behind. Expect a real piece of work for each one, such as moving a company's email or rebuilding a failed server. If the hardest thing was installing it, treat the other names on the list as things they have seen, not run.
What was the last IT project you saw through from start to finish, and which part was yours?
Why ask it
Projects such as a laptop refresh, an office move or a switch to cloud email show planning, which day-to-day support does not. Listen for a date, a count of machines or people, something that went wrong and how the changeover was handled for staff. Press gently on 'we' until you know what they personally did.
How do you keep your skills current, and what have you taught yourself in the past year?
Why ask it
The tools in this field change every few years, so the habit of learning counts for more than any one product. Good signs are a test setup at home, a trial account they broke and rebuilt, or a course they finished and then applied at work. 'I pick things up as I go' with no example is the weak version.
Have you been the only IT person somewhere, or always part of a team? What was hard about it?
Why ask it
A lone IT person has to cover a little of everything and know when to call for outside help, while someone from a large team may be deep in one area and have never touched the rest. Neither is wrong, but say which of the two your job is and watch how they react. Someone moving from a team to working alone should be able to say who they would call when stuck.
Which area of IT are you weakest in, and what happens when a problem lands there?
Why ask it
Nobody is equally good at networks, servers, security and support, so a candidate who claims no weak area is either guessing or has not been tested. Credit a named gap plus a plan: the documentation they read, the colleague or vendor they ask, how long they try before handing it on. Then check the gap is not the center of your job.
Troubleshooting
A user says, 'My computer is slow.' Walk me through what you do, step by step.
Why ask it
A complaint every support person has heard many times, which makes it a fair test of method. Good candidates begin with questions (slow since when, at what, in one program or all of them) and then check cheap things first: how long since a restart, free disk space, memory, what is running. Going straight to wiping the machine or ordering a new one skips the diagnosis.
One person cannot get online, but the colleague at the next desk can. Where do you start?
Why ask it
The neighbor being online already rules out the office connection, and a sharp candidate says so before anything else. From there you should hear an order: cable or Wi-Fi, whether the machine has been given an address, whether it can reach the router, whether names are being looked up. You do not need to follow every term to hear whether each step rules something out.
The whole office loses its internet connection at once. What do you check first, and who do you tell?
Why ask it
Everyone being down points away from individual machines and toward the router, the line or the provider. A grounded answer goes to the equipment and its lights, checks the provider's status page from a phone, and has a fallback in mind, such as a second line or a mobile hotspot for whoever takes payments. The 'who do you tell' half is the part many technical people forget.
A shared printer stops working for one department. How do you work out whether the fault is the printer, the network or the computers?
Why ask it
Printers are a daily reality, and this shows whether the candidate can split a problem in half. A neat answer prints from another department's machine, runs the printer's own test page and asks what changed overnight, so each result removes one suspect. Reinstalling the driver on every computer in turn is effort, not diagnosis.
What do you ask a user before you touch their machine?
Why ask it
The answers you want are the ones that save an hour: what exactly did you see, when did it last work, what changed, does it happen to anyone else. Asking to be shown the problem is better still, because a description often differs from what happened. A technician who asks nothing fixes what they assume is wrong.
Something worked yesterday and does not work today. What does that tell you?
Why ask it
It tells an experienced person to look for what changed: an overnight update, new software, an expired password or certificate, a setting someone else altered. Hear whether they would look at a record of recent changes or ask colleagues before poking at the machine. That habit is the difference between finding a cause and trying fixes until one sticks.
What do you do when you have tried everything you know and it still is not fixed?
Why ask it
Every IT person hits this regularly, so 'that rarely happens' is not believable. A sound answer has stages: read the error and the logs again, search the vendor's documentation, ask a colleague or open a support case, and set a point at which they hand it up. Listen too for whether they tell the waiting user what is going on.
A problem disappears after a restart. Are you finished?
Why ask it
Sometimes yes, and an honest candidate says so: a one-off on one laptop is not worth an afternoon. The better ones add that they note it on the ticket and look for a cause if it comes back, because a server that needs restarting every Monday has a fault nobody has found. A flat yes and a flat no both miss the judgment involved.
Tell me about a fault that took you days to find. What finally gave it away?
Why ask it
You should be able to follow the story without the vocabulary: what they suspected, what they ruled out and how, and the clue that broke it. Be wary if the ending is that it fixed itself, or that a vendor found it and they cannot say what the cause was.
How do you fix a problem for someone working from home, on a machine and a network you cannot see?
Why ask it
Remote support adds unknowns: the home router, the family's other devices, a user who has to be your eyes. Expect remote-control tools, a request for a photo or screenshot of the error, and patience in talking someone through steps over the phone. Ask what they do when the remote tool itself will not connect, which is the case that tests them.
Networks and systems
Windows, Mac or Linux: which have you supported day to day, and which would slow you down?
Why ask it
Hold the answer against what is on your own desks and servers, not against a general idea of being good with computers. Someone who has only supported Windows can learn an office full of Macs, but there is a learning curve and an honest candidate says so. Ask which versions as well: experience that stops at a system its maker no longer supports suggests a workplace that did not keep up.
In plain language, what happens between typing a web address and the page appearing?
Why ask it
A classic because the answer can last thirty seconds or thirty minutes, and you can judge the short one. The outline: the computer looks up the name to find a numeric address, connects to the server at that address, asks for the page and displays what comes back. Order and clarity count for more than depth here, so a tangle of acronyms with no sequence is a poor sign.
What do DNS and DHCP each do, and what does a user notice when one of them fails?
Why ask it
DNS turns names such as a website address into the numbers computers use, and DHCP hands each device its address when it joins the network. The symptoms are the test of real experience: with DNS down, sites will not load by name though the connection is up, and with DHCP down, a device that has just joined cannot get on at all. Definitions with no symptoms suggest reading more than fixing.
How do you set up a new employee for their first day, and what do you do on the day someone leaves?
Why ask it
For a starter, hear accounts, the right access for the role, a prepared laptop and sign-in protection arranged before day one. The leaver half matters more: access closed promptly, equipment returned, mail and files handed to someone, licenses recovered. A candidate who covers only the first half is the kind who leaves old accounts open.
How do you decide who can open which files and systems?
Why ask it
People should get what their job needs and no more, granted through groups by role instead of person by person, and a candidate who has run this says something close to it. A good answer includes who approves a request, usually the person's manager or the owner of the data, and a periodic look at who still has what. 'Whoever asks' and 'everyone has everything, it is simpler' are both worrying.
How do you keep computers and servers updated without breaking something people rely on?
Why ask it
Updates close security holes and now and then break things, so the answer should hold both. Expect a small test group first, a set time for restarts, a way to see which machines missed the update and a way back if one goes badly. Leaving updates off because one caused trouble once is the answer to worry about.
Which cloud services have you administered, and what is different about looking after something you cannot walk up to?
Why ask it
Many companies now run email, files and sometimes servers with a provider such as Microsoft, Google or Amazon. Thoughtful candidates mention that sign-in and permissions become the front door, that costs can climb unnoticed, and that a provider keeping the service running is not the same as a backup of your data. What a given provider covers varies, so a good candidate says they would read the agreement and not assume.
How would you set up Wi-Fi for an office that has visitors coming and going?
Why ask it
Separation is the whole answer: guests get internet on their own network and cannot see company computers, printers or files. Extra credit for thinking about coverage in the far meeting room and for a staff password that is not written on the whiteboard. One network for everyone with a password unchanged in years is the common bad setup, so see if they name it.
How do you keep track of every laptop, license and account the company is paying for?
Why ask it
You cannot secure or budget for what you do not know you have. A good answer names a living record, a spreadsheet at small scale or an inventory tool at larger scale, with who has each device, when it was bought and when support for it ends. Ask how they found things that were missing from the list, because there always are some.
How do you find out that something is down before a user tells you?
Why ask it
This separates reacting to complaints from running systems. The proactive version is monitoring that sends alerts on the things that matter, such as backups failing, disks filling, certificates about to expire or a server going quiet, with someone actually reading those alerts. If the honest answer is that users are the monitoring, ask what they would set up first here.
What repetitive job have you scripted or automated, and what was it written in?
Why ask it
Scripting is not required for every support role, but it marks someone who would set up twenty laptops the same way instead of by hand. PowerShell and Bash are the usual tools, and a real example comes with what it replaced and what went wrong the first time. For a junior hire, wanting to learn counts; for an administrator, having nothing to show is a gap.
Security and backups
A user tells you they clicked a link in a suspicious email and typed in their password. What do you do in the next ten minutes?
Why ask it
Speed and order matter here, and so does the first sentence, which should thank the user for reporting it. Then: change the password, sign the account out everywhere, look for anything the intruder set up, such as mail being forwarded elsewhere, and find out who else got the email. Scolding the user teaches the whole office to stay quiet next time.
How were backups done in your last job, and when did you last restore something from one?
Why ask it
If you ask only one security question, ask this. The full answer covers what is backed up, how often, where the copies live (at least one somewhere the main systems cannot reach) and a recent restore, either a real one or a test. A backup nobody has restored from is a hope, and a candidate who knows that will say so unprompted.
Someone phones to say they are locked out and need a password reset right now. How do you know it is really them?
Why ask it
Resetting a password for a caller who is not who they say they are needs no technical skill at all, which is why it gets tried. A careful candidate describes a check before the reset: calling back on the number on file, a word with the person's manager, a video call. Push on what they do when the caller is senior and in a hurry, since that is when the check gets skipped.
Ransomware has locked every shared file overnight. What does your first hour look like?
Why ask it
Calm, ordered answers are what you want: disconnect affected machines to stop the spread, tell whoever leads the company, check whether the backups are intact, and bring in outside help. Decisions about paying, insurers and who must be notified depend on your policies and the law where you are, so a sensible candidate says who they would ask instead of deciding alone. Wiping and rebuilding at once can destroy the evidence of how it got in.
How do you get a whole company using strong passwords and a second sign-in step without a revolt?
Why ask it
The technical half is short: a password manager, a second step such as a phone prompt on email and on anything holding money or personal data, and no shared logins on sticky notes. The human half is the real question. Listen for how they would explain it, help people through setup and handle the senior person who wants an exemption.
Who should have administrator rights, and how do you handle your own?
Why ask it
As few people as possible, and not for everyday work, is the answer in one line. Careful administrators keep a separate account for admin tasks and read email on an ordinary one, so that one bad click does not hand over the whole network. Giving staff admin rights on their laptops to cut down on requests is a shortcut that tends to be paid for later.
A senior manager asks you to switch off a security rule for them because it slows them down. What do you say?
Why ask it
Whoever holds this job will face it, usually from someone who outranks them. The good answers find out what the manager is trying to get done, offer a safe way to do it, and take a real exception to whoever owns the policy instead of granting it quietly. Both 'rules are rules' and 'they are the boss' fail, in opposite directions.
A laptop with company files on it is left on a train. What happens next?
Why ask it
Preparation shows here: was the disk encrypted, can the device be locked or wiped from a distance, and how fast are the owner's passwords changed. Whether customers, an insurer or a regulator need to be told depends on what was on it and where you operate, and a careful candidate raises that question without claiming to know your answer. Ordering a replacement is the last step, not the first.
This job would let you read anyone's email and files. How do you treat that kind of access?
Why ask it
You are hiring someone with keys to everything, so this is about character as much as skill. Hear that they look only when a task needs it, that a request to see someone's mailbox goes through whoever your policy names and not through a hallway favor, and that such access is recorded. What an employer may look at varies by place and policy, so 'I would check what the rule is here' is a good sign.
Users and outages
Explain what a firewall does, as you would to someone in our accounts team.
Why ask it
This is a technical answer you can grade yourself, because the test is whether you understood it. A firewall decides which network traffic is allowed in and out, and a good explainer reaches for something everyday, like a doorman with a guest list, and checks you are still with them. If you are lost after a minute, your staff will be too.
Tell me about the angriest user you have had to help. What did you say first?
Why ask it
People meet IT on their worst day: a deadline, a dead laptop and no patience left. The good versions acknowledge the deadline before the diagnosis and say what will happen next and when. Watch the tone of the retelling, because contempt for 'users' in an interview becomes rudeness at the desk.
Three things break at once: the owner's email, a new hire's login and the card reader at the front desk. Which do you take first?
Why ask it
There is no single right order, which is why it works. A thoughtful candidate asks what each one is costing, usually lands on whatever stops money or the most people, and tells the other two when to expect help. Swap in three items from your own business, and be suspicious of an answer that simply goes by rank.
Tell me about the worst outage you have been part of. What did you do first, and how did people know what was going on?
Why ask it
The opening minutes show whether someone works a problem or flails at it: confirming what is actually down, checking what changed, deciding whether to fix or fall back. On the second half, find out who they told and how often they updated them while the fix was still unknown. A candidate with years in the field and no outage story has been lucky or is being careful with you.
A user comes back with the same problem every week. What do you do differently the fourth time?
Why ask it
A repeat visitor means the fix so far has treated a symptom. By the fourth visit the approach should change: looking for the cause, replacing the failing part, or sitting with the person to see what they actually do. Blaming the user may even be accurate, but a good technician turns that into ten minutes of training instead of a complaint.
Tell me about a mistake of yours that took something down or lost data. What happened afterwards?
Why ask it
Hold administrator rights for long enough and you collect one: the wrong cable pulled, a change pushed to the wrong group. You are listening for how fast they owned up, how it was put right and what they do differently now. 'Never' from an experienced candidate usually means never admitted.
How do you turn down a request, such as software someone wants installed, without making an enemy?
Why ask it
IT says no often, and how it is said decides whether staff bring problems forward or work around the rules. Good answers give the reason in plain words, offer an approved alternative and say who could authorize an exception. A candidate who enjoys the no is as much a risk as one who cannot say it.
This role includes some calls outside office hours. What has on-call been like for you, and what made it workable?
Why ask it
Leave this out if the job truly ends when the office closes. Otherwise describe your real out-of-hours expectation before you ask, including how often it comes up and how it is compensated, since candidates decide on this. Useful answers talk about clear rules for what counts as urgent and about fixing the causes of repeat night calls. Keep it to the work: ask whether they can meet the requirement, not about their home life.
Process and closing
What do you write down after you fix something, and where does it go?
Why ask it
Documentation is what turns one person's fix into the company's knowledge. A good record has the symptom, the cause and the steps, in a ticket or shared notes where the next person can search for it. 'It is all in my head' is a warning in anyone, and a serious one in a sole IT hire.
If you were away for two weeks with no phone, what would a stand-in need to keep things running, and does it exist where you work now?
Why ask it
This asks whether they have made themselves replaceable, which is what you want in whoever holds your systems. The things to hear about are an up-to-date list of systems, passwords in a shared vault that a named second person can open, and written steps for the regular jobs. If none of it exists in their current job, ask why not, and what they would do about it in their first months with you.
Before you change something many people rely on, what steps do you go through?
Why ask it
This is change control, whether or not a small company calls it that. The steps to hear: tell the people affected, pick a quiet time, take a backup or snapshot, test afterwards, have a way back and note what was done. 'I just do it at lunch when it is quiet' covers one of those six.
How do you use a ticketing system, and what do you do with requests that arrive as a tap on the shoulder?
Why ask it
Tickets are how a manager who is not technical sees where IT's time goes. Sensible candidates help the person at their desk and still log it, so the record is complete and patterns show up. Someone who treats ticketing as bureaucracy will leave you with no evidence when you need to justify a hire or a purchase.
How do you decide whether to repair, replace or keep an aging piece of equipment, and how do you make the case for the money?
Why ask it
Whoever runs IT in a smaller company is also the one asking for budget, so you need someone who can argue in business terms. Good answers weigh age, whether the maker still supports it, the cost of it failing on a bad day and what a replacement would allow. 'It is old' is not a case; 'it holds the only copy of the order history and parts are no longer made' is.
Tell me about a time the fault was on a vendor's or a provider's side. How did you get them to fix it?
Why ask it
Much of a small company's IT is other people's products: the internet line, the phone system, the accounting package. You want the person who calls support with the evidence ready, what was tested, when it started and the error word for word, and who knows how to ask for a case to be passed up a level. A candidate who only waited, or only got angry, will take longer to get your line back.
What would you want to look at in your first week here, before changing anything?
Why ask it
Experienced people ask to see the backups, who holds administrator access, what is out of support and what is written down, and they talk to staff about what annoys them. A plan to replace your whole setup by Friday, before understanding why it is the way it is, should make you nervous.
Would you be willing to do a short practical task, such as fixing a fault we have set up on a spare laptop?
Why ask it
Half an hour of watching someone work shows you things no answer can. If you are not technical, have your current IT person, an outside provider or a knowledgeable friend set the task and say what good looks like. Give every candidate the same one, keep it short, and note whether they talk through what they are doing.
I cannot judge all of your technical work myself. Who could I talk to who has seen it up close?
Why ask it
Saying this openly is fine, and good candidates respect it. A former manager speaks to reliability, but a fellow technician or an outside provider who worked beside them can tell you whether the systems they left behind were sound. Ask that referee what was documented and how the handover went.
What would you need to know about our setup before you would say yes to this job?
Why ask it
The questions an IT candidate asks are a preview of their first month. Ones about backups, how old the equipment is, who approves spending and what broke most recently come from someone already thinking about the job. If they ask nothing about your setup, they are either not curious or planning to find out the hard way.
How to interview IT candidates when you are not the expert
Practical guidance for the conversation itself
Before the interview
Decide which IT job this is
Support, systems administration, networking and the one-person generalist role share a title on many postings and little else. Write down what the hire will spend most days doing: answering staff, keeping servers and cloud accounts running, or all of it. Then weight the list to match. A support hire needs more from Troubleshooting and Users and outages. An administrator needs more from Networks and systems, Security and backups, and the change questions under Process and closing.
Write down your own setup first
Before you meet anyone, list what you have: roughly how many people and devices, where email and files live, who does the backups today, what broke most recently. The scenarios on this page work best with your own details swapped in. If you cannot fill in the list, that is useful too: it tells you the hire's first job is to find out.
Borrow a technical ear
If nobody on the hiring side is technical, find someone who is for one stage: an outgoing IT person, an outside provider you already pay, or a contact who runs IT elsewhere. They can set the practical task, sit in on one round, or read your notes afterwards and tell you which answers were sound. Method, honesty and manner you can judge yourself, and they carry a good part of the decision.
Choose ten to twelve questions
An hour has room for about that many with follow-ups. Take two from Background, three or four from Troubleshooting, and at least one each on backups, a security incident, a difficult user and making changes safely. Ask every candidate the same core set so that you compare answers and not moods.
Check the credentials the job depends on
If a certificate, a clearance or a license is a requirement of the role, confirm it with the body that issued it instead of taking the resume's word. What a given kind of work requires, and which checks an employer may run, differs by country, state and industry, so ask whoever handles hiring rules where you are.
In the room
Ask for the steps, not the answer
'What causes a slow computer?' invites a list anyone could memorize. 'Walk me through what you do' produces an order of work, and that order is what you are hiring. When a candidate jumps to a fix, ask what they checked before it.
Use the last thing that broke
Describe a real recent problem from your own office, in the words of the person it happened to, and ask what the candidate would do. You know how it ended, so you can tell a plausible path from a guess. It also shows them what the job is like.
Ask for it again without the jargon
When an answer loses you, say so and ask for it in plain words. This is not rude. It is the job: the person you hire will explain outages to you and passwords to everyone else. A candidate who can only repeat the same terms more slowly will do that with your staff as well.
Make 'I do not know' safe
Say early on that you would prefer an honest 'I would have to look that up' to a confident guess. In IT a bluff costs more than a gap, because a wrong command typed with confidence is one way data gets lost. Follow a 'do not know' with 'how would you find out?' and judge that answer.
Keep the practical task small
Twenty to thirty minutes on a spare machine with one planted fault is enough: a network setting changed, a full disk, a printer that will not print. Tell the candidate they may search online, as they would at work, and ask them to talk as they go. What you watch is the order they check things in and whether they leave the machine tidy.
Judging answers when you are not technical
Order tells you more than vocabulary
A good troubleshooter moves from the simple and likely to the complicated and rare, and each step rules something out. You can hear that structure without knowing the terms. Fluent jargon with no sequence is the more common way to be fooled.
Listen for questions before fixes
Strong candidates ask you things: how many people are affected, when it started, what changed. Count the questions in their answers to the scenarios. A candidate who never asks one is solving a problem they have imagined.
Listen for the person in the story
In every account of a fault or an outage there was someone waiting. Notice whether the candidate mentions telling them what was going on, and how they speak about them. Skill without that makes a technician staff avoid, and problems nobody reports.
Past tense beats 'I would'
'I would check the logs' is a plan. 'I checked the logs and found the backup had been failing for a week' is experience. When a question about the past gets a hypothetical answer, ask once more for the actual occasion.
Answers that should worry you
A few carry across every group: nothing has ever gone wrong, users are the problem, the fix is always to replace or reinstall, backups 'just run', documentation is for later. One of these is a point to probe. Several together describe how your systems would be run.
After the interview
Score alone, then compare
Write a line on each core question straight after the interview, before talking to anyone else: what was said, not how it felt. If a technical helper sat in, have them score separately. Where your marks differ, it is often because one of you heard confidence and the other heard content.
Ask the referee about a bad day
References for IT roles are most useful on specifics. Ask about an outage or a mistake: how the candidate behaved, who they told, what state they left things in. If the candidate has already left that job, ask whether notes and passwords were handed over properly.
Plan who holds the keys before day one
Whoever you hire will have access to everything, so decide beforehand how administrator access is granted, recorded and shared with at least one other person, whether that is an owner, a second technician or an outside provider. A good candidate will welcome this. One who resists a second keyholder has answered a question you did not ask.
Topics to leave alone
Out-of-hours work and travel between sites make it tempting to ask about family, health or age. Describe the requirement and ask whether the candidate can meet it. What an interviewer may ask differs from place to place, so check the rules where you hire before the first interview.