Follow-up to “The dystopian world of software engineering interviews”
I think one of the major takeaways here is, <i>stop asking algorithm questions</i> [1]. Everyone. Just stop it.<p>In my opinion, and modest experience (I&#x27;ve done several dozen interviews, so there are plenty more experienced then me, but I&#x27;m at least not new, plus nearly all interviews were for my team so I had to live with the results!) it isn&#x27;t <i>that</i> hard to come up with small sample questions related to what the job actually is doing. From there, in addition to the mere fact of whether or not they were able to complete the task, you can learn about how they did it, look at their practices, stop them for a moment and discuss the implications of something they just did. You can add a wrinkle to the task (&quot;what about unicode?&quot; &quot;what about cross-site scripting vulnerabilities?&quot;). I also find being this kind of flexible, rather than being stuck on &quot;did they solve this algorithm challenge in the <i>proper</i> manner&quot; also gives me room to be human, to take a moment to try to calm the candidate down in what is inevitably a stressful situation for them (even if it&#x27;s basically just Tuesday afternoon for me in my current position in the world). I think of an interview as &quot;I want to find all the positive I can&quot;, rather than as a process of locating all flaws, and you can&#x27;t do that if your candidate is frozen in the headlights the whole time.<p>Interviewees are pouring forth a wealth of information. The idea that the only way to find out how good they are is by asking this one narrow set of questions is absurd.<p>And the interview<i>ers</i> are pouring forth a wealth of information too. Consider what message you&#x27;re sending with a rigid adherence to something we <i>all</i> know is broken.<p>[1]: Unless it <i>really is</i> relevant to the job! I expect that if I&#x27;m hiring a senior level machine learning <i>researcher</i> that you better be able to describe gradient descent to me, for instance. We may not implement it literally in the interview but I have a reasonably case for saying the researcher ought to convince me they could get there. But in a lot of cases, what&#x27;s more relevant to me is that you know the <i>characteristics</i> of algorithms rather than exactly what they are. You can know the runtime and weaknesses of quicksort or RAFT consensus even if you can&#x27;t spew the actual algorithms on to a board.<p>Actually, my parenthetical here almost makes me want to rewrite this whole post, although this thought is still fresh and I&#x27;m still chewing on it. Is that perhaps the error we are making? Are we conflating <i>knowing</i> the algorithms for knowing the <i>characteristics</i> of the algorithms? The latter is legitimately important and I see screwups based on failing to understand <i>characteristics</i> of algorithms all the time. Knowing the literal, actual algorithm to the point that you could simply open up a terminal and bash it out yourself is rarely important in this era.