I asked this question to the Portland Ruby Brigade mailing list. Here’s what people had to say:
I have a short list that’s served me well over the years and can be summarized in a single sentence: they need to be able to think and communicate clearly and honestly about code (whether they wrote it or not) without getting tangled up in ego, pride, shame, etc. If you've got that, the rest is just details.
– Markus Roberts
I look less for skills, qualifications, and more soft-skills. Off the cuff:
Curiosity - are they genuinely interested in the work, in learning more about how code works, about solving puzzles? Do they hate loose ends in movies? Do they have a lot of interesting careers or hobbies in their background? I can teach skills, I can’t teach desire.
Authenticity - are they someone who feels genuine, someone I can trust? Are they a natural culture fit versus an assumed culture fit? Are they willing to do Important, Uninteresting work? (This is admittedly pretty biased. I’m still puzzling this one out.)
Fearless & Fun - Are they willing to make mistakes? What’s their approach to handling stress, or learning curves that look like a cliff? Do they just give up, or make an effort? I can teach techniques for learning, I can’t teach “not curling up in a ball at the first obstacle in their path”.
Empathy - are they collaborative, sharing individuals? Are they able to empathize, and see peers and coworkers as doing valuable work? Are they able to celebrate successes of others, or do they see the team as a zero-sum equation? I can teach pair programming, but I can’t teach how to not be a juice box.
– Kerri Miller, BlueBox
Same things I look for in anyone. I usually head straight to their GitHub. Are they opening issues, following projects, building an interesting gem, running through some koans, anything at all?
After that I’d probably check their Twitter. Do they even have a Twitter account? It’s totally cool if they don’t, but why? Are they talking with other devs, asking questions, following some interesting people or blogs, tweeting about stuff their working on. Those relationships and skills matter.
If we meet in person, then I’ll skip the “tell me all about yourself” part and just pair program. How do they take feedback? Do they make recommendations? Are they asking questions? Do I have to read their mind or can they communicate?
‘Junior dev’ is kind of silly because it doesn’t really mean anything. When does someone become non-junior? After 1 year? 2 years? 10 years? What matters most is they are excited, working on cool things, engaging with the community. Non of those have anything to do with experience IMO.
– Chris Hunt, GitHub
Just thought I would throw in a few things that I strongly consider:
1) understanding of diminishing returns
2) on a related front, understanding the code’s value or ROI for the larger business/client/project/whatever
In other words, code doesn’t exist in a vacuum. Even if you don’t know the specifics or fully understand a particular context, I think one should know that there’s almost always a context to consider.
I have worked w/ a lot of devs that see things in black-and-white, but most problems I work with have trade-offs; so understanding the context enables better decision-making.
On another front, I hate asking yes|no questions b/c I have been burned by candidates who had a different understanding of “yes”. So I usually ask people to talk about the limits/extremes of their knowledge or especially difficult obstacles they have overcome. If you can give students the opportunity to develop those stories, I’d recommend it.
I have heard of quite a few devs being asked “fencepost” questions, do fizzbuzz, or display your knowledge of some arcane bug/whatever. I’m not a big fan of it, but if students are looking for jobs they might have to jump through similar hoops–it doesn’t necessarily mean the actual job will be unpleasant.
– Tim Loudon, Loudon & Company