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.

You just have to be one step ahead of them. If you log the requests in the firewall and not on the provided computer, they won’t be able to erase the log. Also, limiting access to only outbound ports 53 and 80 (and arguably 443) is a cheap way to limit their connections to ssh tunnels and proxies. I’d still log requests to the other ports (so you know if they attempted to connect to ssh).

Another option would be to not block the requests, but instead just log them. You’ll be able to see the context of what they’re doing, which is sometimes good enough. Seriously, the only reason people would use ssh during an interview would be to copy or review some old source code that they had written in the past. That brings up a very interesting point.

Is looking at your old source code considered cheating? Old source code is something akin to looking at other people’s websites and code snippets on the internet. Arguably, it doesn’t violate any licenses. In my humble opinion, the best developers are extremely resourceful developers; so, couldn’t old source be considered just another resource?

Comments?