Comments on: Two Rules for Hiring/Retaining Developers http://blog.calevans.com/2007/11/13/two-rules-for-hiringretaining-developers/ Lint I find in my mind's belly-button. Fri, 05 Dec 2008 08:35:11 +0000 http://wordpress.org/?v=2.6.3 By: mheart2 http://blog.calevans.com/2007/11/13/two-rules-for-hiringretaining-developers/#comment-45985 mheart2 Wed, 21 Nov 2007 07:36:11 +0000 http://blog.calevans.com/2007/11/13/two-rules-for-hiringretaining-developers/#comment-45985 General mistake of employers they query employees but say nothing about themselves. General mistake of employers they query employees but say nothing about themselves.

]]> By: Saptarshi http://blog.calevans.com/2007/11/13/two-rules-for-hiringretaining-developers/#comment-45879 Saptarshi Wed, 14 Nov 2007 18:55:05 +0000 http://blog.calevans.com/2007/11/13/two-rules-for-hiringretaining-developers/#comment-45879 Simple, yet important points to remember when hiring!! I have the same observations as you have... Your points are all the more important for startups as they can afford that developers leaving in the middle of tough times!! Simple, yet important points to remember when hiring!! I have the same observations as you have… Your points are all the more important for startups as they can afford that developers leaving in the middle of tough times!!

]]> By: Keith Casey http://blog.calevans.com/2007/11/13/two-rules-for-hiringretaining-developers/#comment-45873 Keith Casey Wed, 14 Nov 2007 15:09:35 +0000 http://blog.calevans.com/2007/11/13/two-rules-for-hiringretaining-developers/#comment-45873 @Rob - Good point and you're right, the third aspect isn't nearly as useful as the other two, but you can still glean a bit of information from it. When they're active, is it a bunch of little commits or is it a huge refactoring? When they're inactive are they completely out of the picture (radio silence)? Are their contributions all over the place in terms of areas of the code or are they focused in specific modules/etc? It's just further information to consider and evaluate. @Rob - Good point and you’re right, the third aspect isn’t nearly as useful as the other two, but you can still glean a bit of information from it. When they’re active, is it a bunch of little commits or is it a huge refactoring? When they’re inactive are they completely out of the picture (radio silence)? Are their contributions all over the place in terms of areas of the code or are they focused in specific modules/etc?

It’s just further information to consider and evaluate.

]]> By: Rob W http://blog.calevans.com/2007/11/13/two-rules-for-hiringretaining-developers/#comment-45868 Rob W Wed, 14 Nov 2007 11:56:30 +0000 http://blog.calevans.com/2007/11/13/two-rules-for-hiringretaining-developers/#comment-45868 @Keith Casey: Commit quality and forum participation is an obvious one -- but what conclusions do you draw from their activity patterns? "Consistently active" would suggest to me that they have a pretty basic day job with minimal "crunches" (which is possibly good luck for them but not always something they have control over), and probably just one "pet" project they contribute to regularly. "Bursty with long silences" could mean lots of things -- maybe they have poor time management skills, but also maybe their paid work is intermittent (they're independent, contracting/sub-contracting, etc.), maybe they approach open source work as a "scratch the itch then move on" type thing, or maybe their normal job has varying time demands based on release schedules, etc.. @Keith Casey: Commit quality and forum participation is an obvious one — but what conclusions do you draw from their activity patterns? “Consistently active” would suggest to me that they have a pretty basic day job with minimal “crunches” (which is possibly good luck for them but not always something they have control over), and probably just one “pet” project they contribute to regularly.

“Bursty with long silences” could mean lots of things — maybe they have poor time management skills, but also maybe their paid work is intermittent (they’re independent, contracting/sub-contracting, etc.), maybe they approach open source work as a “scratch the itch then move on” type thing, or maybe their normal job has varying time demands based on release schedules, etc..

]]> By: Keith Casey http://blog.calevans.com/2007/11/13/two-rules-for-hiringretaining-developers/#comment-45858 Keith Casey Wed, 14 Nov 2007 03:42:15 +0000 http://blog.calevans.com/2007/11/13/two-rules-for-hiringretaining-developers/#comment-45858 A few years ago, I started by recruiting from Open Source projects. Odds are you know of a few people with the right skills and you already have a relationship with them. Or if you don't, you can learn about them. Look at their commits - do they catch the subtle bugs or introduce them? Look at their forum/mailing list activity - are they a jackass? Are they helpful? Do they just give an answer or do they work to improve clarity? Look at their general activity patterns - are they consistently active or bursty with long silences? A few years ago, I started by recruiting from Open Source projects. Odds are you know of a few people with the right skills and you already have a relationship with them. Or if you don’t, you can learn about them.

Look at their commits - do they catch the subtle bugs or introduce them?

Look at their forum/mailing list activity - are they a jackass? Are they helpful? Do they just give an answer or do they work to improve clarity?

Look at their general activity patterns - are they consistently active or bursty with long silences?

]]>