I completely agree. One of the people I used to do interviews with would look through the resume, etc. and then say something like "this all looks good. Tell me about something you've done". And we'd move on to talk about projects and how they tackled it, etc. We didn't give tests, just questions like "if we asked you to do this, on something you haven't seen or used before, how would you go about it". Or pretend I'm the customer. I want to do this. How would you go about it? it wasn't about getting a 'correct' answer, it was about how they went about solving the problem.
-----Original Message----- From: "Owen DeLong" <o...@delong.com> Sent: Tuesday, July 14, 2020 1:33pm To: "Michael Thomas" <m...@mtcc.com> Cc: nanog@nanog.org Subject: Re: questions asked during network engineer interview On Jul 14, 2020, at 10:20 , Michael Thomas <[ m...@mtcc.com ]( mailto:m...@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 ]( https://mailman.nanog.org/pipermail/nanog/2012-July/149687.html ). My general feelings on the subject of tech interviews are summarized in the “interview anti-loop” section of [ this article by Steve Yegge ]( http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html ). 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 ]( http://rip-van-webble.blogspot.com/2013/07/interviews-as-hazing-rituals.html ) MikeNot 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
