Comments on: 19 Tips for Recruiting Great Developers http://improvingsoftware.com/2009/09/29/19-tips-for-recruiting-great-developers/ Upgrading the software development process one reader at a time. Tue, 01 May 2012 06:08:29 +0000 hourly 1 http://wordpress.com/ By: Rachel http://improvingsoftware.com/2009/09/29/19-tips-for-recruiting-great-developers/#comment-673 Sat, 01 May 2010 15:08:16 +0000 http://improvingsoftware.com/?p=1291#comment-673 An excellent article. As a developer that’s been on both sides of the hiring table over a 20 year career, much of it resonates, particularly the importance of sending all candidates away with a good feeling about your company, even if they don’t meet your requirements this time around. Inevitably, people you don’t need at the current time *will* know someone you will want to hire at some point, or they themselves may have the right qualities for a job that you’re interviewing for some time in the future. If you treat people that don’t meet your present needs badly the first time they experience your recruitment process, you can kiss them goodbye when you decide that you do need them for a referral or another post further down the line. Similarly, whenever developers are leaving, I always take them into a private room, tell them how sorry I am that they’re leaving, wish them the very best in the next step in their career, then give them my phone number and ask them to get in touch if they’re ever looking for work again; I call it the ‘golden ticket’ approach to saying goodbye. By taking that approach, not only do you have a ready-vetted stream of developers *calling you* in years to come, but whether you do or don’t have a job available when and if such departing employees call, you’ll be sending them away as a personal advocate of your employment brand, and telling other developers how good a manager you are personally to work for. Each of those benefits makes recruiting other good developers that much easier; there’s nothing like a personal recommendation from an otherwise uninvolved party to seal the deal when it comes to recruiting good people.

The point that had me nodding the most in relation to my personal experience as a candidate was number 9. On the candidate’s side of the table, there’s nothing more painful than being quizzed on your technical ability by someone that doesn’t have a hope of understanding the answers to the questions they’re asking. The most egregious example of this that I’ve encountered was a person that was interviewing me for a contract role their company had advertised around 2002. This person wasn’t the hiring manager, a technical members of staff, or even an HR professional at the firm that had advertised the role; they were just an ordinary employee within the department that the position was being recruited for, and they had a list of questions that had been written by an apparently-technical member of staff who was “on holiday” that day. The first question he asked me was:

“What is the most important piece of code in a system?”

…and then looked at me like that question made any kind of sense whatsoever. Which system are we talking about? What is the context? When I asked these questions, he said:

“Sorry, no. The answer I have here is ‘error checking’ ”

-?????? Painful doesn’t quite cover it, does it? And now for a question about cooking – ‘what is the most important flavour in a dish? – No, I’m sorry, the answer I have here is ‘chicken’ ’. ‘But that’s not even a flav…’, ‘…I’m sorry, that’s what I have here!!!’ Hmmm. Save the technical questions for people that are competent enough to know what the questions, and the answers anticipated, actually mean. Without the context and understanding intended by the original articulator, most technical questions merely become meaningless sounds when voiced by an unskilled interviewer. All such questions asked by an non-technical interviewer do is tell the candidate you’re a company they really don’t want to work with. If you want to question a candidate’s technical ability in the first interview (and I recommend that companies do), show them some respect by making sure that there’s someone in attendance on your side of the table who can understand the answers.

]]> By: Koen Roozen http://improvingsoftware.com/2009/09/29/19-tips-for-recruiting-great-developers/#comment-671 Wed, 21 Apr 2010 22:32:43 +0000 http://improvingsoftware.com/?p=1291#comment-671 Wow, thanks great tips & tricks for a recruiter. I’m experienced recruiter but new in recruiting developers. Especially the tip of a contest is helpful. Thanks.

]]> By: johnfx http://improvingsoftware.com/2009/09/29/19-tips-for-recruiting-great-developers/#comment-445 Sun, 18 Oct 2009 03:59:38 +0000 http://improvingsoftware.com/?p=1291#comment-445 Go right ahead.

]]> By: Polprav http://improvingsoftware.com/2009/09/29/19-tips-for-recruiting-great-developers/#comment-441 Fri, 16 Oct 2009 22:15:50 +0000 http://improvingsoftware.com/?p=1291#comment-441 Hello from Russia!
Can I quote a post in your blog with the link to you?

]]> By: Phaoloo http://improvingsoftware.com/2009/09/29/19-tips-for-recruiting-great-developers/#comment-404 Sun, 04 Oct 2009 11:02:27 +0000 http://improvingsoftware.com/?p=1291#comment-404 Great tips. Agree with the point 10, developers who are called ‘great’ must have the skill to switch to a different programming language or a new flatform with ease and quickly.

]]> By: Paul Tomblin http://improvingsoftware.com/2009/09/29/19-tips-for-recruiting-great-developers/#comment-398 Fri, 02 Oct 2009 02:17:59 +0000 http://improvingsoftware.com/?p=1291#comment-398 If you want to see what a programmer really is passionate about, ask them about their side project. (And yes, every decent developer has a side project or two.) Sometimes work is just a paycheck, but the side project is the one where you call your own shots and deal with what you want to deal with.

]]> By: Greg http://improvingsoftware.com/2009/09/29/19-tips-for-recruiting-great-developers/#comment-397 Fri, 02 Oct 2009 00:56:20 +0000 http://improvingsoftware.com/?p=1291#comment-397 Great article! I will be using knowledge from this article and it has helped me look at hiring in a new light and I like it. Thanks again.

]]> By: Erik http://improvingsoftware.com/2009/09/29/19-tips-for-recruiting-great-developers/#comment-396 Thu, 01 Oct 2009 23:29:36 +0000 http://improvingsoftware.com/?p=1291#comment-396 Not necessarily stolen, but any sane employer will let his employees sign a work contract that prevents them from showing company internals around to to get another job. Except for Open Source of course.

]]> By: garbagegirl http://improvingsoftware.com/2009/09/29/19-tips-for-recruiting-great-developers/#comment-395 Thu, 01 Oct 2009 19:05:04 +0000 http://improvingsoftware.com/?p=1291#comment-395 great advice on the blog!

]]> By: johnfx http://improvingsoftware.com/2009/09/29/19-tips-for-recruiting-great-developers/#comment-394 Thu, 01 Oct 2009 14:57:48 +0000 http://improvingsoftware.com/?p=1291#comment-394 Previous work is not necessarily stolen code from a previous employer. The article assumes that the candidate and the recruiter demonstrate professional ethics during the recruiting process and are respecting any intellectual property rights involved.

]]>