<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><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></body></html>