TechCrunch had 2 articles last month on “Secretly terrible engineers.” Reading the articles makes it sound like there’s a serious problem with how we interview software engineers. Personally, I just don’t see it. Software engineers are like every other profession, the people in it range from terrible to amazing, and the which engineer is which is hardly a secret. Likewise, having just gone through the interview process within the past year, I haven’t really encountered the issues Danny Crichton described. Granted, I wouldn’t interview anywhere near Silicon Valley, so my geography could be affecting what I observed, or I could just be absurdly lucky, but somehow I doubt it.
I’ve heard a few pretty hilarious stories of an intern that worked at an employer of mine before I started with the company. According to legend, he was pretty horrible. Utterly terrible even. Didn’t understand programming to interfaces bad. No understanding of variable scope bad. Couldn’t grasp a simple class with only getters and setters bad. Just legendarily bad. It was the kind of bad that could have been found and avoided with some simple efforts to gauge this guy’s skills.
On the one hand, a lot of what this guy’s describing is less of a fear about hiring a “secretly terrible engineer” and more of a fear about not hiring a “rock star”, “ninja”, “10x developer”, or whatever term people are using to describe someone who’s really good at their job these days. Whatever your thoughts on the existence of such uber developers (and there are some notable doubters), the simple fact is that these developers are, by the sheer fact of their definition relative to other developers, rare. The odds of anybody hiring them is incredibly slim, and even if you are trying to recruit them, you’re competing against Googles, Netflixes, and pretty much every other incredibly well-known tech company that draw in developer applicants through name recognition and a good reputation.
Not everyone can be some type of uber developer, and that’s perfectly fine. The good news for people hiring developers is that terrible engineers that people are allegedly so desperate to avoid about as rare as the uber developers that they’re trying to hire. The reality is most people (myself included) aren’t in either camp but can still make positive contributions. All you really need to do is a simple test to filter out the terribad applicants and you’ll be fine. Contrary to Danny Crichton’s thesis, this typically isn’t being done via a bunch of nit-picking trivia questions but by asking potential developers to code, just like they’d have to when they start working anyways.
Crichton seems aware of that fact – he even points out the example “(m)anagement consultants often have to work out a case study, even though they spend most of their time early on in Excel or PowerPoint.” Crichton claims most software engineering interviews attempt to do this via programming trivia, but the reality is most places that are serious about hiring developers are far more interested in “Why should you program to an abstraction?” or even “Do you program to abstractions?” than “What’s the Big Theta of this code?” I’ve had my share of trivia questions during interviews, but those typically come towards the end that stage of the interview when questioners are just throwing questions out there. More poignant (although I can see where this seems like trivia) are the questions along the lines of “Hey, this is something we’re dealing with, let’s see how the interviewee handles it” (it’s happened to me, and I’m pretty sure I’m not the only one).
Crichton’s follow-up article in the series talked about this trend being targeted at older developers. Personally, I think this is more of a Silicon Valley-specific phenomena, if it’s a real trend at all. Most of the programming interview questions are easier and can be answered better with more practical work experience (which necessitates being older). I’m not trying to claim that places don’t try to avoid hiring older workers (in any job), just that in my experience, the interview process doesn’t seem stacked against older applicants until you get to the salary round.
Look, everybody wants to avoid hiring people who would be bad at their jobs. The interview process, by design, tries to filter these guys out as early as possible in the “I’d like to work for you process.” Even Crichton acknowledges that much in his columns. The reality is, there’s usually not nearly as much need to probe during the interview process as he’s letting on. Terrible engineers, just like any other terrible job candidate, tend to expose themselves pretty quickly. That said, technical jobs will ultimately involve technical questions it’s not unreasonable to expect applicants to be able to give technical answers. Some questions may seem like useless, purely theoretical questions to some people, like “What algorithm would you use to solve this problem?”, but for engineers who live and breathe problems where you have to weigh the costs and benefits to these questions, it’s important stuff and they’re going to give the edge to people who can intelligently discuss these things. That means if performance is of critical importance to what you do, you need to be able to discuss how different approaches to a problem impact performance. If data integrity is important, you need to be able to talk about how different ideas impact the accuracy of the data. If memory is a constraining factor, you better know and be willing to justify memory trade-offs in the code you’re writing.
Crichton’s columns aren’t about avoiding “secretly” terrible engineers, they’re about finding taking a set of potential candidates who are good enough, and trying to determine which of these good options is the “best” for that particular role. Sometimes that means getting into details to tease out minor differences between candidates. It’s not hostility towards potential job candidates, and it’s not an attempt to only employee young, fresh-out-of-college developers (there are easier ways to do that). The horror stories that Crichton is describing are rare, if they’re even notable occurrences outside of Silicon Valley or the relatively small number of development jobs that rely on such technical minutia. Long story short, there’s not a lot of worry about hiring secretly terrible engineers, because they’re not a secret, and typically discovered too early into the interview process to justify the level of effort being talked about in the TechCrunch articles.