First and foremost, almost everyone in the world relies heavily on a multitude of various tools (whether Googling, reading reference texts/tablet books, social networking, trial and error tests, etc…) to solve real world problems. This goes not just for coding problems but almost any problem you can think of today. What coding tests are really trying to ask and get the answer to is, “Is this person a good thinker and problem solver?”. Unfortunately due to the pressures of interview environments, cocky di*khe*d interviewers, time constraints, etc… few good coding tests exist.

Personally what I have done in the past, and what I prefer, is to get a decent idea of the candidates background in technology with a techie discussion such that I know they are thinking for themselves and, possibly, if anything, some test or assignment to solve a problem but it doesn’t necessarily even need to be a coding problem. Anyone who knows anything about computer science knows that being a good coder or software engineer has absolutely zero to do with knowing lots of languages intimately (or even 1 for that matter) and a lot more to do with how well you solve problems and your resourcefulness and ability to research effectively.

To reiterate John’s question from earlier, why do we entertain this junk and/or how did it ever get this way?

-Are mechanics given automobile teardown/build tests? No
-Are nurses given hospital equipment and drug administration tests? No
-Are accountants given math tests? No
-Are chemists given lab tests? No

I don’t quite understand the fascination with giving out these tests and wasting such an insane amount of time with interview after interview after interview in the recruiting process. You can gauge someone’s skill without going through 5 rounds of interviews and a coding test fairly accurately with just a 45 minute “techie” style interview + reference checks. And, oh the horror, if for some reason one falls through the cracks and can’t code (or learn really damn quick)? Wow, you are out what… a whole 1 or 2 weeks tops? Well guess what? You just saved yourself 4-8 weeks in the first place. And someone falling through the cracks like that would be exceedingly rare if you interviewed correctly (quick phone interview/screen 15-20 minutes, 2 follow up interviews max 30-45 min each plus ref checks).

I watched a show on Discovery or TLC recently about the rigorous recruiting style of Google and how one candidate was interviewed or called back in a total of 13 times before his offer letter. OMG! I would have seriously been like, “you know what guys… you can keep it.”. I mean come on. This fascination with testing candidates just baffles me.

The reasoning behind the whiteboard test is to have the candidate provide a simple solution to a simple problem but outside of their comfort zone.

The test should not ask something that requires a complex algorithm or one where the candidate even feels they need to come up with a complex algorithm.

The review of the test should not focus on syntax errors, although absolutly the candidate should feel the pressure of making something that would compile. After all, it is what they do.

A candidate that is comfortable with coding, can picture code in their head before putting fingers to keyboard. They will solve any whiteboard style question immediately and have absolutely no need for cut n paste or intelisense or any other “tool”.

The whiteboard test will indicate if a candidate is comfortable at coding.

Other tests, including more complex code on a PC as well as discussing coding techniques and design patterns will give you more information about the ingenuity of the candidate.

No one test should ever be deemed suitable alone in determining a candidates ability.

I have seen candidates that can talk the hind legs off a donkey about the theory of OO. Yet were almost completely computer illiterate!

You might be after a theorist and in that instance it would be the perfect candidate. You might be after an innovator, or a code monkey.

Usually the idea is to give a simple problem to see if they can program at all, in any language. About 10-20% of candidates can pass a phone screen, have a resume with all kinds of programming, and do fine on all the other interviews. But after I ask them to write a few lines of code, suddenly they confess that they cannot program at all, in any language. This has been most often true for candidates with experience. Most new grads remember something, at least.

I keep the copies of the code that they write. I’ve looked at it years later and have found it to be an accurate prediction of coding performance, at least in the people that were hired.

I also invite candidates to bring code samples.

Besides, whether you like it or not very little program out there is anything like finding a string in a string or sorting an array. All that stuff has been done already.

Yeah, I think it’s a stupid way to figure out if someone can program and Joel has perpetuated the problem. I wish they’d stop, because I hate doing them.

I now have a large whiteboard in my bedroom which I use to practice all the most common whiteboard problems in each of the languages which I list on my resume. I’ll be a shoe-in for the next shop looking to hire a senior fizzbuzz engineer.

Frankly, I can already feel my brain starting to lockup. I wonder how the interviewer would respond to my asking them to complete a whiteboard coding question so that I can evaluate whether they are worth working for? After all, I’ve been doing this now for over 25 years! I’ve probably forgotten more than some can ever hope to know (but I dare not tell the interviewer that!).

As interviewer I like the candidate to bring in some project code, complete or not and let him explain why he/she has taken certain decisions. This, together with good non-standard questions gives some insight in coding practice. In the end, most of the coding tasks in my industry require flexibility, enthousiasm, OOTB thinking and as last programming skills.