It’s campus recruiting season again, which means that career fairs will soon be flooded with hopeful companies looking to find the next generation of amazing students to build their paradigm-shattering, game-changing, world-beating visions of glory. Or CRUD database apps. Whichever.

This is also the time when people like me write blog posts about how to prepare for interviews, or better yet, how to interview candidates (and why our methods are clearly superior to everyone else’s). You may notice, however, that there’s a bit of a disconnect between the advice that’s being handed out. And in fact, that there are two main schools of thought out there, each pouring scorn on the other across the yawning divide. Since this is my blog (which means I get to decide), I will call these two camps the “mechanists” and “humanists.”

Mechanists believe that knowledge of CS fundamentals matters. That a ready understanding of basic data structures and algorithms is critical when making design and coding decisions. That being able to code during an interview (on a whiteboard, a piece of paper, at a keyboard, on cuneiform tablets, whatever) is the most effective way to determine if a candidate can code. And that having graduated from a top university, or having worked for a great company with a strong engineering culture, is a positive indicator of future job success.

Humanists, on the other hand, take a more portfolio approach. They want to see if you can solve problems, and want to see past projects as proof. They don’t think that the ability to regurgitate an algorithm you’ll never need to code in real life (because common libraries, Google, StackOverflow) is a meaningful test of anything, and want to see if you can solve a novel problem with all the tools at your disposal. They look for people with a learning mindset, and who feel comfortable having technical conversations.

Anyone who’s read my blog knows that I’m firmly, unapologetically, trenchantly in the mechanist camp. But the point of this post is not to have a point-by-point rant explaining why they are clearly wrong, and why I am clearly right. To close your mind to all opposing arguments is to invite stupidity¹, and when an opposing view is articulated well, it’s worth taking another look. So when Laurie Voss posted a well-thought out post describing his take on the humanist approach, I decided to sit down and think through the problem a bit more. I kept asking myself, why does this divide persist? Do I have it wrong? We’ve all spent a lot of time recruiting – what are they seeing that I don’t?

At the same time, there have been a number of posts about the different roles played by different types of engineers in either the project, or corporate life cycle. They divide into two, three, or more categories, but they basically boil down to the same archetypes, all falling somewhere on the hacker/software engineer continuum. The idea is that there are some coders who are always pushing boundaries, always throwing together prototypes, tools, and looking for alternate ways of doing things. They use whatever technology makes the most sense (or whatever they happen to be playing with at the time), regardless of the technology stack used by the rest of the company. They can throw together a proof of concept in an astonishingly short period of time, but are less interested in creating a robust, performant, maintainable, shippable product². They’re always chasing after the next exciting idea, fun technology, or thought experiment they had while showering.

On the other hand you have reliable, stolid software engineers. They have interesting ideas as well, but put them aside in order to focus on getting their projects out the door. They write unit tests, worry about big-O time, and put significant time into thinking through a design in order to maximize long-term maintainability. They put in the hard, boring, frustrating hours at the end of the project, when all the cool bits have already been written, to get the last 10% done and project shipped.

And it occurred to me… The humanists are looking for rockstars. The mechanists are looking for rock solid stars. The humanists want to find the unceasing energy of true hackers. The mechanists are looking for coders who can build to last. The humanists want creativity. The mechanists want responsibility.

Of course, we all want everything. Mechanists want über-hackers, and humanists want dependable finishers. But some people tend to date the edgy, dangerous ones, while others go for the stable, reliable ones.

There’s a basic rule of interviewing that goes something like this. “Hey you! Yeah, you! You wouldn’t be on the interview panel if you weren’t doing well at your job, so don’t ask a question you couldn’t have answered when you were applying.³” And ultimately, I think that this is what’s going on – we’re all looking for some set of questions that we would have been able to pass. If you’re a classically trained software engineer, then you ask about data structures and algorithms, and get candidates to code on a whiteboard. If you’re a self-taught hacker, then you see what they’ve built and try to geek out with them.

Let me be clear – I am most emphatically not saying that all interview methods are equally valid, and that you should do whatever the hell you want because it’s all the same in the end. There’s been quite a bit of research into how people interview, and what is and isn’t an indicator of future job success⁴. What I am saying is that the interview process tells candidates a lot about the kind of person you’re looking for – and by extension, how you see yourself – whether you know it or not.

³ Embarrassingly, this is why I don’t ask questions that require knowledge of breadth-first-search

⁴ Pro-tip: identify candidates with past job success, test competencies that will be used in the job setting, and do everything you can to remove the influence of cognitive biases.

Follow me on Twitter