Interviewing Software Engineers
Interviewing is something I've given some amount of thought. It's certainly something I have experience with; more of it recently than I wish I did. I'm hardly an expert, but I have read and talked about it because it's important. I think it's commonly accepted that as a collective field, tech is not very good at this. I've served as an interviewer at various times, and I certainly was given no training or preparation for that. In the time I've spent on the outside of that process, it's been clear that the lack of support I experienced as an interviewer is common.
There are a lot of problems with the way tech interviews people. But they mostly boil down to evaluating the wrong things, or evaluating things in the wrong way. White board coding challenges—and honestly any coding challenge—is the ultimate example of both. It's a bizarre, contrived, high-pressure test that strips the candidate of all of the tools, context, and support that they would rely on to do actual work. People's performance in their work is a product of their environment. For software development, some of the critical components of that environment are the tools we use, the knowledge we've gained about the systems we're working on and the problems they address, and the team we work with to build that software. Virtual whiteboard tests are not really any better, in my experience. Online tools are more helpful than a physical whiteboard, but they're not at all the same tools we would use on the job. And the extra tool support seems to just encourage interviewers to pick harder, more elaborate assignments. Take home projects might be worse, because while they do potentially allow people to use their actual tools of choice, it also severs the tenuous connection they had to a member of the team. They also take much longer, and developer interviews are already frequently long enough that it's exploitative and exclusionary.
So, if white board problems are out, and online programming challenges are out, and take home projects are out, what's left? Not much. And that's fine. If you're asking what test should you use, that's the wrong question. None of these tests are useful. Just don't do them. I think the reason they're done in the first place is because they're easy. Easy to administer, and easy to evaluate. But the information they provide is useless, at best. In fact it's often misleading, and creates lots of opportunity for bias to sway an interviewer's perception. We know that the work done by the candidate in these tests will not be representative of they work they do on the job. There is no relationship between the two. So then what is being evaluated? Mostly communication style. Also confidence and affluence play a large role. But mainly it's a question of whether the candidate thinks aloud in a way the interviewer finds familiar. Whether they happen to follow a logical path the interviewer agrees with. Whether they prioritize a working solution vs an exploration of the problem vs whatever else in the way the interviewer prefers. Or any number of other things which are not an expression of competence at writing software, which is the ostensible point of this challenge. And because these are mostly about communication styles, values, and priorities, they will favor people from a similar background as the interviewer. Given that tech is ~90% men and ~70% white, that means this situation favors white men. It just does. It's 2021, and so much of tech has been saying for so long that we want to increase the diversity in our companies. I'm taking those claims at their word. Interviews and recruiting are neither the cause nor the solution to the uniformity of people in our field, but the way we do it definitely isn't helping, either.
