One of the fastest ways is to ask about something they had to "fix" (use the word "fix") at their last job, or some problem in a pet project that they just figured out. This will sound like poetic license, but really good programmers have a light that flares when they start talking about that. They immediately are back in the trenches, telling about how they couldn't figure out some nasty recursion error or some server problem that was untraceable. Usually their hands start getting animated; they loosen up.
I couldn't care less about the problem OR the eventual solution. I couldn't care less if he used an open source module to write some new code last week or if he thinks CouchDB is super amazing.
What I really want to know is how they think.
When you have a programmer who lives in code, he (or she) swim through problems like they are physical objects. They find passion in killing bugs and making code more efficient. I can hire a hundred people who can recite what the Gang of Four is or write a bubble sort. I can't hire guys who care about whether their own code can be improved.
But this is just one way. There are lots of ways to tell.
I 100% completely agree. I think asking programming trivia questions in this day and age is ridiculous because everyone now has memorized every single CareerCup question out there.
When I interviewed for previous copmanies, this is actually one of the questions I would use. "What is the hardest bug you've ever worked on?" If you take this question, and keep pressing for more and more details, and expand on that question, you can get a surprising amount of information about someone's experience and understanding. If they can't adequately answer this question, it means they haven't really been deep in code, or don't have a lot of experience, so that sets your expectations relative to the position that you're hiring for. If they claim to have a lot of experience, but can't go into too much depth, it means they're not very excited about getting their hands dirty or they don't understand what really happened, which are both bad signs to me.
I don't care if they can write up a function that can spit out the Fibonacci sequence. I can that they are smart enough to figure out relatively complex issues and can communicate this intelligently.
I couldn't care less about the problem OR the eventual solution. I couldn't care less if he used an open source module to write some new code last week or if he thinks CouchDB is super amazing.
What I really want to know is how they think.
When you have a programmer who lives in code, he (or she) swim through problems like they are physical objects. They find passion in killing bugs and making code more efficient. I can hire a hundred people who can recite what the Gang of Four is or write a bubble sort. I can't hire guys who care about whether their own code can be improved.
But this is just one way. There are lots of ways to tell.