questions asked during network engineer interview

Tue Jul 14 20:03:48 UTC 2020

This is exactly why the espresso network looks like it does… 

Have you seen the advert for network architect position at google? Bunch of programming languages and that’s enough apparently.

adam

From: NANOG <nanog-bounces+adamv0025=netconsultings.com at nanog.org> On Behalf Of Ahmed elBorno
Sent: Tuesday, July 14, 2020 6:57 PM
To: Michael Thomas <mike at mtcc.com>
Cc: NANOG list <nanog at nanog.org>
Subject: Re: questions asked during network engineer interview

15 years ago, I applied to a network admin role at Google, it was for their corporate office, not even the production network.

I had less than two years experience.

The interviewer asked me:

1) What is the difference between flow balancing techniques on Cisco IOS and Linux?

2) If we had a 1GB file that we need to transfer between America and Europe, how much time do we need, knowing that we start with a TCP size of X?

I'll never forget this :)

On Tue, Jul 14, 2020 at 10:50 AM Michael Thomas <mike at mtcc.com <mailto:mike at mtcc.com> > wrote:

On 7/14/20 10:33 AM, Owen DeLong wrote:

On Jul 14, 2020, at 10:20 , Michael Thomas <mike at mtcc.com <mailto:mike at mtcc.com> > wrote:

I once failed a network engineering interview because I couldn’t recite the OSPF LSA types by number from memory. It was fine, the fact that was a key question in the interview convinced me that I had no more desire to work there than they had to hire me.

I once got rejected because I spaced out and didn't remember the java keyword "final" as a constant. you can't make this stuff up.

My personal method is to devise a problem and actually work with them... because that's what I (or others) are going to be doing. How well can they get the requirements? How do they zero in on how to solve it? You can take this as deep or shallow as you like. Often I'd give it as a homework assignment if I liked them.

I prefer this approach as well. Depending on the level of interviewee, I like to pull up a real world scenario from my past and see how they approach it. I’m not nearly as concerned if they get to the right solution as I want to see how they go about identifying and solving the problem. Do they ask questions that narrow their focus and identify the issue, or do they start trying random things hoping to stumble across a solution without understanding the problem?

I often use something that was somewhat topical to me but dumbed down enough to fit in an interview and possible homework assignment. My reasoning is that I'm not entirely sure what the solution ought to look like either, so I'm interested to see what their take is. I can also give them real time feedback just like I would if they were a co-worker. At base, an interview should answer the question: "can I work with this person?". 

Not being a developer (at least not for the last 25+ years), I haven’t done many “software” interviews, but I’ve been through network and sysadmin interviews that ran the gamut. Frankly, the ones that seemed to be more about fluffing privates were the companies I put less focus on going forward. The interviewers that seemed to match my style and wanted to see me do real-world things like troubleshooting or solving design problems or identifying architectural flaws in a proposed solution usually resulted in mutual respect and I usually moved forward through the interview processes. On the few occasions where I got a job out of a fluffing interview, it almost universally turned out to be one I wished I hadn’t taken.

I had a screening interview at Google where the screener asked some ridiculous question that nobody not straight out of school would know, and even then not likely. I was like, wtf? If that's how they treat candidates -- and from everything I've heard it is -- I want nothing to do with them, and flat out refused their recruiters a dozen time afterward even though they pleaded that they've changed. Sorry, interviewing is a two-way street.

Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200714/51424694/attachment.html>