I got my first IT job because I told an interviewer I’d locked myself out of my own domain and then spent twenty minutes looking in completely the wrong place for it.
That’s it. That’s the whole thing. He asked whether I’d worked with Active Directory or Group Policy, and instead of listing features at him, I told him about the Group Policy I’d written at home that shut me out of my own lab.
He laughed. I got the job.
I’d sent sixty-something applications by that point and stopped counting. Most never replied. I had one certificate — CompTIA A+ — and I sat it after the lab was already running, not before. The thing that actually got me over the line was a domain controller on a second-hand box in the spare room, and being willing to say out loud what I’d broken on it.
So this isn’t a list of twelve model answers to memorise. There are plenty of those and they all sound the same, which is exactly the problem — if you memorise twelve answers you will sound like someone who memorised twelve answers.
This is the layer underneath. For each question: what the interviewer is actually measuring, and then how to answer it out of a homelab instead of out of experience you haven’t got yet.
📺 Watch the video: The 12 IT Interview Questions That Decide If You Get Hired
The thing nobody tells you about interview questions
Almost none of the technical questions are testing whether you know the answer.
That sounds like nonsense until you’ve sat on the other side of one. When someone asks “a user can’t log in, walk me through it”, there isn’t a right answer — the user could be locked out, the password could be expired, DNS could have drifted, the DC could be down. They know that. What they’re watching is whether you narrow, or whether you guess.
Same with “have you worked with Active Directory”. They’re not checking your definition. They’re listening for whether you can say where things live.
Once you see that, the whole interview changes shape. You stop trying to have the right answer and start trying to show the right process — and a homelab is the single best place to get one.
I’ve grouped the twelve the way an interview actually runs: the questions that screen you, the technical ones, and the ones about how you behave when something’s gone wrong.
Tier 1 — The screening questions
These four decide whether they spend the next hour on you. Nobody’s testing technical ability here.
1. “So, tell me about yourself.”
What they’re really testing: whether you can edit. Can you pick the ninety seconds of your life relevant to this job, or do you start at birth and work forwards.
Nobody fails this on content. They fail it on length.
Three parts is the whole answer:
- Where you are now, in the honest words. “I’m in manufacturing, been on shift work about ten years.”
- Why you’re here — one line, hold the detail for question two.
- What you’ve built. Land on the lab.
Finish on the lab, not the old job. Whatever you say last is the thing they ask the follow-up about, so hand them the question you want to be asked.
2. “Why do you want to get into IT?”
What they’re really testing: whether the motivation survives a bad week. “I’m passionate about technology” is free to claim and they’ve heard it four times today. They’re listening for a reason that cost you something — because that’s the one that’ll still be there in month four when the queue is horrible.
Mine: I did ten years of shift work in a process plant that makes chicken feed. Twelve-hour shifts, nights, weekends. My son was born and I wanted to be home at night.
Nobody else on the shortlist has got that one.
If you’re changing careers, your old job is not a gap to apologise for. Shift work means you’ve done handovers, worked to a process, and turned up at 4am when you didn’t want to. Say that out loud — it’s the part nobody else on the shortlist has.
3. “You’ve got no IT experience. Why should we hire you?”
What they’re really testing: whether you get defensive. They already read your CV. They know what’s on it. This question isn’t for the information — they’re watching your face.
Don’t argue with the premise and don’t apologise for it. Redefine the word:
“No, I’ve got no paid IT experience. Here’s what I have got — I’ve built a domain, I’ve broken it, and I’ve fixed it. Want me to walk you through it?”
You agreed with them and handed them the next question in one sentence.
The word to kill is “just”. “I’ve just been messing about at home.” You built an enterprise directory service on second-hand hardware. Don’t sell it as messing about.
4. “What have you been doing to learn?”
What they’re really testing: consumer or builder. Everyone’s watched a course. They want to know whether anything you learned ever got stood up and left running.
Name the specific thing, not the category. Not “I’ve been studying Active Directory” but:
“I’ve got a domain running at home —
trevtech.lab. The DC’s on192.168.10.10, it runs its own DNS and DHCP, there’s an OU structure with a Group Policy that actually applies. It’s on Proxmox so I can snapshot it before I break something.”
Specifics are unfakeable. Anyone can say “Active Directory”. Only someone who’s done it says “it runs its own DNS” — and the person interviewing you knows that.
Have one number ready too: how many VMs, how many users in the lab, how long it’s been running. One number does more work than three adjectives.
Tier 2 — The technical ones
5. “Have you worked with Active Directory or Group Policy?”
What they’re really testing: have you touched it, or have you read about it. The tell is whether you can say where things live — not what AD is.
Navigate out loud, like you’re sitting at it:
“Yeah, I run one at home. If I need to unlock someone that’s Active Directory Users and Computers, down the left into the domain, into the
IT-AdminsOU, right-click, properties, Account tab, unlock. Group Policy’s the other console, and my policies are linked at the OU, not at the domain root.”
That last bit matters and it’s worth understanding rather than reciting: linking at the OU instead of the domain root is the difference between a policy that hits one team and a policy that hits everybody. That distinction is the entire reason OUs exist.
Someone who’s only read about it names concepts. Someone who’s used it names menus. It’s the fastest tell in the room.
6. “A user can’t log in. Walk me through what you’d check.”
What they’re really testing: whether you have an order or you guess. Broad to narrow, cheap checks first.
Say the order out loud before you start answering — “I’d go broad to narrow” — because you’ve just told them how you think before you’ve said a single technical word, and that’s the thing being marked.
Then the funnel:
- Is it them, or is it everyone? One call settles it.
- Is the account locked or the password expired? Cheapest check there is.
- Is it this machine, or any machine?
- Is the domain controller actually answering?
Here are the three commands worth being able to say out loud for step two and step four. These are exactly what I run in the lab:
# Is the account actually locked, and when was the password last set?
Get-ADUser bwayne -Properties LockedOut, PasswordLastSet, PasswordExpired |
Select-Object Name, LockedOut, PasswordLastSet, PasswordExpired# Unlock it — one user, one line
Unlock-ADAccount -Identity bwayne# Is the client actually talking to the domain controller?
# 389 is LDAP — if this comes back False, it's not a password problem
Test-NetConnection -ComputerName DC01.trevtech.lab -Port 389I had exactly this in my own lab: a client that couldn’t log in because its DNS had picked up the router instead of the domain controller. Nothing wrong with the account at all — the machine simply couldn’t find the domain. A domain-joined machine finds its DC through DNS, so get DNS wrong and everything downstream looks like a password problem.
7. “Someone’s lost access to a shared folder. Where do you look?”
What they’re really testing: whether you know permissions have two layers. Share permissions and NTFS permissions, and the effective permission is the more restrictive of the two.
Share permissions are the door to the building. NTFS permissions are the lock on the office. You can be let in the front door and still not get into the room — and the error message looks identical either way.
Then the bit that gets you the nod: check group membership before either of them. Real file server problems are almost never the permissions. They’re who’s in what group.
And the one that catches people: you’ve just added someone to the Finance group and they still can’t open the Finance share. Permissions are right, the group’s right — they just haven’t logged off since you added them. Group membership is picked up at sign-in, so until they log off and back on, as far as that share is concerned, they’re not in the group yet.
8. “How would you get a piece of software onto 50 machines?”
What they’re really testing: whether you think at scale or reach for a USB stick. This is the sysadmin question hiding inside a help desk interview, and it’s how they work out who’s promotable.
Any answer that scales beats the perfect answer that doesn’t:
“I wouldn’t touch fifty machines. I’d push it — Intune if they’re cloud-managed, Group Policy or SCCM if they’re on-prem. And if it’s part of the build rather than an add-on, it goes in the image, not the deployment.”
The homelab version of this is the strongest flex of the twelve. I built a Windows 11 template on Proxmox — configured once, and every new VM clones off it. Same idea, smaller scale. You do the work once and the machines inherit it.
And if you’ve never touched Intune: you don’t need to have used it. You need to know the shape of the answer. “I’d push it centrally rather than touch every machine, and here’s how I’ve done that at small scale.” The tool is a detail.
Tier 3 — How you behave when it goes wrong
Every one of these is really the same question: what are you like at 4:45 on a Friday.
9. “A user’s furious and it’s not your fault. What do you do?”
What they’re really testing: whether you need to be right. The tech who has to establish it wasn’t their fault is a tech who makes every outage longer.
“Sorry” is not an admission of guilt and you can hand it out free. Sorry that it’s happened, not sorry that I did it. Then tell them what you’re doing next and when you’ll come back to them — because most of the anger isn’t about the fault, it’s about not knowing when it ends.
The phrase that ends most of these: “I’ll come back to you by three either way.” Either way. Even with nothing.
10. “Tell me about something you couldn’t fix.”
What they’re really testing: whether you know when to escalate, and whether you escalate with information or with a shrug.
The fix isn’t the point. The handover is. Never say “I escalated it” as a whole sentence — say “I escalated it with…” and then finish it.
“It’s not the account, it’s not the client, and the DC responds on 389.”
That’s something a second-line engineer can actually pick up. A ticket handed up with no notes just starts the whole thing again one level up. Escalation isn’t giving up, it’s routing — the only bad escalation is one that arrives empty.
11. “Tell me about a time you broke something.”
This is the one they decide on. It comes late, it sounds casual, and the room has usually relaxed by then. That’s not an accident.
What they’re really testing: two things at once. Are you honest — because everyone has broken something, and the person who says they haven’t is either lying or hasn’t done anything. And then the real one: did you learn the mechanism, or did you just learn the fix.
This is the question that got me my job, and I answered it with a homelab.
A rehearsed answer proves you prepared. A real one proves you’ve got somewhere to prepare from.
Four parts, all short:
- What you were doing
- What broke
- How you found it
- What you changed so it can’t happen again
Most people leave off the fourth one. It’s the one being marked.
And a lab break is a completely legitimate answer here. You do not need to have broken something in production. Say “in my own lab” and the honesty does the work.
12. “Do you have any questions for us?”
What they’re really testing: whether you’re interviewing them back. “No, I think you’ve covered everything” reads exactly one way — any job will do.
Three, ready, and they all do double duty:
- “What does the first ninety days look like for someone in this role?” — you sound like you’ve already started.
- “What’s the environment — on-prem, hybrid, all cloud?” — you’ve just told them you know those are different, and you get a genuinely useful answer.
- “What’s the thing that goes wrong most often here?” — everyone loves answering this, and it tells you more about the job than the ad did.
Write them on a pad before you go in and let them see you look at it. Prepared is not a weakness in this room.
The last five minutes are the ones they remember when they talk about you afterwards. It’s the only part of the interview whose content you control.
The four homelab projects that answer most of these
You don’t need twelve separate projects. Four builds cover the technical half of this list and give you something concrete to say on most of the rest.
| Build | Questions it answers | What you can say because of it |
|---|---|---|
Active Directory on trevtech.lab — DC, OUs, users, groups | 4, 5, 6, 11 | Where things live, and the Group Policy you broke |
| DNS & DHCP on the DC | 4, 6, 10 | Why a login failure is often a name-resolution failure |
| File server + share and NTFS permissions | 7, 10 | The two-layer answer, from having been bitten by it |
| Windows 11 template on Proxmox | 4, 8 | Build once, deploy many — at any scale |
None of it needs a rack. My first lab was VMs on my gaming PC. The Dell R730 came later — after I already had the job. It was the upgrade, not the start.
The mistakes that cost the job
- Waiting until you feel ready to apply. You won’t feel ready. The job spec is a wish list, not a gate. I waited far too long.
- Chasing five technologies at once. One domain built properly beats five things half-watched. Depth is what survives a follow-up question.
- Putting the lab on one line at the bottom of your CV under “interests”. That’s what I did. It should be a projects section with the technologies named — it’s the only evidence you’ve got, so put it where they’ll read it.
- Bluffing. “I don’t know, but here’s how I’d find out” is a passing answer. A confident wrong answer is not.
- Not asking what the environment is. You’ll end up interviewing for a job you can’t do, or talking cloud at a shop that’s entirely on-prem.
Get the worksheet
I’ve put all twelve on a single page — the question, the one-line “what they’re really testing”, and a blank box under each one to write your own answer in.
That’s deliberate. It’s a worksheet, not a script. Fill the boxes in with your own lab and you’ll sound like you. On the back: the four homelab projects above, so you know which build to do first.
Get the free 12-Question IT Interview Cheat Sheet →
What’s next
The AD build that half of these answers come out of is a full series on the channel — Active Directory from zero, start to finish, on hardware that costs less than a night out.
There’s also a dedicated PowerShell video planned that goes properly into the commands above and the rest of the one-liners worth knowing on day one.
📺 Watch the video: The 12 IT Interview Questions That Decide If You Get Hired
☕ Support the channel: https://buymeacoffee.com/trevtech
— Trev | I broke it. Fixed it.
Tags: homelab · it interview questions · help desk interview · career change into it · active directory · group policy · proxmox · entry level it · enterprise IT
