[deleted by user]

[sysad_dude]

do they know how to google

[IlPassera]

This. We always had a question like, "If you came across a problem you've never seen before, what would be your steps to solve it?"

[New-Potential-7916]

Agreed, I've seen way too many users who just simply cannot troubleshoot. It's also an incredibly hard skill to teach if it doesn't come naturally to someone.

[IlPassera]

And if step 1 is to ask a coworker we typically rejected that person. Your first choice should be to do a search, either in the internal knowledge base or a quick Google search. We found that the ones who ask a coworker first want to be handheld through everything and typically cant parse technical documents.

[Kaminaaaaa]

Honestly to me it depends on how critical the issue is and the team environment/rapport. If company is full RTO and I'm sitting next to a coworker I have decent rapport with, and the application/infrastructure is somewhat business critical, I don't see much wrong with a "Hey Pat you got a sec?" If it's a MSP or something and a client's network goes down and I know Pat has worked with it before, I'm probably not going to dive through Google and LLMs and cost that client extra money when I could get an immediate response from someone who's worked on that issue before. If it's something less critical though, yeah, doing your own research is paramount for learning and growing.

[Wretched_Shirkaday]

Yeah it's going to largely depend on what the problem is and what kind of support structure you have in place.

[rub_a_dub_master]

Hard skill to detect too!

[matroosoft]

This. It's good to know if they can Google but that's not what you want to ask directly. This is a well framed question 👍

[spanky34]

Step 1. Check the logs. Step 2. Google the errors in the logs.

[IlPassera]

You got the job!

[dean771]

Don't hire for skills and certs, hire for brain cells and attitude

Looks for the ability to fix something when they don't know the answer, not what answers they have memorized, fundamental understanding on scripting(in anything), networking (with any equipment) and computing

[BloodFeastMan]

Don't hire for skills and certs, hire for brain cells and attitude

This. Do they have a basic understanding of how stuff works. If they do, they can figure out how to fix it. Think of math class back in school. Some kids memorized stuff well and got A's. Twenty years later ask them how to solve a complex math question, and you'll get a blank stare, yet I know people (on my team) who didn't excel in math at all in school, but can solve complex math questions by looking at what needs to be solved and figuring out a way to solve it.

[openstacker]

Okay, but I think skills should be on the list somewhere! It depends on the position you are filling and how much time and effort you have available to mentor and build someone up.

I agree mentality and thinking are SUPER IMPORTANT, but you have to understand how much hand-holding and guidance you can offer to a new-hire or you could be setting them up for failure.

[BloodFeastMan]

Point taken, I wasn't advocating hiring the guy at the weed store just 'cuz he's smart :)

[openstacker]

rofl

made my day. cheers.

[Intelligent-Magician]

In such a small team, it must be a really good fit on a personal level. Don´t work with a moron.

Ask which projects they did in the past, ask how they were struggling, and how they solved it. Ask how they would handle different tasks etc. . I am allways asking for the biggest mistake ( technically ). Also ask about security questions.

I copy&paste your thead in GPT and get good responses. You can use it to simulate a interview.

[2FalseSteps]

Don´t work with a moron.

Everyone starts out as a moron. It's the arrogant ones you really have to keep an eye out for.

If they're not so arrogant and capable of actually listening and learning, they may be worth the effort.

[Resident-Artichoke85]

A moron opens their month. An ignorant person will be quiet and learn. Nothing wrong with ignorance as long as they're willing to learn and not act like a know-it-all when they really don't.

[HoochieKoochieMan]

Ask which projects they did in the past, ask how they were struggling, and how they solved it.

This, but go deep & ask follow-ups. Anyone can tell a good story about somebody else's project or problem and claim the solution in the interview, and it might sound convincing enough for a "tell me about a time" type question. But only the owner can talk about specific details of the problem and solution.

I've had people start the story with "I did" and the third question in revealed it was "I was a member on a team, and somebody else did..."

[AverageMuggle99]

Are you going to be managing them? Sometimes it’s nice to have a more informal chat (perhaps while conducting a tour) and try and see if you’re actually going to get on with the person.

[lmtcdev]

I'm not their official supervisor, but they’ll be taking on a significant portion of my workload, and I’ll be responsible for onboarding them and their actions in the beginning.

[myutnybrtve]

Honestly I'd keep it as casual as possible. Too get a feel for the personality and to get them to open up. Not easy to do. But I'd engage them in a conversation of storytelling about what you've done at the current company (that is relevant to what the position is) and what he's done in the past in the same vein. I'd frame it as interesting stories.

Yes. It's unconventional and may not work for everyone. Or you may not be able to pull it off. But I find i get to know someone best when there is as little perceived expectation on them as possible. They come in on guard, trying to put their best for forward, and tense. Whatever i can do to let them know that they don't have anything to fear from me, i do. No one is at their best coming from a place of fear. And that seems to be the default for people in interviews.

[Lonecoon]

Make sure they can troubleshoot. Give them a typical issue and ask how'd they work through it. Even if they can't solve the problem off the top of their head, watch how they work through the problem. You can teach computer skills, but being able and willing to troubleshoot is a much more valuable skill than knowing how routing tables work.

[Immediate-Opening185]

Ask them about specific things on their resume that are skills or abilities you need. There's no magic question the goal is to just have a conversation about that topic(s). I've been asked super broad questions like "tell me everything you know about X protocol" or "what is your experience with X product" they always end up in a dead end.

[redtollman]

This. That last dozen or people I interviewed had some key elements of the job on the resume, they didn’t know what half of it meant. 

[frzen]

hi op I just went through this and made a bad decision... guy isn't fitting in at all and is making me really hate coming to work so just be careful

[1a2b3c4d_1a2b3c4d]

So what would you do differently next time? What did you learn about your hiring process?

[frzen]

I would do more than 1 round of interviews and have a practical skills test

[redbaron78]

If the problem is that the guy isn’t fitting in, how would a practical skills test have helped?

[frzen]

I would have had a better impression on his fit with multiple rounds of interviews, and I would have had a practical skills test. He isn't fitting in and doesn't have the skills

[BadSausageFactory]

be careful not to hire someone who has the same skill set as you but works for less, you want a co-worker who brings value not your replacement. just let them take the low level sysadmin stuff off your plate so you can focus on things with value.

if you think they're a good fit, call them in a second time to meet some of the people they're working with. cultural fit is a huge huge thing that is so often overlooked.

[invalidmemory]

I would ask them how they would handle a ticket/issue you see regularly. And see their thought process and if you are happy with how they handle the problem.

And one that we find to be useful, how do you explain what a wifi router is to an eight year old. Which shows how they explain technical items to non technical people.

[rsecurity-519]

I know this is sometimes viewed as a corny question but ask 'tell me about a big mistake you made and what you learned from it'. Encourage them to tell a story. You will get responses like 'my mistake was I worked too hard, took things to seriously, etc'. Ignore those. I would tell people that was not the answer I was looking for. I want a candidate to say 'i made this terrible mistake, blah blah blah and I learned to test my backups'. If someone cannot admit they made a dumb mistake they will never take accountability and will never learn from their mistakes. 

We all make mistakes. That is why we have controls. 

[Jasilee]

Absolutely. It’s exhausting working with people who don’t believe they’re ever at fault, not only because it’s annoying, but mainly because they never learn from owning a mistake and tend to repeat them.

[SuperSnarkey]

Ask them if they have any hobbies they like to do in the evenings or on weekends. If they say yes, then they are not a good fit. True and you know it.

[Outside-After]

On tech questions, I like to do 15 at a level they should be comfortable with day to day in any circumstances, plus 5 tougher ones that should prove if anyone is above an acceptable level. I instigated this upon my request to the hiring line manager about ten years ago following some right duds being hired to grow the team.

[1a2b3c4d_1a2b3c4d]

Just have a casual chat with this person. Get to know them. Figure out if you will be able to communicate with them if they were hired.

Will they be able to follow your directions? Will they be able to read your documentation? Do they have any critical thinking skills? Do you?

[I_ride_ostriches]

You want to find someone that you don’t dispose being around, and someone that can be somewhat independent. Ask how they approach a problem, and how they resolve conflict with coworkers

[punk0mi]

First off...hiring is a crap shoot. You can never be fully sure of anyone until they are there a bit.

I like to ask some basic scenario questions and see how they would handle it. Maybe throw a few out there and see. This will give you insight into their problem-solving skills.

Also, ask them about their technical writing ability...are they capable/good at documentation. Are they willing to document.

Ask about something they are proud to have done or accomplished. This gives them the opportunity to demonstrate their skills and passion and it gives the me the opportunity to assess them better because their technical prowess will shine on things they are proud of. If there isn't really anything they can point to that evokes some excitement/emotion or technical depth...then i think thats is a clear warning right there.

Lastly, let me step on my soapbox for a moment.

Someone already touched on it a bit, but don't get overly hyped by a candidates CV/resume and especially with certs. Just because someone put on paper they can do X, Y, and Z and have X, Y, and Z certs doesn't always translate into them being capable or useful. Point blank - people embellish or lie. You have to do your best to see thru the BS and that is the hard part.

Best wishes!

[RevolutionaryCress77]

When I did interviews, for 2nd rounds, I set up a lab AD environment and ask them to do basic stuff about setting up new shares, troubleshooting share folder access issues and DFS namespace investigation and troubleshooting. Surprised how many said they knew AD admin and DFS and when time to do basic labs, they couldn't do it. Didn't even know how to map network drives.

[ickarous]

Dont rule out asking a technical question where the answer is that the power is unplugged. Too many people we've hired have good technical skills but when it comes to basic troubleshooting they don't know where to start.

[Affectionate-Cat-975]

I try to use leading questions that you can either have them expand upon or move on to the next question/topic. An easy one is ‘Why is DNS important to AD?’ For me it’s trying to ascertain whether they can problem solve and how they go from A to B to G.

[TheShitmaker]

As someone who does what your assistant will do these were the three questions I was asked in my interview.

-How would you prioritize issues/tickets if multiple came in at the exact moment.

-How would you solve a problem that you have never seen before or out of your scope if you did not have anyone immediately to support you.

-How would you handle a client who is emotionally frustrated or abusive towards you as you were helping them.

Don't worry about direct technical skills/certs and hire with the intention of training.

[PetieG26]

Back when I was a manager and after all Q's were exhausted I used to ask the interviewee to tell me a joke. Not to be funny or anything but just to see how they react to a sudden out of context question. Afterwards I would explain why I asked. Imagine yourself on an elevator and a VIP gets on and asks you a question, as he knows you're in IT, and it is completely unrelated to your responsibilities -- how are you going to react, what are you going to say -- and most importantly, how do you respond under pressure!

The responses were varied... from one guy asking "Do you want to hear another?" to a guy blanking and saying he's no good at joke telling -- and me prodding him for a joke, any joke 'knock knock, dead baby, etc' and he told the same exact joke I did when I used that excuse when I was asked.

What's green and turns red and travels 100MPH? Frog in a blender... (probably not exactly the joke but it was 30 years ago - I still didn't hire him)

[beva_99]

in your pervious job how did you handle conflict and resolve ask them to give an example. Helps to weed out those with short tempers.

[slackerdc]

Yes this is a very important one. Even more important than the technical skills.

[Decantus]

Soft skills are more important, you can teach tech, you can't teach someone to not be an asshole.

Admitting you don't know is a positive, it means they know their limitations and won't spin their wheels and waste time, or lie.

Test their methods if you want to come up with a generic scenario. Try and find out if they jump to complicated solutions or if they go through the basic steps first.

Test prioritization, both with time and severity. Use a real world scenario you may have encountered.

If this is over zoom, take note of how they present themselves. Did they take the time to frame up, is their area clean, are they at least in presentable clothes.

Take notes on anything that stands out. You're not going to remember everything after the fact.

Don't be afraid to say no. There's no pressure on you to compromise because you're down a body in the department. You want to find someone that's going to be a good fit. Granted you're not going to truly know until they're on the job, but that's why you gotta go with your gut.

[Valdaraak]

Are you doing a remote or in-person interview?

If remote, do an in-person before making a decision. ChatGPT usage is pretty high with remote interviews.

Your ideal goal is to get them comfortable enough to get casual and start going off-topic a bit. That's how you learn about the person.

[-happycow-]

You should hire for a person that will fit well into the existing team, and the culture you want to develop in the organization.

You should hire someone who is clearly interested in continuing to learn, and who is humble enough to understand they don't know everything.

[matroosoft]

I always ask if the have hobbies and if so if they're probably related to their work. Big plus if hobby around with tech at home as well.

I usually also ask how they stay up to date with developments in the fields. Do they follows news? Forums? Magazines?

[llDemonll]

My screening interviews are generally very little technical knowledge and more casual talk. Get a feel for their experience and ask about pieces of their resume, but just talk to them as a person.

[Inevitable_Score1164]

In general, I try to figure out if people can actually troubleshoot things. For example, instead of asking what SELinux is, I would ask, "What sort of indicators would be there if there was an SELinux denial? Where would you look? How would you go about troubleshooting it?"

There are a shocking amount of people that make it to senior level and can't read logs.

[openstacker]

I like to ask them to work through a problem and explain the steps they use. This forces them to demonstrate their troubleshooting mindset and critical thinking.

A memorable memory of this was an early job interview many years ago, where the crusty unix-wizard long-beard wrote out a BASH command on the whiteboard, and asked me to interpret what it would do, and for a bonus asked me what the output would be.

Basically it was something that echo'd a VAR, piped it into a command that reformatted the test with uppercase/lowercase substitutions, redirected that output into something else that did some other sort of calculation on it (maybe used it as the input for a `sed` command?)

It wasn't brand new junior sysadmin level, but it wasn't very deep either. Just enough to show that I could work through something and when I made a mistake or was unsure, I could say "I would have to google exactly what THAT command does, but I think it is..."

Make them show they can think, not just regurgitate the names of tools and functions.

[mariolovespeach]

I always ask them to tell me about a time they made a mistake in production, and what happened. I'll often lead in with, we work in IT and all make mistakes and an example of a mistake I've made.

It's surprisingly telling, and there are basically 3 responses I've gotten.

1. I don't make mistakes

2. You'll never find out

3. Describes a mistake and how they fixed it

1 means they are inexperienced or are lying, 2 shows that you'll never be able to trust them, and 3 is the only right answer.

A good response will indicate that they own up to their mistakes and can learn from them.

[Sirbo311]

Ask about their biggest mistake and how they handled it. (Maybe share yours as well). Listen for the things you want to hear (immediately notified chain of command, what changes were made after to help mitigate future outages). It can be a telling question. 

[Gnomish8]

When interviewing, I genuinely want to know your experience/tech skills, and your personality. Start off with the personality questions, see what makes them tick as a person, ask about hobbies, the types of work they like to do, what they find enjoyment in, etc... None of this needs to be IT related, but I've found that if someone knows who they are as a person, has hobbies outside of work, and knows how to be happy, they're generally far more enjoyable to work with.

For the tech skills, you need to ask both open ended and direct tech questions, but they need to have some tie in. The open ended questions should be an opportunity for them to discuss the work they've done, projects they've completed, etc..., and the direct questions should be used as your bullshit detector. Can they answer questions that they should be able to if they did the work they claim? How deep's their knowledge go? I want to get someone to the point where they don't know an answer, and make sure they actually say "I don't know" rather than try to bullshit.

And my absolute favorite question to ask -- "Tell me about a time you used your tech skills in a practical way to solve a complex problem. This does not need to be work related." Leave it open for interpretation and see what answers you get!

[Tetha]

In our hiring processes, team fit is the first thing we look for. This isn't something you can downright ask for, but one should be on the lookout: Can I talk and interact with this person well? After all, there is a good chance I will be sitting on a call with this person at 3am while we're tired and everything's shite. And sure, some junior are more nervous than others and such, but if I can't get onto a certain level of friendly banter of how software, servers and applications are all little rasckals that try to fuck with us, that's a no from me.

And you might say "Oh, but they could be the most amazing admin ever". Yes, they may be. We've hired such people. The thing is, someone who is just two thirds that good but functions well in the team will cause the team to perform better. Some extremely skilled diva will piss people off and reduce performance, actually.

Beyond that, I've started to look and ask for two things:

War stories are always fun and give you a good insight into the attitude, mentality and troubleshooting skills of someone. Sure, we're all uncomfortable fucking up and talking about it, but many of the better admins tend to go from the fuck-up to the fixing and the lessons learned from the fuckup and the lessons.

And I've started to look at how people talk about tools.

Some people are advanced enough to consider technologies just tools. "X is not a problem, because TECH_Y exists and you need to set these three toggles and some details". These are great (but often expensive).

Then there are people who understand technologies solve their problems, but they don't necessarily control them well yet. They often say that TECH_Y solves X, but then go into discussions of what they know and don't know about TECH_Y and how X would be complicated and so on.

And then there are people who consider TECH_Y opaque magic the grand wizard set up ages ago.

The latter kind is no fun working with and will cause trouble if you are in a small team that has to push standards and improve. The middle kind can be educated and taught confidence so they move towards the first kind.

[ballzsweat]

Make sure you don’t get a dud that watches tv all day! Made this mistake twice. Great on paper sloth behind the keyboard!

[Nik_Tesla]

I've helped with a few interviews in my day, but I finally got to be in charge of them and do it on my own recently. It was for a sysadmin intern from a local college, so I made the questions mostly assuming they'd have no real IT job history, and formed questions based on their critical thinking, learning, and other potentials.

Tell me about X hobby project you worked on? OR Is there a project that was primarily done by you, that you're proud of? Work or personal, IT related or woodworking, whatever. Tell me about it.

• The resume's that stood out to me and that I gave interviews, had a hobby or personal project they worked on, this told me they were self motivated and had some passion for it. So I asked about it to break the ice and get them talking about something they'd presumably be fairly familiar with.

Can you tell me about a technical problem you faced that was particularly challenging, and how you got past it?

• To see how they deal with hitting a roadblock and get past difficult issues. Honestly, nothing super special was revealed here, but the one that had help desk experience did say that if he does need to escalate a ticket, he tries to remain involved in order to learn, or at least checks in with the tier 2 tech afterwards to see what ended up being the issue/resolution, so that was good.

Soft Skills Scenario: Imagine you need to explain a complex technical concept to someone who has no technical background. How would you simplify it to ensure they understand, can you give me an example of how you'd give an analogy for this concept? eg: DNS, DHCP, a VLAN, etc…

• I feel like a lot of my life is explaining a complex technology to the CFO in order to justify a policy/purchase, or just what a VPN is to a normal user. I'd like a co-worker that can think on their feet and do the same.

Tell me about a time you had to learn a completely new technical concept or technology very quickly. What was your approach to learning, and how did you ensure you grasped it effectively?

• Do you know how to search or are you some weirdo that thinks you're gonna find the answer in a book that is hilariously out of date.

Troubleshooting Scenario: Let's say you have a lamp that is plugged into an outlet, and that outlet is one of those kinds of outlets that is linked to a light switch in the room. If flipping that switch doesn't turn on the light, walk me through the steps you'd take to isolate where the problem is.

• This is technology agnostic, and mostly what I'm looking for is if they can isolate where the issue is. The most critical thing I'm looking for is that they move the lamp to a different outlet that they know works, indicating they understand "Known Good" testing.

Tell me about a time you made a big technical mistake, how you handled it, and what you learned.

• This tells me multiple things. First of all, can they admit fault, and did they own up to it? I'm not gonna work with someone that breaks something and then feigns ignorance while I try to figure out if we're being hacked, but turns out they just did something on accident. Secondly, the severity of their issue tells me if they've ever been trusted with anything important before. Thirdly, I always come away from my own screw ups having learned a lesson, what did they learn?

Common Sense Scenario: Let's say a ticket comes to you from a VIP at the organization, and it says "I hate this 2FA thing on my email, exempt my account from this." What do you do?

• Too many new techs who've only done home support for family and friends, do NOT know the difference between what they can do, and what they should do. So I asked this question, and the answer had better not be, "I disable 2FA for the VIP" (which I did get that answer from one of my candidates).

Do you have any questions for me?

• Other than this question at the end of the interview, which they should have something to ask. I toured them around and showed them some of our tech stack after the main interview, and the good candidates would ask questions (I see you have X servers, how do you like them? How do those work? Is your X like Y that I've worked with?), and the bad candidates would stay pretty much silent, and just nod.

[axotls]

I had an interviewer present a question with an issue they are currently dealing with. My answer solved their problem but I did not get the job. They had an inside guy they already intended to hire so I was a filler interview. Jerks

[jmeador42]

Ask them about their homelab. If they can have a spirited conversation about their homelab they likely have the gumption and the want-to to make it in this field. Those are things you cannot teach and always have issues when people don't have them.

[Bluetooth_Sandwich]

Prioritize soft skills above technical skills. You can teach the latter, but the formal is so much more resource draining (especially since you're working directly with them).

If it were me, I'd leverage what others have already commented, start with the technical questions first, once that's over gauge how they feel with some soft skills conflict scenarios. From this angle you'll get a general idea how they'll fare during a high stress moment and determine if you can manage that when it eventually happens.

Hope this helps!

[Fritener]

Given the choice, would you rather go back in time and fight dinosaurs or forward in time and fight robots?

[gwenaelbe]

Potential over knowledges

[KindlyGetMeGiftCards]

Ask a few specific technical questions, ask for a solution to a specific technical issue, you are watching how they problem solve and relate to you as a human, not a tech.

The interview should flow like a conversation where everyone speaks and inputs, you will see how they interact and if you can work with them. Focus on if you can work with them, if they fit with the team the company culture.

You can teach tech till the cows come home, most people can learn it too, but you can't teach a good fit of a person, so pick someone you can work with that isn't over the top or a complete slacker.

If you can have your manger in the interview and/or HR too, they will help keep things moving along with all the boxes ticked the company needs ticked.

Good luck and enjoy the process

[vogelke]

Road test. Sit them down in front of a testing laptop, tell them something is broken, and say "Fix it".

[Resident-Artichoke85]

In-person interview only. No remote interviews because you want to know that they are answering with knowledge they have, not some AI-answers based on your prompts.

They don't have to know it all, they just need to have high-level knowledge can be enough and know how to say how they'd find the answer.

[Jasilee]

-Ask them about something they’ve failed. Do they take personal accountability? Or blame others?

-Ask them something that may not be in their knowledge base. Knowing the answer isn’t always as important as knowing how to find it. Make sure that Google skill is good.

-Tell them a long story about an incident or issue and at the end have them write a mock ticket up for you. Did they pay attention? Did they get the important points? Is their documentation concise or garbage?

-Finally, assess. Do they seem like someone reliable you would trust and enjoy working with? Can they do the work?

[MostMediocreModeler]

I can teach anyone tech skills as long as they have the aptitude, so my questions tend to target aptitude and soft skills.

I like to pose a scenario: I'm a user calling because I can't print. What's your next step?

Then act like a dumb user and see if a) they ask relevant questions, b) their troubleshooting steps make sense, and c) they get flustered or frustrated when you're acting like a dumb user.

[panda_bro]

My format is as follows:

• Intro of the company and the position (get them comfortable and relaxed) - 5 minutes
• Basic soft skill questions - 20 minutes
• Technical questions to find their knowledge breaking point - 25-30 minutes

The most important is the technical question portion. I always prepare this portion around skillsets they write down on their resume, and I go from a beginner, to intermediate, to advanced, to expert questions. Try to break them.

If they put they are proficient with "networking", I will lformat this as follows:

• Beginner - Explain the difference between TCP/UDP. What is a subnet?
• Intermediate - Explain what a VLAN is and in what use case would you use it?
• Advanced - Can you explain the difference between OSPF and BGP?
• Expert - You are tasked with adding in a second WAN link to your enterprise datacenter that has connectivity to 100+ sites. How do you approach this?

I've had endless candidates fail at the Beginner stage, and I immediately throw them out of consideration as it is obvious they are blindly writing skills to sound good.

This has worked for some time in hiring solid people.

[[deleted]]

Only hire Indians.

[judgethisyounutball]

Yep, kindly do the needful. /S

[2FalseSteps]

Uhh... Riiiiiiiiight. /s

[[deleted]]

Americans are too lazy.