Introduction

First off let me start with a little bit of background on me.  I have over 12 years experience developing software for a variety of projects.  Some large, some small, some web based some not, I am what you call a jack of all trades when it comes to programming.  I don’t believe that any one language is better than another or that there is a one size fits all approach to any software problem.  I use the best tool for the job.  Often in my career that means that I need to learn a new tool… and fast.  I take pride in this ability and have even coined a catch phrase I have repeatedly said to my supervisors, “A book and a weekend and I will be ready”.

This phrase embodies what it means to me to be a Software Developer.  If I know the basic programming concepts, design patterns, architectures etc, then all that is left is to learn the syntactical differences and the libraries that make a language or framework unique.  This I can mostly accomplish with a book and a weekend, and I can learn the rest as I go.

Hopefully you have a pretty decent idea of what kind of developer I am.  Some might call it “hacky” but I call it “resourceful”. Really what type of programmer would you rather work with or work for you?  Someone who says “If it ain’t in this language I ain’t doing it!” or the person who says “Buy me a book and I will be ready to go on Monday”.

Which brings me to the point of this post, the way that most companies go about hiring programmers is fundamentally flawed.  I have done some hiring in my career and I am not excluded from this.  It wasn’t until recently that I myself was looking for a new job that I came to this conclusion.  So here is my suggestion as to how we fix it.

The Current (broken) Way

You can’t get away from all of the soft questions.  They have been tried and true for a reason over the years. You simply have to ask things like “Why are you leaving your current job?” “Where do you want to be in 5 years?” If anything they are giant huge softballs to toss at someone who is nervous simply to break the ice, but you will also be able to gauge a little bit about the person’s personality and if they would be the right cultural fit based on their answers.  If someone says they are leaving their current job because they hated working 9 hour days and your employees average 10 hour days… well it probably isn’t going to work out.

The hardest part of hiring programmers is… well… how do you know if they can program.  So let’s look at a few of the ways I have experienced recently as well as some I have read about online.

 The Whiteboard

I have seen this just sprung in the middle of a bunch of soft questions.  The conversation went something like “How do you deal with a difficult coworker…. Ok now stand up and write a function that will reverse all the letters for each of the words in this string…”.  I get what you are trying to do by asking this.  I understand that you want me to code, however being able to code on the fly like that with no tools available is extremely nerve-racking, and is not the reality of your working environment, hopefully.

You see I have stood up in front of thousands of people and pitched solutions before, it doesn’t even bother me, I could do it in my sleep.  However, ask me to stand up in an interview where my livelihood is basically at stake on one question that some geek has his specific answer he is looking for and if I don’t get it I get sent home and I mentally collapse.  My heart starts pounding, I get nervous about every little detail.  ”Ohh my god should I use public or protected, should I make this static… I mean it is on the whiteboard…. Ohh crap did I remember to iron THE BACK of my pants?!?!”

Most of the time people fumble their way through it and the end result typically never looks like how I would have coded it in the real world.  The interviewer simply says yeah you could have done this here and that there and then they move on.

So what does this accomplish?  Well let’s review

1. It tests how nervous the person gets when asked to “perform” on the spot for a total stranger.
2. It shows you if they have good hand writing.
3. Generally shows the person knows what the structure of one simple function looks like and if they can write a loop.
4. Are they good at writing code on the whiteboard/napkin/paper.  If they are… odds are they have been rejected by everyone else and they are simply getting good at it or worse have had to solve the same problem in the interview before.

And that is it.  I really can’t think of much else this proves.  Now I can hear some of you moaning from here, “But Steve!?! If they can’t write code on a whiteboard under pressure how will they ever meet a tough deadline?”.  I can answer that simply.  I have never even under the toughest of deadlines felt like if I made a simple mistake on my code that someone was going to send me home and potentially my children don’t get to eat.

When we are in the context of a job interview that is what you are talking about most of the time. That is what is going through the candidates head.  Can they pay rent, feed their family… buy that car.  It isn’t about the solution to your silly character flipping problem.  So if you weed someone out by this process you are going to miss out on a guy who is very creative and can come up with the solution given a comfortable environment… like your workplace.

The problem is not that this doesn’t test to see if someone knows the fundamentals of code, it does to a certain extent.  The problem is what you miss by performing this as your only test.  You have no real way to judge the persons creativity, their resourcefulness or their overall understanding of larger programming concepts like patterns or even object oriented concepts. It may sound like sour grapes and I just don’t like writing on the whiteboard but that is not my intention here.  My intention is to show that this test is to easy and does not provide you with the answers you are looking for.  It is also susceptible to conditions that exist in this test that do not in the every day work environment, like high levels of stress and the lack of familiar tools. If a person fails on those other conditions alone you may mistake a brilliant coder as someone who can’t even code.

A Portfolio

As if we are all designers with a packet of pretty pictures to show off our creativity. I don’t have a single line of code that I can show a perspective employer due to contractual obligations and non disclosure agreements.  So if I show them something I hacked together on the side while having no time and possibly one to many beers I get eliminated in favor of the guy who may be un-employable and has had a ton of time to do side projects because of it. Not really a fair comparison.

Code Samples

Code samples are like a quote taken out of context.  You rarely can include enough to show what the program does, and they are read in a bubble with no perspective on how long the project was, what the budget was and what other resources were on the project.  Without being walked through the code sample, all you are looking for is “would I have written it this way” which is no better than the silly whiteboard question and wanting one particular answer.

Enough… What’s the answer.

I have read plenty of other people’s blog posts that try to tackle this question of how to hire a programmer.  I have read a few others that ask why 99% of coders can’t code.  The answer is they can I believe, under the right environment.  I think it is silly to type cast (nerdy pun intended) and pretend that you are weeding people out that can’t code.  You really think that the majority of people who have given you a resume are simply lying and don’t actually code yet they want to be put in a position where they will have to code so they can utterly fail right in front of you and their peers?  It seems far more likely to me that you simply are asking the wrong questions.  In my experience I wouldn’t have been employed for 12+ years if I didn’t have some coding ability, and by that nature I could and should be offended if you ask me to write code on a whiteboard or even mention reversing strings (String.Reverse()… duh).

So the answer is there.  It is right in front of our faces.  Those of us in the industry probably do it monthly if not weekly and it is…

Conduct a Code Review!!!

I know right.  Simple isn’t it.  Well let’s look at this process in detail.

1. A night or two before the interview give the person a problem.  Something like, parse this file of words and print out on the screen the count of all the words that start with each letter, and end with each letter.  Now it doesn’t have to be this specific problem, that is just one I came up with as I was typing it.  Realistically, pick a problem that your company has recently had to solve, and won’t take hours to complete.  Something simple yet forces them to cover the concepts that are important to you.  For instance the above example is obviously going to need some loops and show file reading, inspection of strings etc etc.
2. Ask the person to bring the solution to the interview on a thumb drive or email it to you earlier.
3. Sit down with a projector or just around a monitor and do a code review!  Let them describe what in detail the code is doing and why they chose to solve it that way.  Ask them clarifying questions just like you would if you were helping out a peer.

Now what does this test for us in comparison to the other ways?  What can we learn about the person from this process?

1. Creativity!  It is probably the most important trait a programmer can have.  By giving them a vague set of requirements you get to see the persons creative side.  Do they simply just write out a table of all of the letters and words, or do they make a drop down with the letters and then show the statistics when a letter is selected. The creative side that is hard to see if the person is overly nervous like when writing on a whiteboard, hopefully at home the person can relax and write a creative solution, imitating your work environment right?
2. Independence. By not giving them a specific task and telling them exactly what to do you can see if the person works independently.  If they email you back 100 questions and are scared to solve it on their own, you may find out that that person would need a more task driven or micro managed style to be successful.
3. Cultural Fit.  By sitting down with the person and talking with them in a real life work style type of way you can really gauge what it would be like to work with that person. Do they get defensive when you make another suggestion?  Do they claim that there is only one way to do it?  You get the point, if they start nerd-flexing you will know if it is a fit or not.
4. Coding skills!  Did they comment?  Worry about error handling?  Use proper variable names?  Or did they try to do everything on one line to impress you? Lastly they should be able to describe everything right there in front of them and how it is working.  This is your test on whether or not they can code, you flush out the full awareness of the candidate about an entire solution.  Not just a method stub that does something that already exists.

Ok I hear you again…. “Steve… woah woah… you are a smart guy… but you are forgetting that they will simply just go cut and paste a solution.”  My answer is this, of course they will.  The real question is, do I care?  If a person is resourceful enough to head on over to StackOverflow ask a question and get it answered and paste the solution back into the code.  Do I care?  Hell no, I do that frequently in my job.  What I would be more concerned about is if the person wrote their own implementation of a hashmap because they didn’t like the other ones.  That person is going to cost me big time on a project where the other one probably saved me time.

Now the key is that they need to be able to tell you what the code is doing during the review, and bonus points to them if they actually tell you the cut and pasted the code. But if you are asking them what line 100 does and they blank, then well you know more about them than if they just happened to study up on string reversal don’t you.

Conclusion

I know if I am ever put in a position to hire someone this is the route I am going to take.  It isn’t about some silly fraternity prank where I see if I can stump someone or worse ask language specific nuance type of questions.  It is about finding the right person for the job, and in most cases that is a creative, resourceful, get things done type of person.  This test I believe gets you really close to finding that person…. does yours?