Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When pre-screening candidates for a position prior to the first face-to-face interview, how useful are technical tests in filtering out poor candidates and possibly predicting their ability to succeed in the position? While some of the personality based ones might not say much, is there benefit to sending a technical test (e.g. on Java or C#) prior to a face-to-face interview or even a phone screen? Also, do these tests ever falsely identify a strong candidate as one that is likely a poor fit for the position?

share|improve this question
Please follow this proposal for that kind of question: Organization aspects –  bigown Dec 10 '10 at 19:35

8 Answers 8

up vote 8 down vote accepted

I don't think that there is much value to technical tests that aren't delivered face-to-face during the in-person interview. You can send me a technical test on virtually any subject, and me and my pal Goog are going to deliver reasonable answers.

On the other hand, you can tell a lot about a potential candidate when they sit across a table from you, sweating and squirming over FizzBuzz.

share|improve this answer
You may be able to google the answers, but a surprisingly large number of candidates can't or won't. –  Bruce Alderman Oct 29 '10 at 16:39
If the types of questions are easily googled, then the questions are bad imo and are likely only testing trivia. –  Steve Evers Oct 29 '10 at 16:41
I'd rather not have someone watching me code. It's very offputting. Chance's are they're squirming because you're watching them not because they can't do it. –  sashang Nov 24 '10 at 0:40
SnOrfus, I see your point, and yet: FizzBuzz is useful as a low-end filter, and is not trivial, and yet can easily be googled. And there's not only Google, but also people's smarter friends helping them out, including through SE. –  poolie Sep 9 '11 at 6:38

I sent a test to candidates for a position we're hiring. The task was to debug a simple web signup form. I put in half a dozen errors and inefficiencies, but nothing that would prevent the page from loading. It just didn't always work the way it was supposed to. Then I filled out a couple of user tickets for the form, describing the problems they way they might appear to an end user.

Only one candidate was able to fix both errors reported in the tickets and make note of other potential problems with the form. If nothing else, this simple test helped screen out candidates who might struggle with the actual job.

share|improve this answer
I like this, it's a lot harder than it seems (the interviewee may think there are only the two errors you mention) and harder to find the actual answer than a problem they do from scratch. –  HLGEM Dec 17 '10 at 22:09

One of the best interview screen questions that I've heard is to invent a fictitious technology buzzword maybe something like "pineapple endpoints". Then casually ask in the phone interview how much they know about it. If they say anything other than "nothing", you should be very concerned.

share|improve this answer
Pineapple endpoints. Awesome. I hope you know that this is now 100% stolen. –  Adam Crossland Oct 29 '10 at 20:24
It'd be fun to invent a fake webpage about it and see if they take the bait. –  User1 Nov 5 '10 at 14:50
I'm so want to ask someone what's the differnce between how Oracle handles pineapple endpoints and SQL Server. I may have to steal this one. –  HLGEM Dec 17 '10 at 22:08

Well, if nothing else (and a consensus on this has still to be reached) it will show which candidates at least know where to look to find answers.

share|improve this answer

Even a simple exercise can show you something about a candidate. I've had timed tests, interesting problems with unlimited time, and even simpler "Fizz Buzz" type tests. As long as they can demonstrate that they can write code prior to coming, you'll find that there's a lot less people going your way. For me, I would (and have) question(ed) every job offer that comes my way without writing a single line of code.

share|improve this answer

As said by the previous commenters: written technical questions a mostly useless, especially if delivered way before the interview. What you want to know is how the candidate thinks, and how fast he can narrow down on an issue.

Pick something really simple at the beginning of your pre-interview phone screen: atoi, reversing an array in place, reversing a linked list, something really basic. Asking those questions over the phone let you test two things: first the ability of the person to code and how they think, second the communication skills this person has and how well can he share this knowledge.

In my experience a lot of candidates struggle with these questions, even with copious help and you don't even need to bring them over for a sit down.

share|improve this answer

Technical tests for the sake of learning whether a person knows a particular bit of information are of low usefullness. You need to ask enough to see whether the person has actually worked with the technology you require experience in, but small details are not valuable test questions.

Instead, you want to know how the person thinks.

  • Can the interviewee find an answer to a question he doesn't know?
  • How do they find these answers?
  • Once they learn the answer, do they retail it fairly well?
  • When a solution is very difficult to find, do they communicate this to the appropriate people and ask for enough time, help, or another way to "resolve" the problem?
  • Does the interviewee routinely learn new programming concepts or details in an effort to stay current?

After discovering answers to these questions, you're far mor likely to choose the correct person. Judging primarily by a score on a technical test, you can end up with someone who knew the answers, but does very poorly in unfamiliar territory. A person who does well in unfamiliar territory will do well with pretty much whatever you hand them.

share|improve this answer

I think a short test to make sure the person is at least basically worth interviewing may be worthwhile.

You would have to expect a lot of cheating: failing to answer may show the person can't program, but answering doesn't show anything very positive.

Some headhunters will systematically distribute the questions, or even the answers, to candidates they propose. (My friend recently discovered this was happening with applicants to her company.)

If the test is very laborious, you have to bear in mind that some good applicants may not think it's worth their time to do it before even getting a confirmed interview. Google can (or could) get away with long puzzles because they are (were?) a highly desirable employer, and because the puzzles were fairly long in their own right.

If you do ask questions, I would definitely ask at least a few questions about them in the followup interview:

  • this will probably tell you whether the person actually solved the problem themselves or just cheated
  • for candidates who did solve the problem well, it starts out the interview in a fairly comfortable situation of them talking about something you already have in common
  • you can check whether they're able to talk about code clearly, as well as writing it
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.