Technical tests in interviews as a judge of employer

Question

There is an increasing (and generally good) trend for potential employers to ask candidates to sit some sort of technical test before even being invited to interview.

I appreciate that it is going to be more cost-effective that even a phone call to screen you but there seem to be two types of test out there, in the wild.

The first type is the genuinely practical, e.g. Practical programming test in interview, where you're sat in front of a 'real' machine and asked to code away. You'll be given a decent environment, have a web browser (for Google/MSDN/Stack Overflow/etc.) and a spec/question to answer as well you can within a time limit.

Then there's the more formulaic, answering, almost trivia quiz-like, questions. You're in front of an application that asks you specific questions, possibly with multiple choice answers. They'll dress this up as wanting you to be able to answer from first principles, but realistically, it's just a cheaper way than having a hiring manager call you on the phone.

As a candidate for interview, should I be wary of any company asking me to do a technical test that isn't a realistic simulation of a working environment? Or should I just deal with it, ace the easy test questions, accept the fact that I need to prove (again) that I know the really basic simple stuff off pat (or have at least read the first couple of chapters of any primer for the language I'm being tested on)? It's their job, I need to jump through their hoops in order to work there.

If a company can't trust me to know the basics, should I want to work there?

---

Update: thanks for the comments. In my case it's probably because I'm a gamekeeper turned poacher. I've been a hirer and interviewer and the muppets who blatantly lied did annoy me. (Actually that's being harsh on muppets, I love Animal and Rowlf the dog.) I'm just fed up answering the same textbook questions about mainly arcane trivia within the language again and again and again.

Maybe that's the answer - this idiot filter is almost certainly what the recruitment agencies should do, but generally they're slave traders who don't know what or how developers do what they do, just in it for the commission.

Answer 1

I think it's only fair they want to check if the data you provided in your summary makes any sense. After all, it's relatively easy to make up a glowing summary and there are even plenty of companies that forge university diplomas these days. If I was the recruiting guy, I'd probably do the same.

If we practice TDD, why shouldn't they practice TDH (Test Driven Hiring)?

Answer 2

No you shouldn't be wary of such a company.

Why? Because a simple test is an effective idiot filter. You'd be surprised how many people can't explain or code simple concepts like recursion or even far simpler concepts than that. You can save yourself an awful lot of time and money with a 15 minute test that'll weed out at least half your candidates.

If the company doesn't trust someone to know the basics, they're actually doing due diligence in recruitment. I'd be more inclined to work for such a company just because there's a higher likelihood that their employees aren't idiots and thus it might be a better place to work.

The "real" test you refer to is less meaningful imho because it can then come down to familiarity with a particular language feature, library or framework and that's far less useful as a litmus test.

Answer 3

I've set a paper of multiple choice questions to be answered by candidates in the past. It doesn't mean that's going to be the only kind of technical test, but it's a much quicker way of screening people who really don't have a clue (whatever their CV might say).

(This also provides good feedback to recruitment agencies as to whether their assessment of technical abilities appears to match reality.)

Note that none of the questions I set were particularly hard... it was just a preliminary "get rid of the dross" type of test.

Answer 4

No, you shouldn't be wary because it may be realistic in ways you wouldn't think. For example, someone may put down a trick question in such a test as a way to see how you handle that situation which may happen in the real world if someone wants something that isn't possible, e.g. the user wants the system to read his mind all the time and have everything ready before he asks for it and maintain 100% accuracy. Alternatively, really hard questions can have a similar effect where you may get some people that will try to guess an answer or some may just admit that they don't know something. This is more a test of communication than technical knowledge which may not always be easy to see.

Super easy questions can also have a similar effect if after asking the question the reply is, "That is such a stupid question! Who told you to ask that kind of crap? I'm not even going to bother answering such a question," then one may get the impression that this person's interpersonal skills may not be able to handle cases where a customer or client may require some diplomatic and patience in resolving their issues.