On 7/14/20 10:33 AM, Owen DeLong wrote:
On Jul 14, 2020, at 10:20 , Michael Thomas <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