questions asked during network engineer interview

Tue Jul 14 22:35:24 UTC 2020

I was once asked at a FANG interview how I would affect incoming traffic using BGP. I listed the usual offenders like AS path and med. He kept asking how else, to which after pondering I said that I cant think of other ways right now. He was insisting I find one, so I theorized on using more specific prefix even though that’s technically not a BGP method. I think that was when he decided I failed, and I decided that he wanted me to name a creative method he himself used at his megascaler. Considering I never had to even think about solving problems at their scale I think that was just dumb to insist I come up with it. 
I’ll never know what that magical method is since he didn’t actually give me the answer I didn’t know ¯\_(ツ)_/¯ 
In my mind I’d rather a person admit to not knowing than spit bull at you with confidence. Admitting not knowing means you’ll know to look it up or ask someone. Bullsh*tting means you’ll probably implement some insane thing and not consult anyone about it.

The interview in general seemed to be more about technical nerd knobs of random technologies and less about how I think about problems. 

My take is that nerd knobs can be taught and/or looked up. How a person thinks and dissects the problems at hand can hardly be changed easily.

The question about “what happens when you enter google.com into your browser” is probably my favorite and I ask it to candidates every time. That and “how can you confirm a remote system is listening on a given TCP port”. Idk what it is that confuses people, but close to zero people answered “telnet or netcat to that port” and most of them went down the “I ssh into the system” or “I look in the firewall” or “I netstat”.

Another one is “what is the summary prefix for 10.0.0.0/24 and 10.0.1.0/24”. So.many.minds.blown! Some ask for pen and paper. Others just start doing binary conversions out loud....

Turns out there are as many bad candidates as there are interviewers. I consider myself a bad interviewer so I try to shy away from interviewing candidates if I can. And based on this email chains so far it seems like there is not an agreed upon good interview method.

-----------
Sent from mobile

> On Jul 14, 2020, at 10:34, Owen DeLong <owen at delong.com> wrote:
> 
> 
> 
>>> On Jul 14, 2020, at 10:20 , Michael Thomas <mike at mtcc.com> wrote:
>>> 
>>> 
>>> 
>>> On 7/13/20 8:16 PM, Greg Skinner via NANOG wrote:
>>>> If you ever decide to revisit this subject, I recall it was covered here in this thread started by Bill Herrin.
>>>> 
>>>> My general feelings on the subject of tech interviews are summarized in the “interview anti-loop” section of this article by Steve Yegge.   Although it is targeted to people seeking software engineering jobs at FANG (and FANG-like) companies, IMO the general tone is applicable to other tech careers, even network engineering.  I have seen numerous articles (and subsequent discussions) on this subject on forums such as Quora, Medium, and Hacker News.
>>> 
>>> That blog post is everything that is wrong with software interviews. It's fine to ask intricate algorithm questions for somebody fresh out of school because what else are you going to ask them? But for somebody who's years out of school and has lots of experience, the intricate details of various algorithms fade especially ones that you don't use very often, or are embedded in library routines you'd be fired for if you tried to reinvent them. Telling people they have to go back to school for stuff they won't be using on the job is offensive.
>>> 
>> 
>> 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.
>> 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?
> 
> The former moves on to the next steps towards employment. The latter is dropped from consideration.
>> My personal theory is software interviewing is basically a hazing ritual where the interviewers are trying to fluff their own privates, and it's almost to a one male. I wrote this post a while ago:
>> 
>> http://rip-van-webble.blogspot.com/2013/07/interviews-as-hazing-rituals.html
>> 
>> Mike
>> 
> 
> 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.
> 
> Owen
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200714/35fca7c9/attachment.html>