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 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.
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.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 intervieweewhat 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.
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.
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.
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 of 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 knowledgably about anything they have on their resumes.We interview 10 people for every 1 we hire because the others can’t talk knowledgably about what is 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.Conversation about code are more efficient than code tests at getting at a programmer’s ability.
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.Current research suggest that, 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. (Blink: The Power of Thinking without Thinking). 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 decisionCoding tests at interviews are a way to justify a decision that has already been made..
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.
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.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.
Other Places Talking About Coding Interviews
- Elements of Programming Interviews
- Nothing Is More Indicative of a Bullshit Job Than The Interview
- How To Win A Senior Level Programming Interview
Other post in Interview
- Why Programmers Can’t Program - March 11th, 2010
- Cracking the Programmer's Interview Code - May 7th, 2015
- 7 C# Interview Questions [That Weed Out The Losers!] - August 13th, 2015
- 3 Reasons Responding To Useless Interview Questions Makes You Happier - September 10th, 2015
- Your Programming Resume is Garbage - June 30th, 2016
- Revisiting The Technical Interview - October 11th, 2016