Job interviews are stressful and difficult. You basically interview for a position you want by answering a bunch of questions that have nothing to do with your true skills, while dressed like someone going to a funeral. How can anyone find the best candidate for a technical position based on how well you react when asked a bunch of strange questions by people you have never met?
In this article by Thomas H. Ptacek (Co-founder at Starfighter), he outlines what he thinks is a better way.
Engineering teams are not infantry squads; members aren’t selected for their ability to perform under unnatural stress. But that’s what most interview processes demand, and often—as is the case with every interview that assesses “confidence”—explicitly so.
Confidence bias selects for candidates who are good at interviewing. There are developers who have the social skills to actively listen to someone else’s technical points, to guide a discussion with questions of their own, or to spot opportunities to redirect a tough question back to familiar territory. Those people build impressive resumes. They effortlessly pass “culture fit” tests. But a lot of them can’t code.
Confidence bias also excludes candidates who don’t interview well. For every genuinely competent and effective developer who can ace a tough interview, many other genuinely competent developers can’t. Our interviews select for the ability to control a conversation. They miss the ability to fix broken network software.
Let’s contain the damage. There are things you can do to make your hiring processes better. I’ve deployed the below tactics, seen them work, and know they should be industry standard. They aren’t yet. Adopt them and profit.
If you have anything to do with the hiring process, can you please implement some of his ideas to make the process just a little better?