Home » Interview » Cracking the Programmer’s Interview Code

Cracking the Programmer’s Interview Code

33TrSeveral 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.

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.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.

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 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.

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.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


Other post in Interview

Related Post

  • ASP.NET Interview Questions For New College GraduatesASP.NET Interview Questions For New College Graduates I’m not the first to write on this topic and probably won’t be the last.  But I do have something to say on the matter that I think is helpful. In fact, there has been quite a bit […]
  • Revisiting The Technical InterviewRevisiting The Technical Interview I’ve written about the technical interview before.  I’ve written both for and against code interviews.  And I’ve provided both C# and JavaScript questions to weed out fake programmers. But […]
  • 3 Reasons Responding To Useless Interview Questions Makes You Happier3 Reasons Responding To Useless Interview Questions Makes You Happier I’ve noticed a trend recently.  Someone will write a post about some technical interview question and someone will write a comment about how that’s such a dumb question that they wouldn’t […]
  • Your Programming Resume is GarbageYour Programming Resume is Garbage Over the last several years, I’ve had a chance to read a few Programming Resumes.  Or, I should say, TRY to read a few resumes.  But frankly, if the Programming Resume I typically see is […]
  • 7 JavaScript Interview Questions [To Weed Out Imposters]7 JavaScript Interview Questions [To Weed Out Imposters] Last week, I posted 7 interview questions for C# programmers.  I guess I forgot that people can’t see in my brain.  So, let me be very explicit this time.  The “weed out the losers” […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS. Does your team need additional help in any of the above? Contact Dave today.

One Pingback/Trackback

    09 July 2015 at 4:07pm
    […] Cracking The Programmer's Interview Code – Dave M Bush ...
  • Automate the Planet
  • In my team, we have the practice to give the new candidates a project before the interview. On the interview day, the candidate should defend his ideas and implementation. I have seen a couple of times candidates to write pseudo code that we usually use to observe how they can handle the problem.

    Also, I have included your article in my weekly best-articles-about-programming-roundup Compelling Sunday- http://automatetheplanet.com/compelling-sunday-15/

    • Oh yes, we use that one as well (not all the time).

      The best part for me is not the implementation, but how people react to the assignment and their communication. Give them a project they can complete in an hour one week in advance. It is good if the project has a simple bonus assignment. When you finally receive the solution at 3 AM, 7 hours before the actual interview with no bonus completed… Great fit, tell HR to prepare an offer!

  • Pingback: Automate the Planet()