Re: questions asked during network engineer interview

[Michael Thomas <mike () mtcc com>]

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