In a sense, you are looking for a way to verify that the interviewee is passing some kind of Turing Test. For example, even if the interviewee visits your office in person, she or he could have a subcutaneous radio transmitter embedded in their ear canal that is hooked up to Watson over at IBM. Are you planning to check for subcutaneous ear transmitters for all the candidates who visit you? No, because the likelihood of that kind of cheating is low, and the cost to the cheater is high enough that few cheaters would be willing to bother.
So the goal is to orient the test so that cheating is expensive, and so that the signal you receive from the candidate is hard-to-fake. Nothing is ever perfectly cheat-proof, so you need to decide on how expensive you want to make the evaluation. A test that's ridiculously elaborate will drive away potentially good candidates who don't have the time to putz around with complicated tests in their already busy lives. A test that's too easy will get many good submissions from many folks, making it hard to separate the sheep and goats.
In the domain of programming, some tips that I have used when building and conducting programming tests:
- Make the test less about trivia and more about creativity / ingenuity. For example, I never explicitly ask people to submit unit tests with their code samples, but I penalize them heavily if they don't simply do that all on their own. If they take the initiative to make something good, rather than something that minimally meets the requirements of the test, it's less likely they are cheating (since cheating costs someone else to use time, they are less likely to go the extra mile).
- Make the question very open-ended, allow the candidate to use Google or other people, but ask for an explanation for their approach. By the time the "cheater" has explained all about the cheating approach taken, the candidate ought to actually know about it, well enough to write a write-up. Here again, unless the cheater has access to a magic oracle person with no personal time constraints, it's going to be expensive to get someone else to take a lot of time to both solve a problem creatively and write the write-up.
- Use tools like collabedit or Google Docs to have the candidate solve a problem in real time with one of your programmers. During the interview, make sure to ask questions that are very specific, and look for quick answers. If the programmer is doing well at solving the problem, they should be able to de-focus on the programming, quickly answer related side questions, and then re-focus on the programming. If they need extended pauses every single time to answer routine side questions, they are probably consulting something else for help.
- Make the candidate pass through several filters. Ask a wide range of questions that have a wide range of difficulty. After all, a big part of technical interviewing is to figure out the technical skill boundaries of a candidate. No one knows everything and you need to know where the limits, cracks, and low aptitude areas are. If you give a phone screen with 5 questions, ranging from easy to hard, document both the candidate's answers and also the speed with which they answer. Then give another phone screen that is similar, and possibly a third. It will be difficult for a candidate who is cheating to arrange for the same assistant to be there all the time, and if you see glaring inconsistencies in aptitude on certain kinds of questions, it can be a red flag.
- Ask for a certified sample instead of the answer to a test. Ask the candidate to submit a sample of code from a college course, an open source project, etc. and ask for the name of a reference (not a student, but a faculty member, a teacher, a teaching assistant, a project leader) who can vouch that the candidate wrote the code. Then ask the candidate to explain their coding choices for that problem / project.
The basic idea here is that (1) make cheating expensive and (2) find a trade-off for the expensiveness of (1) such that good non-cheaters are not put off by the barrier to entry at your company.
I would also add that in my years of experience designing and conducting programming tests at my current company, cheating is the least of my worries. Few candidates can even follow basic instructions. For example, throw in a simple instruction such as: "You are not allowed to use built-in string manipulation functions to solve this problem." In my experience, greater than 50% of the candidates still use built-in functions, unapologetically, and have no answer when asked why they did it.
If you just use a few of these screens, it will beat out a large percentage of cheating, laziness, and low aptitude noise. Then, those few extremely diligent cheaters who make it through will be less of a time-waste for your company.
You might also try telling the candidates that they may receive help from a friend, but only if they tell you the names of all the people who helped them. If the candidate doesn't seem like the genuine article in the in-person interview, then hey, maybe you can call up their friend who helped them cheat and gave the better answer in the coding test?