Follow-up to “The dystopian world of software engineering interviews”

[1] described at https://news.ycombinator.com/item?id=11662380 if you don't recognize the term

I've outlined it here before. Been using it and tweaking it for the last 3 or 4 years. I keep bring it up because it's a tested alternative to the usual death marches and dumpster fires and it has been a success for the teams I've led and our applicants.

The principles I've defined to guide our process[0]:

- Hiring cycles will be structured and as short as possible.

- When we start a hiring cycle, we will finish it by hiring the most qualified applicant who accepts our offer.

- Every applicant will receive a response within 48 hours and be updated on the status of their application at each step asap.

- The hiring process will be as transparent as possible.

- Objective and fair-minded measures will displace biased and bigoted ones.

- Every applicant will appreciate their experience, even the rejected ones.

- The process will be agile and adapt over time to improve and meet the specific needs of the organization.

- Onboarding will begin with hiring.

One problem I'm confronting at the moment. As our company grows, we've brought on a new HR lead who wants to jam the process we've been refining over the last couple years into a new ATS (Applicant Tracking System) that could significantly screw up our meez. We'll see how that works out. I'm doing everything in my power not to let it fall apart.

If you have the power to improve the situation, please do so.

[0] For an outline of the process, see https://wiki.klenwell.com/view/Hiring

In my opinion, and modest experience (I've done several dozen interviews, so there are plenty more experienced then me, but I'm at least not new, plus nearly all interviews were for my team so I had to live with the results!) it isn't that 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 ("what about unicode?" "what about cross-site scripting vulnerabilities?"). I also find being this kind of flexible, rather than being stuck on "did they solve this algorithm challenge in the proper manner" 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's basically just Tuesday afternoon for me in my current position in the world). I think of an interview as "I want to find all the positive I can", rather than as a process of locating all flaws, and you can't do that if your candidate is frozen in the headlights the whole time.

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.

And the interviewers are pouring forth a wealth of information too. Consider what message you're sending with a rigid adherence to something we all know is broken.

[1]: Unless it really is relevant to the job! I expect that if I'm hiring a senior level machine learning researcher 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's more relevant to me is that you know the characteristics of algorithms rather than exactly what they are. You can know the runtime and weaknesses of quicksort or RAFT consensus even if you can't spew the actual algorithms on to a board.

Actually, my parenthetical here almost makes me want to rewrite this whole post, although this thought is still fresh and I'm still chewing on it. Is that perhaps the error we are making? Are we conflating knowing the algorithms for knowing the characteristics of the algorithms? The latter is legitimately important and I see screwups based on failing to understand characteristics 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.

At the same time, a great deal in this is the level of expectations about the "greats", finding the right job place at once. I believe adjusting these criteria might open up a lot more chances to get to doing the craft, be on the team, well, interview the others too.

Good luck!