If you really want to weed out the inappropriate candidates, ask a range of basic questions to gauge their range of knowledge. From the more old school questions ‘how is a string stored in memory’, ‘what is a pointer’, to much more new school questions ‘what is a pattern’, ‘what are your thoughts on using 3rd party extensions vs coding solutions in house’, ‘when should you unit test’. Nobody will have perfect answers for all questions, but understanding where the candidate has focused their knowledge development will help you gauge how much to expect from the candidate. A truly passionate developer will A) Know of, or have some experience with the answer or B) Have the balls to say ‘I don’t know the specifics, but I’d really like to find out… can we discuss it for a moment?’.

They only take a few minutes to ask, and if someone can answer some of these questions with honest thought and understanding, you’re way beyond the ‘write some code you code-monkeying code monkey’. No screwing around with net meetings and code review and all that bs.

You want intelligent and relevant candidates? Ask intelligent and relevant questions.

Just sayin’…

The problem with these tests is that it’s treating the process backwards. If you want someone who is really good at what they do, no matter what discipline you’re hiring, they have to choose to work for you. You want it to be as easy as possible for them to find you and get through the interview process while still filtering out the people you don’t want. Good people do not need a job, they already have one. The more hoops you make them jump through the less likely they’ll bother to keep going. This is why tests like ‘reverse a string’ or fizzbuzz are great. They’re easy to understand, fast to implement, and shouldn’t require any outside resources if you allow the interviewee to use whatever language they want. Then you give them a complex problem and have them work through some general design and implementation ideas without talking about code to make sure they can manage some high-level design. Between these 2 types of tests you should be able to filter out the non-programmers while not putting up too many roadblocks to deter someone who needs to choose to work for you.

I was thinking what happens when you have Aaron on the left of Carol (I mean everything in the example seems so orderly and simple without loopholes). A better example detail explanation for me at least is the bigger set of array of numbers and not as orderly initial set like the one found in

http://www.algolist.net/Algorithms/Sorting/Quicksort

It’s the partitioning that I was confuse about.

So if I were you, I would use a real life example instead, more geared towards structure than algoritm.
Structures are hard to fix if someone have made bad ones, algorithms aren’t. Usually.

To be honest, given the time constraint, I wouldn’t expect a particularly sophisticated attempt to cover tracks. What’s more is, the more sophisticated the attempt to cover tracks, the less likely they’ll actually need to go to those lengths to do so (i.e., they’ll probably be the sort of person who will nail the test *anyway*).

My concern really is use of InPrivate or clearing the browser cache because it’s just so darned easy. Yes, looking at firewall logs gets around that, and I even considered setting up a proxy server on my own PC that the browser will point at (with suitable rules to prevent access any other way). In all honesty though, I don’t think it’ll be needed.

I do not believe that looking at source code is cheating at all—however, copying source code *verbatim* without understanding anything about it *is* cheating.