[MrTonyD]

I'm a very old timer...and I think people have forgotten that there was a time here in Silicon Valley when it was enough to be someone with programming experience. The interviews - such as they were - were mostly just to see if you were someone who wasn't a complete jerk. As the supply of programmers has steadily increased, the hoops to jump through have also increased. So now it is acceptable to test people and just generally ask any lame question because "you are the hiring manager". Experience and education should be enough - I'm really not clear about why it isn't. (Not saying that programmers don't have different skills - and different experience. But, for the most part, most programmers can be taught enough to do most things.)

[toast0]

> I'm a very old timer...and I think people have forgotten that there was a time here in Silicon Valley when it was enough to be someone with programming experience. [snip] Experience and education should be enough - I'm really not clear about why it isn't.

There are people who managed to get a CS (or similar) degree but can't program or problem solve, but manage to get hired at enough places to appear to have experience, but still can't program or problem solve. That's why I interview with a programming programming problem that I hope is at least a little bit interesting.

[donw]

The real key is problem-solving ability: can a prospective hire get a grip on a real-world problem, and then break things down into solvable components.

Real-world problem solving is often very different than the very clean-cut computer-science exercises that companies tend to throw at candidates, which nominally have a set of solutions, only one of which is "correct" (in terms of computational complexity).

Personally, I'm a big fan of one of two styles of interviewing.

Pair interviews are great, because they are the closest thing to a real-world test-drive that you can get. During a pair interview, you work on real production code, with a member of the team that you will be working with, and at the end, it's pretty easy to tell whether or not the Thunderbirds are "go".

For non-pairing teams, I usually go with a simple (think "fizzbuzz") programming exercise, followed by a combination of collaborative problem-solving sessions with members of the team, exploring the candidate's background (what problems have they solved in the past?), and also a check to make sure that there's a fit in terms of engineering culture (somebody that hates TDD will hate working with me, for instance).