Several comments this week contribute to this week’s post.
The first, and the one that pushed me to write this post, is a discussion over at Simple Programmer on a post called “Cracking the Coding Interview” where I made the following statement,
Coding interview? Really? I wouldn’t bother. This is right up there with working 60 hour weeks for me. Yes, I know all the big companies do this, but it doesn’t make it right. “Just because you can, doesn’t mean you should.” I’ve been programming now for 27 years. I started with DOS 3.1 for anyone who’s trying to figure out when that was. I’ve NEVER had to do a coding interview and I make really good money so it isn’t that I’m working for minimum wage. Here’s the deal. I can tell in about 10 minutes if another programmer knows their stuff. I expect that any company worth working for (and yes that includes even Amazon, Google, Microsoft, and the other big boys) should have someone on their staff who can do the same. The best interview I’ve ever had is from the guy I currently work under. The question was, “I know nothing about JavaScript, tell me what I need to know.” And then he just shut up and let me talk. Every once in a while, he’s ask me to drill deeper on the topic. But it is the only interview in 27 years where I felt like the guy interviewing me really wanted to know what I knew. Most of the other tech interviews I’ve been on have been more of the interviewer telling me how much he knew (by asking impossible questions). Now, if I ever did run into an interview where they wanted me to write code on a whiteboard, I’d probably pseudo code it out and explain that I’m a huge fan of Intellisense, particularly ReSharper, and Google and that I rely heavily on those two to get the syntax right. If you want a guy who can write code in notepad, I’m probably not the guy you’re looking for. If you want a guy who can solve problems, who understands how to write testable code, write unit test, can mentor younger programmers, understands what it really means to be agile, and can say “no” to power when it is appropriate, then I’m the guy you want.
OK, I admit, that probably came off a little strong. But the point is, I don’t see any value in coding tests. And when I interview others, what a coding test would reveal isn’t what I want to know about the interviewee and isn’t what I want to be known for.
Response
That was weeks ago. The comment was followed up yesterday by this response
Why wouldn’t you want to have all the qualities of the latter and the ability to write code in notepad? Who says you have to be one or the other? It seems to me that most places would want to hire someone who could do both. In all my interviews, as a candidate, I’ve walked out having learned something new from a coding challenge. It’s a “free” opportunity to learn something new from someone who has different experiences and levels of understanding than I do. It’s also a good opportunity for me to recognize my knowledge gaps where I need to be stronger. Also, I think you missed out on one really critical component of white boarding code challenges. As someone who’s been on the asking questions side, I’m okay with the candidate not knowing the intricacies of array manipulation in JavaScript, but being able to have someone talk through a problem and ask questions and have a dialogue is a really important aspect for me. I really want to know how tenacious a candidate is at figuring out a problem. If they get an answer right away, we’ll move onto something else, but I want to know how willing they are to break through the wall when they don’t immediately know how to solve a problem. I also want to work with someone I enjoy solving problems with, who isn’t going to look down at their peers because they don’t have experience in time or if they have knowledge gaps. Coding challenges are an easy way to hash these things out. I’ve never made a life decision based on a 10 minute conversation and I’d hope no one would ever make a decision that could impact the next 3-5 years of my life based on a 10 minute conversation where a little extra time doing something that’s relevant and challenging could be more indicative of how I will do as a potential future team member.
Recruiter Says
And then there was this offhand comment by a recruiter this week who told me, “You know what reason most hiring managers give for refusing candidates we send them is? ‘They aren’t dynamic enough.’ What does that even mean?” And so rather than write a whole blog post as a blog comment, I respond here.
Why Not Both?
First, let’s get at the first question the responder asked. Why wouldn’t I want to have all the qualities of the later and the ability to write code in notepad? Well, it really isn’t a matter of either/or. I think my method actually gets deeper faster. The place I currently work interviews 10 people for every 1 we hire because most people (9 out of 10) can’t talk knowledgeably about anything they have on their resumes.
Once we’ve established that they aren’t lying on their resume about their experience, we can be pretty sure they’ve actually written code. A white board coding interview might be a way of getting at this information. I just happen to think it is inefficient at best and puts undo stress on a candidate who may otherwise be exactly what you are looking for. In fact, you’ll notice that the comment says that the whole point of the interview is to have an interaction. I assure you this can be done by just having a conversation about code.
Second, unless you state up front that you are only looking for pseudo code and how the candidate thinks, the candidate is going to stress over syntax. Assuming that he gets it right, it doesn’t necessarily mean that he is an efficient coder. It only means he’s memorized a lot of syntax and can use it.
The final statement is where I want to spend most of my time though. Sorry for so much “ink” to get to the main point, but I wanted to setup the context for you.
Decisions Based On 10 Minute Conversation
He states, “I’ve never made a life decision based on a 10 minute conversation …” First, I never said that an interview should only be 10 minutes long. If the Interview only lasted 10 minutes, that would be a bad sign too. Although, I don’t think you’d find out anything more useful by taking more than 10 minutes.
Current research suggest that, no matter which method we use, most of us are hired (or hire) or not within the first 30 seconds.
The rest of the time we come up with supporting reasons. The fact of the matter is, by the time you’ve reached the coding interview, the decision has already been made. This is just a way to justify the decision.
If you were to study the psychology of sales, you would find that all of us buy based on our emotions and come up with logical reasons why after we’ve already made the decision. This is why sales literature is aimed at the emotions. In some way saying, “If you buy this product, you will not have to worry anymore about X”. Sales pages are constructed the way they are based on this. I once created a fake sales page using the formula.
As much as we’d like to think otherwise, we ALL do this. (And watch the comments come in on that statement! Bring ‘em on.) And so we come to the final question, what do we mean by “dynamic” and how did this impact the interview.
What Does “Dynamic” Mean?
Well, I’ll tell you. It’s like this.
This week I went to a meet-up for ASP.NET and JavaScript developers. Every person there I talked to was passionate about programming. It was the easiest group of people I’ve ever mingled with. Why? Because they all wanted to talk about code. They all had opinions. Some I even disagree with. But assuming they could agree to the standards at my organization, I would have hired any one of them. Why? Because they were “dynamic.” One guy in particular I talked to for several hours. I knew in the first 10 minutes that he knew what he was doing. Several hours later, I found some areas we disagreed on. I never had to look at any code. The way he talked about coding told me that he could code. The projects he talked about told me that he could solve problems. And the fact that he could explain those problems he was solving to me showed me that he could communicate.
Cracking The Programmer’s Interview Code
And so, to the point of the title. The way you “Crack the Programmer’s Interview Code” is to be passionate about what you do. Unfortunately, you can’t fake that if you don’t have a clue about programming in the first place. Yes, you can grease the skids a bit. Dress up for the interview. Don’t smell. Don’t be a jerk. Be confident but not arrogant. Beyond that, winning at the interview may simply be a matter of fit. You may have to do some sort of code interview. Or you might decide to skip it because that’s an indication to you that this place won’t be a good fit for you. And that’s OK. There are plenty of places to work. You don’t have to take the first job that pays. You’ll get bonus points if you can walk into the interview already knowing what the pain points are so you can address them. If you know what they fear, what keeps them up at night, and can show how you are the one who can solve that pain point, you are half way to getting the job. None of these are guarantees. You may not get the job and it may have nothing to do with you. One of the things I’m realizing is that the way people react to me has at least as much to do with them as it does with me. If the guy is having a bad day and/or you say or do something that reminds him of something he’s associated with a bad memory, there is no way for you to know that and probably nothing you could do about it if you did.