In my organization, we start by looking at what the candidate has actually done. We ask for a github profile, and any side projects they might have worked on. If the CV and body of work look interesting, we go on to a phone screen - general questions, clarifying points on the CV, explaining the job, answering questions.
For the on-site interview, we ask candidates to bring their laptop. We advise them to use a typical, comfortable development environment. We've seen candidates struggle with the latest Ubuntu, installed that morning to impress us. So we don't want that.
During the hands-on interviews, we ask to see a side project, or any code they are mostly responsible for, and familiar with. We ask them to explain code, maybe change something, refactor a test, etc.
What we don't tell candidates is that this part of the interview is also about how they use their tools. It's important to see how good they are with their editor, command-line tools, can they type well, do they get easily distracted, and so on.
One of the most effective interviews we do is for project planning. A problem is explained in detail and the candidate is asked to design a solution. Not in code, but to talk it through in detail, drawing or writing docs/stories if needed. This phase helps show us how they break down a project, ask questions, negotiate features, and look for opportunities to reduce complexity. Bonus points for making a pen-and-paper wireframe or throwaway prototype.
What we refuse to do is the "puzzle" problems, whiteboard code (which makes no sense), or tricky technical questions. We instead want to find people that use best practices, don't re-invent the wheel, tackle problems pragmatically, and are good with their tools.
Over time, this approach seems to work well. However, we also discovered that we have to re-train and test our own interviewers. Without that step, the process can change unexpectedly, become inconsistent, or unfair. Don't just assume your staff is interviewing well - take time to check it out and help them get better.
> In my organization, we start by looking at what the candidate has actually done. We ask for a github profile, and any side projects they might have worked on.
Fail. You just killed the quality of your pool.
You've just negatively screened against people with a life (experienced, 30+ years old, generally with a family) and screened for people with no life (aka single, male 20-somethings).
For an example, if John Carmack hadn't been able to release his employers source code (like many people), your process would screen him out (no github or side project presence).
> You've just negatively screened against people with a life
That kind of works both ways, though, doesn't it? As a 30 year old developer with a family, I don't want to waste time interviewing somewhere that has the expectation I'll work outrageous hours. If I get filtered out early in that process because I'm not involved in multiple OSS projects or whatever, all the better for me.
That being said, resumes are a really shitty way to get an idea of someone's experience and talent. If I'm hiring someone and they can show me a github profile or blog entries or a Stack Exchange profile or slides from a local user group presentation or anything besides their resume, it really helps me get to know them better, and -- all else being equal -- will probably set them apart.
I agree with this. I'm a reasonable example - I've spent the last year working on relatively internal applications that don't show up in github (only the most recent year is shown there for some reason). I've also contributed to Rails[1], Rubygems, and a bunch of other projects.
I hope you would promote your contributions when applying for a job, it definitely makes a difference. Looking at a public profile is not everything, you're right.
There are plenty of 30+ developers with families in our organization, and all of them have projects, hacks, or ideas of their own. I would argue that this is part of the culture we have. If someone comes to an interview and can't show any past code at all, that's a worrying sign.
On the other hand, we've also hired people that have not much happening with their public github profile. We still ask to see code they might have worked on (job-related). If they can't show that, we try to have them pair with us on something simple. We have hired people in this situation, but I'm sure we've missed others that may have worked out.
If a young Carmack came through our interview process, I'm pretty sure our team would recognize his talents when asking him to go through someone else's code.
Wow, this is my worst nightmare. I freeze anytime a co worker is near my desk because I worry they will judge how I type and get around the IDE. Of course that just makes the vicious cycle worse.
For the on-site interview, we ask candidates to bring their laptop. We advise them to use a typical, comfortable development environment. We've seen candidates struggle with the latest Ubuntu, installed that morning to impress us. So we don't want that.
During the hands-on interviews, we ask to see a side project, or any code they are mostly responsible for, and familiar with. We ask them to explain code, maybe change something, refactor a test, etc.
What we don't tell candidates is that this part of the interview is also about how they use their tools. It's important to see how good they are with their editor, command-line tools, can they type well, do they get easily distracted, and so on.
One of the most effective interviews we do is for project planning. A problem is explained in detail and the candidate is asked to design a solution. Not in code, but to talk it through in detail, drawing or writing docs/stories if needed. This phase helps show us how they break down a project, ask questions, negotiate features, and look for opportunities to reduce complexity. Bonus points for making a pen-and-paper wireframe or throwaway prototype.
What we refuse to do is the "puzzle" problems, whiteboard code (which makes no sense), or tricky technical questions. We instead want to find people that use best practices, don't re-invent the wheel, tackle problems pragmatically, and are good with their tools.
Over time, this approach seems to work well. However, we also discovered that we have to re-train and test our own interviewers. Without that step, the process can change unexpectedly, become inconsistent, or unfair. Don't just assume your staff is interviewing well - take time to check it out and help them get better.