Why not just pair with the interviewee for half a day or a day? You will learn how they think and work and if you like them. It's a riddle to me. I've never heard from anyone actually trying it and not being happy with the insight won.
I'm a lot more interested in how someone breaks down an architectural problem than I am in how well they can implement heap sort on a whiteboard. The closer the interview is to real coding the more you learn.
Why not pair on whatever you would be working on anyway. I usually have to solve many architectural problems every day but honestly never had to implement a heap sort all my life. So there should be ample opportunity for an interviewee to show his architecture-fu
I think it's got to be more than just github for the resume. There are tons of other open sources of data. Personal blogs, twitter feeds, even things like delicious links can be indicative of what a potential candidate is thinking.
My new startup is focusing on doing exactly this --- bringing together as many sources about engineers together as possible, and putting them all in one place. It's still very early, but I'd love HN's feedback. http://proovn.com
Because with a large codebase, you're not going to be particularly productive on the first day? I mean, it's better for web projects with a framework and set of conventions, but for, say, sizeable C++ applications it can be a serious hurdle.
