RE: questions asked during network engineer interview

[<adamv0025 () netconsultings com>]

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 () nanog org> On Behalf Of Ahmed elBorno
Sent: Tuesday, July 14, 2020 6:57 PM
To: Michael Thomas <mike () mtcc com>
Cc: NANOG list <nanog () 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 () mtcc com <mailto:mike () mtcc com> > wrote:

 

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

On Jul 14, 2020, at 10:20 , Michael Thomas <mike () mtcc com <mailto:mike () 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