I have a similar technique for phone screens. Candidates are told to do the interview where they can receive email. To avoid cheating, we send them a couple o

I have a similar technique for phone screens. Candidates are told to do the interview where they can receive email. To avoid cheating, we send them a couple of code snippets right as we call them. Then, we talk about the code. We found that phone screeners have a bias toward those who speak well, so we often brought in terrible programmers for a half day of interviews. What a waste, especially when flying people in. The in-person failures we experienced were of the FizzBuzz variety, not the "I don't exactly under stand concurrency" sort. So, we started asking people to read some code and comment on it. Really basic Java stuff: Will this code compile? Trace the flow of execution through this method if the BlahException was thrown. String comparisons with ==. The idea was to see if (1) the person was at all clueful, and (2) if they had actually written Java code. As the linked blogger noted, the disparity in responses is shocking. We found that about half the people we interviewed thought that execution of a Java method ceased once a catch block had been entered. Half! How could they ever have written robust production code? These were often people with years of Java experience on their resumes. I just don't understand how someone could write a bunch of Java code and not understand the basics of how exceptions work. Some other parts of the code review were more nuanced. Most candidates knew that one should not compare strings using double equals, but they usually couldn't explain why. Nor did they understand why == sometimes seems to work when comparing a referenced String object to a literal. We were happy to hire smart candidates that hadn't done a lot of Java work, but we wanted to avoid people who had supposedly spent years with a language and didn't even comprehend the basics.