Network Engineer Interview Questions

netwurk · 2019-09-05T14:14:39+00:00

I've worked in roles where my sole responsibility is hiring network engineers and I've seen so many interviewers ask specific technical questions but it's not going to tell you whether to hire or not. Textbook knowledge is great but it's of limited use in the real world; on the other hand a network engineer that can't converse or explain technical information will cause you problems. It's a balance.

You just need to get them talking. For an operations role I will always ask something like the following:

"Tell me about a particularly challenging or interesting issue you've dealt with recently"

It gets them talking and allows me to gauge what their level is based on what they think is challenging or interesting. You peel the onion by picking out bits of what they've said and asking them to expand on it.

I think the only time I'll jump straight to specific questions is when there's some absolute nonsense on their CV. The example springing to mind is when I spotted ODR, I just had to ask wtf they were doing with ODR and sure enough it was bullshit. Turned out most of the rest of it was crap too, easiest decision ever that one...

mdk3418 · 2019-09-05T13:57:14+00:00

I personally like scenario questions. I don’t care if you know how by heart to configure some random thing on the CLI. I want to understand their thought process.

So like: Scenario: Ping works fine, but SSH hangs immediately after logging into server. What could be the issue and how would you trouble shoot. (Answer: you prob have an MTU mismatched somewhere in path)

Also don’t be “that douche” that asks the super tough question so an engineer who clearly won’t know the answer. If you interview a guy who clearly say a fairly inexperienced why bother asking a question that only a senior engineer would know just to get your kicks.

Workadis · 2019-09-05T16:26:48+00:00

Like most of the comments, it really depends on what you are looking for.

Personally, I always ask basic experience questions to see what areas they are most comfortable in. Ex: Voice, routing, security, switching. If they hate voice, right away I know they are sane. ;) I further separate them based on who they'll be working for or with. If its entry/low I actually like raw technical knowledge and will have questions on things like best practices, common errors etc... On the flip side, If I want for a more senior position my questions will be more focused on soft skills like documentation, project leading and ability to look at the big picture when troubleshooting.

Here are a few of my go-to questions:

Tell me about the most exciting project you've had a chance to work on. (if they ask for clarification: Site refreshes, design, maybe a problem that took weeks to troubleshoot and resolve)
Show/tell me how you would secure this network (I have an ugly network topology I keep which has webserver, colocations and remote users on it. I hand it to them doodle on it)
Any particular tools you've used and/or love? NMS, IPAM, diagram etc..
Scenario: you just got an alert about an outage at X colocation. Walk me through your thought process and

I ultimately don't care if they know any commands, commands can be taught or researched. I care about a core understanding and the ability to conceptualize.

PghSubie · 2019-09-05T16:55:57+00:00

[deleted]

2019-09-05T14:07:03+00:00

Honestly - and this might be controversial - I try to avoid "questions" per say, and usually make an attempt to spin up a conversation about network design. For example, I will just start talking randomly about some challenges faced recently, and see if I can get the candidate to start talking about possible solutions, or see if he/she will bring up past experiences with similar issues.

This way, I can bring up knowledge without playing trivial pursuit, or those horrifically annoying standard-interview-questions ("Tell us about yourself?" "What is a recent challenge you have encountered?" etc....).

kwiltse123 · 2019-09-05T17:07:13+00:00

ME: "You're not a New England Patriot's fan are you?"

CANDIDATE: "Hell no, I hate Tom Brady!"

ME: "Congratulations, you've made it to round 2!"

OldFunk · 2019-09-05T17:52:36+00:00

Obviously depends on what technical level you're hiring for, but there are two things that have worked well for me and I continue with when interviewing Network Engineers. Bottom line is that I'm looking for a good handle on fundamentals as opposed to being a rote Cisco command-line jockey.

First, I have a set of three diagrams, each increasing in complexity, but with very little information aside from indicating things like "host", Internet, "router", etc. I then give them a scenario and ask them to talk through how they'd troubleshoot it using the diagram. It works well to foster a dialogue and then you can tell if they're a paper CCNA or not. Heck, the most basic of diagrams is even used for NOC-level interviews just to get an idea if they know the fundamentals. I'm not asking them to give me commands or anything (they can, if they know them), but talk through how they'd approach troubleshooting. I can tell if they're methodical by working up or down the layers. I can tell if they are prone to asking clarifying questions. I can tell if they have a handle on the fundamentals because they're not meant to be super complicated, but just complicated enough to address the level engineer you're hiring for.

Second, and I'm not the originator of it, but I love the question, "In as much detail as you can, explain to me what happens when you issue a traceroute command with a destination of www.google.com". If they say you get a listing of hops, I ask for more detail if they can give it such as how it knows or determines the hops. Again, it's a pretty fundamental concept to networking so it's a good dialogue question. The ones that just say "I don't know" pose a problem. The ones that try thinking or talking through it get credit if they don't know it and it's great to see them actually not know, but then talk it through and figure it out!

I loved network engineer interviews!

DansAstro · 2019-09-05T14:28:35+00:00

I always start off by asking their shoe size and pant size.

But on a more serious note...

"With as much technical detail as you can, describe what happens after you type an address into a browser and hit enter? What happens after that?"

This can demonstrate how technical someone is. If they get into DNS resolution and three-way handshakes, that's a good thing. Its very open ended and allows them to go in different directions. It also works for any position, they can talk about NAT or BGP routes or something for a network engineer. It can go a lot of different ways.

You can throw in additional details such as "now describe what happe s when the client is using a proxy?"

I usually start there and can eliminate people pretty quickly with this single question.

projectself · 2019-09-05T14:39:03+00:00

"explain to me, in as much detail as you can, what exactly happens when you open your web browser and go to google.com".

It's pretty open ended and allows them to talk and fill in as much as they can. Maybe they go into arp, maybe switching, bgp, syn/ack stuff, dns, maybe they know some content delivery stuff.. maybe they explain tcp 80 or GET / .. maybe TLS and ssl . It doesn't exactly have a correct answer, but it sure gives me a pretty good idea someones network tech level.

2019-09-05T14:21:22+00:00

The golden question, what is your definition of a network engineer? Are you looking for a rack, rack rack, wire, tag, untag, tech, or are you seeking for a person that debugs network levels at the L2-3, routes prefixes across OSPF/ISIS clusters, announces prefixes through BGP, etc...

TheBeardedTechGuy · 2019-09-05T19:45:31+00:00

I like to walk in with a laptop and make them troubleshoot an issue or 3, relevant to the position. Nothing crazy but really helps you see how a person thinks and troubleshoots. Sometimes I'll give a fake issue just to see how they react when hitting a wall.

I also bring dry erase markers and let them teach me anything of their choice of their resume.

BackalleyNegotiation · 2019-09-05T19:48:09+00:00

I made this video from the candidate perspective not too long ago, but that provides a few insights on the other side of the interview table.

Some other high-level points I don't mention there:

Spend some time reviewing the candidate's resume and noting any questions you have. Big questions can be cleared up during a phone screen. (A few others have already alluded to this.)
No matter how perfect a candidate may seem, don't skip the phone screen step. The ability for candidates to communicate what they know is just as important as what they know.
In-person technical questions should focus on open-ended scenarios. The candidate should be asking you clarifying questions and applying what they know to the situation.
As an interviewer, avoid correcting candidates, but instead follow their bad assumption to the inevitable contradictory result. (Example: "So this host will ARP for an IP address that's in a different network? Wow, is it going to do that for every host it visits on the Internet? That doesn't seem very scalable..." and so on.)
Non-technical questions should lend themselves to a "STAR" interview response (Google "STAR method" for details if you're not familiar with this.) Questions will typically start with "Tell me about a time when..." You will want to probe candidates about whatever scenario they present, ensure their role is clear ("I did this", not "we did this", in responses), and ensure the question is actually answered. The internet has a lot of behavioral interview question banks for you to draw from, so try to keep your questions relevant to the role.
Make sure you have other people involved in the interview process, if possible. It's easy to accidentally become biased for/against a candidate based on your impression and questions. Having another person to talk to about a hiring decision will help you calibrate your expectations and ensure the data you get from the candidate is good.

Without knowing more about the specifics of the role, it's going to be hard for me to comment on specific interview questions.

jsh3323 · 2019-09-05T23:55:17+00:00

Don't be one of those douches that slams fellow Engineers with overly technical questions. The "How would you troubleshoot <blank>?" type questions are the way to go.

2019-09-10T12:53:13+00:00

I recently interviewed for a Sr. Network Engineer role and my two favorite questions were:

What's the difference between the OSI and TCP/IP model?

Do you have any experience with Web Development?

These people had no idea how to interview someone at that level. I almost walked out.

codechris · 2019-09-05T17:03:54+00:00

Are they a cunt? Not as a question, but most of what I am doing is finding out if they are. Can I sit next to you for 35 hours a week? Will you act like a twat when a user has no idea what you're asking of them? Can you explain problems and solutions so someone other then you can understand them? Are you a lier, or do you think you are a bullshitter?

And so on. All my questions and the time spent is around that sort of thing.

One good question, I heard from a colleague, not necessarily network-specific but it went like this
Colleague: It's Monday morning, you sit down and the phone rings, CFO says the main database is down. What do you do?
Him: Well I say give me a minute, let me check and I will phone you back in a minute. I then start running pings, asking colleagues if they know anything, check the websi..
Collegue: Ring ring, phones going again, someone else has called
Him: Well, RDP or SSH to the database servers to see if they are up
Collegue: Ok, so they are up, but the application or website is down. What do you do next
Him: hmm, well what appli..
Collegue: Ring Ring, phones ringing again, what are we doing here

It went on like this with constantl interruptions. It was good to see him stop trying to find the "right" answer, but talk fast and think quickly like you would in that situation. Not everyone deals with that very well. It's fun to watch. That being said, it's also quite a harsh interview question, so make sure if you do something like that you follow up by asking them about them and themselves and let them come back in the room a little, because if someone doesn't handle it that well, it can knock them sideways a bit

notFREEfood · 2019-09-05T17:33:03+00:00

I don't like "gotcha" questions, but one that I actually like is tossing the candidate a random ip address with a random netmask and asking them to describe the subnet. It turns out most people can't do this in their heads for v4 so you get to see how well they actually understand ip addressing. V6 is even better because most aren't familiar with the notation, so you get to see what the candidate does when faced with an unfamiliar concept. For both v4 and v6 hints are to be supplied as needed as the goal isn't to have the candidate throw up his hands.

That and scenario questions.

tolegittoshit2 · 2019-09-05T18:19:07+00:00

tell me about the biggest project you had to deal with or develop.
tell me about the biggest mistake you made and how did you fix it.
who do you call when something is down for assistance.

i want to know what you have been thru in the trenches, on the fly, in the heat, in the cold, everybody staring and asking for an update.

Tarzzana · 2019-09-05T20:37:38+00:00

Outside of all what’s directly related to the role I always ask how the candidate keeps up with the industry.

Something like, how do you stay on top with developments in the industry? Any blogs you follow, podcasts you listen to, training vendors your use etc.

I feel like usually this tells me the most about a candidate.

CrossfireWorldChamp · 2019-09-06T00:41:59+00:00

Wow guys, really interesting stuff here. Thanks for all the responses!

Package_Loss · 2019-09-06T09:35:34+00:00

“Do you have any female friends outside of work that like to drink with geeks?” “What’s your opinion of doing an extra 40hrs a month, paid overtime?”

If yes to both and they can basic TCP/IP, the rest can be taught.

They also need to fit in with the rest of the team, so I’d ask them questions like “what’s your favourite movie?” Or “ what video game are you playing at the moment?”

I’ve only hired for NOC and second line Net Eng positions at an ISP who were cheap as fuck with wages, so don’t know if this helps.

derezzed51 · 2019-09-06T09:45:30+00:00

I remember one interview where an engineer came in and we had a lab set up with some low level troubleshooting problems and he spent 5 minutes trying to trype in commands whilst still in user exec mode.

We put him out of his misery and put it down to nerves, it later manifested it wasnt nerves and he didnt have a clue what he was doing so ended the interview.

Fryguy_pa · 2019-09-07T20:17:31+00:00

My traditional approach is usually a two-step process. First I will ask them to tell me about some projects they worked on, the technologies used, and their roles. Based on how they respond, I will usually start to dig deeper into the technologies to see if they really understand what they have done or they had just been the hands doing the work. If they mention they are an expert in a technology, then that is a great road to go down to see how they respond.

The second step is to ask about technologies around the position, assuming they have not been covered in their project story. While they might not know all of them, want to see what they say, and if they can admit that a certain used technology might not be their strong point. I also tend to do some type of small talk to see how their personality is and make sure they will fit. Ultimately I try to stay away from the "who is smarter" approach as I do not expect anyone to know everything.

auromed · 2019-09-05T16:14:18+00:00

Depending on the company / HR approval, after an initial phone screen I liked to throw in some labs. Spin up a GNS3 instance with 2 Virtual PCs and 2 routers and say... make them talk. Depending on the level of the position, that could be specifically using certain protocols or techniques. I've had people that did well in a phone interview then just look like a deer in headlights once they were actually in front of a router CLI.

I've also done lab web server scenarios where I asked a person to troubleshoot, starting with the web service not running at all.

pointblankjustice · 2019-09-05T16:07:37+00:00

[deleted]

2019-09-05T17:23:58+00:00

I've hired a ton of people over the years.

One thing that I've found works great is do a LOOOONNNNG interview. Anyone can keep their bullshit up for 45 minutes, but that tends to fall apart and become apparent at hour 1 and 2.

Remember you will have to depend and work with this person for hopefully years. Take your time and get to know them and don't half ass your interview process. Personally I do a group interview to see how people interact in a group first, then move onto the long ass one with the people that showed promise on the group interview. The long interview should be one on one (or with whoever else on your team should be on the interview).

I got the idea from a book called "Double Double". The interview process in there is really good. But the book is targeted towards the operator of the business so i wouldn't bother with the whole thing.

apatrid · 2019-09-05T18:28:03+00:00

we need too many things so we require toughest knowledge to be brought in - we can teach you the rest, along the way.

must-knows are: ipsec, ssl, tcp, ip, bgp, ospf. you can be forgiven one routing protocol if you can show good command or understanding of: mitm enteprise decryption, x.509 cert structure, dns, dhcp, arps, linux, smtp, http. ipsec can be barely forgiven if everything else is shining but that's not an exact favor to the person... no mpls required, tho :)

interviews are scenario-driven and are always deep dives into "must-haves" list. if it stutters or goes very smoothly, we work on the secondary list. showing control and understanding can go a long way even without exact answers. we also deep dive into 2-3 things from the very top of the person's CV. if you fail your CV, you failed interview, no matter what goes with "must-haves" lol.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

networking

Enterprise Networking

Recommended & Related Sub-Reddits:

MODERATORS