This week and next week, I want to talk about hiring. Originally this started life as a single post, but it kept growing and growing so I figured it was best to split it up. 😉 This week, I’m going to talk about typical hiring practices and the issues I have with them. Next week, I’ll talk about the specific practices that I use instead, and why.
My goal with these posts is for people to make sure that they’ve put some thought into their process for interviewing and hiring candidates. What goals are you trying to achieve? What sort of candidates are you looking for? And possibly most importantly, what message are you sending the candidate about what sort of company you are? Seriously, this is a big deal and very few companies seem concerned about how their culture is perceived. I’ve known several companies that actually had fairly good cultures but their hiring process was sending such bad messages to candidates that people were turning them down (of course, I’ve known plenty of companies that had pretty shitty cultures too, but then their hiring process did a good job of reflecting that 😉 ). It is always possible that you use some of the following processes and they work well for you; if you are certain of this, then great. Otherwise, continue down the rabbit hole with me.
In my experience, most companies use some variation of the following practices. It starts with a phone screen centered around programming trivia questions. If that goes well, there’s a series of 1 hour face-to-face interviews which usually contain one or more sessions of writing code on a white board or solving silly logic problems, all while the interviewer sits there and stares awkwardly. Occasionally some companies will instead have you write actual code using Code Pad while they watch. Bonus points for doing that instead of white boarding code, but it’s still not ideal.
So, what are the issues I have with these typical hiring practices?
- Trivia questions during a phone screen probably aren’t as effective as you think. I used to be a big fan of coding trivia questions. Why would you have a virtual destructor? If you cross two normalized vectors is the result guaranteed to be normalized? You get the idea. Here’s the thing: after phone screening literally hundreds of candidates, I found that my success rate in actually hiring competent people was quite low. Turns out knowing coding trivia does not guarantee the individual’s ability to actually write good code. Point in fact, I frequently found that those individuals who could regurgitate the C++ coding standard usually didn’t meet my goal of having programmers with sufficient practical knowledge that I could be very hands-off with them. Unless you’re hiring candidates for Jeopardy, come up with a way of screening that really tells you if the individual’s talents and skills map to the goals you have for that position.
- Any problem that can be solved in 45 minutes or less isn’t going to give you a good idea as to someone’s ability to write solid code. I used to be very good at taking tests in college. This is because I understood that you only had a very limited amount of time, maybe 1-2 hours. Therefore the professor was very limited in what sort of problems they could ask and would focus on just the problems that were solvable in that time frame or less. In reality, they usually had to be problems that were solvable in 30 minutes or less so they could have several questions on the test. Cake! To get around this limitation, companies frequently add silly constraints to the problem to make it harder. In my experience, these constraints usually revolve around using a different coding technique then is typically used to solve this particular problem. Unless the candidate happens to know that specific technique already, they either have to make an intuitive leap or guess, instead of being able to logically deduce a good approach given the time limitations. Do you really want your engineers guessing at solutions? Maybe you do. I certainly don’t think it’s a recipe for success, but if that’s what you want….. 😉
- White board coding. Programmers write code at a computer with their favorite editor, a compiler and a debugger. Writing code on a white board is nothing like writing actual code and doesn’t really show you how this particular candidate actually writes code to solve problems. Unless your company actually writes all of your code on a white board (I’m guessing not 😉 ) and transcribes it into the computer, why oh why do we still interview people like this?
- Silly logic problems. I understand the reasoning behind asking them, but do they truly measure someone’s ability to solve real-world problems, especially when the candidate can’t do any research to look for a solution? Is that how your normal development process works? I still remember one of my first interviews, it went something like this: How would you weigh a manhole cover? I’d put it on a scale. Ah ha! There are no scales. There are no scales? I think we have bigger issues than how much a manhole cover weighs. Seriously. Translate that into any regular conversation at your company. How are you going to implement this feature? Well first I’d look up if there are any discussions or examples online. Oh no! You can’t look anything up! You must implement it from first principles in the next 45 minutes. Well I’d probably start with using the standard libraries. Oh and you can’t use any standard libraries. If this is really your culture, great, I guess you’ve perfected your hiring process. Stop reading now.
- Frequently, interviews end up feeling antagonistic. In my experience, this is because the interviewer is trying to “win” the interview by proving the candidate doesn’t know what they’re doing. Just stop this. Seriously. Crushing a candidate during an interview is trivially easy if you want to set things up with that as your goal. I’ve also seen plenty of interviews where the interviewer sat quietly and stared while the candidate squirmed. Is this what your culture is really like? Your real goal should be hiring a great candidate who actually wants to work with you.
- Interviews are rarely collaborative. See above with giving candidates problems that rely on them knowing bits of trivia instead of core techniques. Because these types of problems involve knowing or intuiting (which people are rarely good at while under stress in an interview) some bit of ah-ha! knowledge, it is next to impossible to collaborate with the person without simply giving them the answer. You can’t give them hints and see how they consider and apply them, or see if they ask good questions, or get any other insights into their thought process.
- The atmosphere of many interviews can be very condescending towards or dismissive of the candidate, in a “prove why we should let a peon like you work for our awesome company” kind of way. I recently did a technical screening where I was on video call. Their video feed was disabled, so they got to watch me while I got to see a blank screen. It’s what I imagine being interviewed through a one way mirror is like. I can’t say I recommend it. 😉 My takeaway was that the company had a very us vs. them culture. Until you’re one of “us”, we don’t want to interact with you. Is that how you want to present your culture? Especially if that isn’t what your culture really is.
Hopefully I’ve made a compelling case that most hiring practices either aren’t as effective as you think they are, or worse, you’re driving away great candidates because of how you’re presenting your company. Next week, I’ll talk in detail about what processes I use instead, and why. Until next time.
Know of other standard practices that just aren’t cutting it? Agree or disagree with anything I’ve said? Questions? Let me know in the comments below or via Twitter, Facebook or email contact at captainbyrank dot com.