Recently, a good friend and fellow developer lost his consulting gig.  Normally this wouldn’t be cause for alarm or even interesting to read about. It’s the nature of being a “hired gun”.  You work on an engagement for a specified period and then move on.  But the events that occurred after his contract ended, made me question how businesses hire developers.  Specifically the interview process, and why I think it’s broken.

You see, Ted (my friend) had been on his 4 month engagement for 7 years.  Yep, you read that right.  During that time, he worked on many different projects, some interesting, some not, but all them (well mostly all of them) involved technology stacks that did little to help his marketability for future work.  Again, this wouldn’t be much of an issue on a 4 month engagement or even a 9 month stint.  However, after 7 years, Ted’s technology tool-belt became quite outdated.

Now I know some of you are saying: “Hey, as a consultant Ted should have kept up with the latest technology on his on time.  A consultant or hired gun needs to be a self-starter and keep learning and growing.”  I can’t argue that.  In fact, I spend countless hours reading and coding to hone my skills and absorb all I can to help myself and my clients.  However, it still doesn’t excuse, in my opinion, the arcane process developers are subjected to during an interview.

Let’s return to our protagonist.  Ted was out of work and needed to look for a new contract and that meant going on interviews.  Remember, it had been over 7 years since Ted’s last interview. He was 7 years older now, which meant he was competing with developers younger and more current with regards to skill-sets.  He was nervous, and he had reason to be.  Nevertheless, Ted set out on his daily quest to find work.

After a few interviews, Ted called me to tell me how it was going.  It was grim.  I knew it wasn’t going to be easy for him, not because  he isn’t capable, but because interviewing is tough.  As he detailed to me some the questions he was asked and the quizzes he was given, I thought to myself, this can’t be.  Has the interview process really not changed in the last 20 years?  Are businesses still asking the same questions I asked candidates 15 years ago?

Let me preface the remaining post with an acknowledgement: Measuring a candidate’s level of knowledge as it pertains to the position they are seeking, is a necessary but often difficult and subjective process.   Business’ often seek a boilerplate, repeatable methodology for determining if a candidate possesses the skills required to work for their organization.  But asking someone to create a method (pick your language) to mimic the Fibonacci Sequence is not the answer.  Nor is asking them to tell you the missing number from a sequence of numbers on a self-destructive tape (which of course, can only be played once and not rewound).

Some of the reasons often given for these types are questions are:

1. We aren’t concerned about a right or wrong answer, we are simply trying to learn more about how the candidate thinks. —  Just because we are developers doesn’t mean we watch the Big Bang Theory.  Nor do we all have subscriptions to Scientific American.  And unless the position being sought is scientific or mathematical in nature, why the hell should I know or care about the Fibonacci Sequence.  I heard about it in 10th grade, so let’s leave it there.
2. We aren’t concerned if the candidate completes a coding test, we just want to see how they structure their code.  Is it readable, does it make sense.  —  You have 30 – 60 minutes to write code under already stressful conditions, and all the while you are trying to guess what the hiring team is looking for: do they want it perfect (and what is perfect), should I put comments in the code, do I use properties or class-level variables.  The list goes on.  The bottom line is that no one codes under those circumstances in a typical work environment. It’s like being asking to urinate in a cup on-command; it’s not normal and it’s very hard to do.

While it’s true you might learn something about how the job candidate structures code under pressure, have you really learned anything about the person writing the code?   Will they be an asset to your organization?  What do their 15 lines of Fibonacci code say about their ability to be self-starter, a team player or a good communicator.  Are these the tools we should be using to determine the value of a candidate to an organization?   Do you really expect a person to remember one of the 6 ways to write a LINQ statement?  Why would should anyone fill their head with information they use only sometimes.  Ever heard of Google or stackoverflow (a.k.a wikipedia for developers)?   The internet is a developer’s desktop reference.  We need to stop expecting candidates to be able to recall, on demand, some random function signature, method or programming term or principle.  Most of us use the Internet and/or colleagues when we are stumped, just as other professionals do.

I am not saying that basic skills questions should be ignored.  On the contrary, I believe they are critical to understanding the “truthiness” of a candidate.  For example, if you are looking for a developer with REST experience but they have no idea what a route is or think REST is a language vs. an architectural principle, you should probably remove them as a prospect.

However, I do believe that more time must be spent getting to know the person.  What makes them tick, what are their interests, do they appear to have a good sense of work-life balance, will they work well in a team setting, are they good listeners and can they communicate their thoughts in a clear, concise manner.   No quiz or programming test can reveal those traits.   If the position I am trying to fill requires client/business interaction and the candidate appears to have communication issues or indicates a desire to work in isolation (as some developers do), then I really don’t care how neat their code looks.

Take the time to read their resume and talk to them (really talk to them) about past projects and find out what they liked or didn’t like about those projects.  It will give you a sense of who they are. The more you communicate with them, the more relaxed the interview becomes, the more open they will be and that’s when you really get to know the person.  Only then can you really know if they are a fit for your organization.  It will be time well spent.

Finally, hiring a good person is tricky and hiring a great person is down-right difficult.  In reality, it takes about 6-8 weeks to learn if you hired the right person, and by “right” I am referring to both their technical skills and their personality.   Some people interview well but turn out to be a bad hire, or vice-versa.  In the end,  you want a person who isn’t afraid to say “I don’t know” when asked a question,  but who is also driven to find the answer.  You want someone who adds value, who makes a positive impact.  You want someone resourceful, not robotic.

It’s time to change the way we interview developers.

Oh, and my friend Ted, he is still searching.