<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">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. <div>I’ll never know what that magical method is since he didn’t actually give me the answer I didn’t know ¯\_(ツ)_/¯ </div><div>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.</div><div><br></div><div>The interview in general seemed to be more about technical nerd knobs of random technologies and less about how I think about problems. <br><br>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.</div><div><br></div><div>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”.</div><div><br></div><div>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....</div><div><br></div><div>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.</div><div><br></div><div><div dir="ltr"><div>-----------</div><div>Sent from mobile</div></div><div dir="ltr"><br><blockquote type="cite">On Jul 14, 2020, at 10:34, Owen DeLong <owen@delong.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 14, 2020, at 10:20 , Michael Thomas <<a href="mailto:mike@mtcc.com" class="">mike@mtcc.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class=""><p class=""><br class="">
</p>
<div class="moz-cite-prefix">On 7/13/20 8:16 PM, Greg Skinner via
NANOG wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:92BDA127-AB54-4012-A196-7BD2BFAFFCFC@icloud.com" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
If you ever decide to revisit this subject, I recall it was
covered here in <a href="https://mailman.nanog.org/pipermail/nanog/2012-July/149687.html" class="" moz-do-not-send="true">this thread started by Bill
Herrin</a>.
<div class=""><br class="">
</div>
<div class="">My general feelings on the subject of tech
interviews are summarized in the “interview anti-loop” section
of <a href="http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html" class="" moz-do-not-send="true">this article by Steve Yegge</a>.
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.</div>
</blockquote><p class=""><br class="">
</p><p class="">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.<br class=""></p></div></div></blockquote><div><br class=""></div>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.</div><div><blockquote type="cite" class=""><div class=""><div class=""><p class="">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.</p></div></div></blockquote>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?</div><div><br class=""></div><div>The former moves on to the next steps towards employment. The latter is dropped from consideration.</div><div><blockquote type="cite" class=""><div class=""><div class=""><p class="">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:</p><p class=""><span class=""><span id="c18" role="region" class="w4txWc oJeWuf"><span class="MUhG4e OGjyyf" data-blogurl="http://rip-van-webble.blogspot.com/"><a class="moz-txt-link-freetext" href="http://rip-van-webble.blogspot.com/2013/07/interviews-as-hazing-rituals.html">http://rip-van-webble.blogspot.com/2013/07/interviews-as-hazing-rituals.html</a></span></span></span></p><p class=""><span class=""><span id="c18" role="region" class="w4txWc oJeWuf"><span class="MUhG4e OGjyyf" data-blogurl="http://rip-van-webble.blogspot.com/">Mike<br class=""></span></span></span></p></div></div></blockquote><div><br class=""></div>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.</div><div><br class=""></div><div>Owen</div><div><br class=""></div></div></blockquote></div></body></html>