I have had cause to interview programmers over the years. It is both interesting and difficult work.
My favourite set of questions for interviewees starts by asking them to describe a large system that they've worked on before - I pick an appropriate one off their resume - and getting them to draw the system on a white board.
The interviewee gets to decide from which point of view to describe the system. If they ask, I tell them to pick whatever they are most comfortable with. They might describe the system from a business point of view (data flows between user departments, reports, and letters to customers) as a technical architect (hardware, IP networks, J2EE), or as a programmer (class and interaction diagrams), or as something else altogether. This is a good time to see how they answer questions from what may not be their natural perspective (What was the business case for this system? How many classes were there altogether? Who wrote the coding standards?)
After a little bit of probing, and getting about 10 boxes on the whiteboard, I then ask what they thought worked well in that design and what worked poorly. I also ask them what they would do if it were up to them to redesign the system from scratch. The intent of the question is to evaluate their design skills, and whether they think critically about what they are doing.
From this, I start making up my mind about whether they are a thinker, a leader, a starter or a finisher, experienced or new or just along for the ride.
Anyone falsely presenting themselves as being a senior member of the team that worked on that project tends to show their hand by speaking in generalities and not having a strong opinions on specific issues.
Not quite the same as a coding test, but valuable.