[tconfrey]

First I'd say that at a company level there should be an overall plan for the interview that you fit in to. Interviews work better if the hiring manager assigns specific areas to specific interviewers, otherwise you can all end up focusing on the same area and not getting a rounded view of the candidate. (e.g. Jim - you focus on his general software engineering skills, John - quiz him on C++, Kate - do a resume walk etc).

In the absence of a plan (or as part of one), a good approach is to pick one or more projects from the resume and drill down into the details. Find out specifically what the candidates contribution was, what was the high level architecture his code fit in to, how was his/her piece designed/structured/laid-out, what were his interfaces to other team members, what difficulties (technical or interpersonal) arose and how were they handled, etc.

Feel free to challenge them and push a bit - why did they make the design choices they did, what would have worked better etc.

I find this approach can give you a good sense of the candidates level of contribution, their understanding of the larger scope in which they were working, their ability to debate and defend their choices, and their ability to communicate with you.