[trcollinson]

You’re thinking rather short sided here. There are a lot of ways to find out if someone can think critically and also has the appropriate level of skill at programming. I prefer to give them a set of much more real world type scenarios to see how they will handle things. Often I do this in a paired programming scenario. We both sit down. I drive they navigate and we spend 20 - 30 minutes trying to build something. The something is never anything that is going to go into production. Just code that is real and useful and can show me how they think through a problem and whether they can catch mistakes in code as they happen in real time. Lately I’ve been a fan of making a shopping cart (since the software I build doesn’t have a shopping cart).

I keep it very short. I try to make it low stress. I try to make it fun and funny. Why? I really want to know if the candidate can work with me and how they will work. I don’t care one bit whether they can remember the big O notation of a red-black tree search or whether they know how to reimplement a complex datatype. I care how they will work with me in my environment.

You might say “you’re method is just too simplistic. People can game it and get through.” It’s been accused of that before. And frankly, I can memorize algorithms and game that interview. Try gaming me while we pair on some code and I try to toss in a few roadblocks. Try to game me as I try to see how you will react as we work together. It’s hard, and my methods have been quite successful for me.

As for the pay, I don’t pay people what Amazon, Google, and Facebook pay. But I pay very well and people stick with me so it seems to work out.

[AstralStorm]

The other good test is to toss some intentionally cleverly buggy or incomplete piece of code to analyze and debug, since a third of the job is debugging.

And by bug I do not mean super hidden tricky language feature you get to look up on language standard to not misuse.