6 ms·
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. I
by foz 12y ago
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.
- kelukelugames 12y agoWow, 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.
- rasur 12y agoLOL, been there, done that, and I work at the same place as foz :)
- bsder 12y ago> 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).
- jaggederest 12y agoI 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. [1]: http://contributors.rubyonrails.org/contributors/justin-george/commits http://contributors.rubyonrails.org/contributors/justin-geor...
- foz 12y agoI 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.
- rupert_murdaaa 12y ago> 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.
- jqm 12y agoI like this approach. It's pragmatic. After all, it's not what a person knows (nor who they know) that produces results. It's what they do.