1. The big job boards like Monster and Dice have become practically useless for hiring top tier talent.
It is easy to quickly obtain a pile of resumes using these services. However, this approach will have you shucking a heck of a lot of oysters to find a truly great Perl programmer. Several professional recruiters I know have given up on these boards except for staffing entry level positions like help-desk and phone support jobs. The odds of finding the proverbial rock star programmer on Monster are growing increasingly slim.
2. Niche job boards will get you qualified leads, but not very many of them.
High-end job boards like TheLadders charge a fee to the candidates and are as much a den of recruiters as the mainstream sites. I find it hard to believe that top-tier talent is likely to pay to be listed on a job board.
Caveat: I have not personally used TheLadders as part of my recruiting efforts, but did briefly have a subscription as a candidate.
The really niche job boards like the one at JoelOnSoftware do a good job at pre-qualifying the candidates through self-selection, but maybe too much so. I’ve listed a few jobs on this site for opportunities in Austin that generated almost no response. I suspect this is a better tool if you are in a bigger market like NYC or the silicon valley.
Actually Joel’s board does have a compelling strategy to draw higher quality candidates:
- Trim back recruiter nonsense by forcing the advertiser to disclose in the ad who the candidate would actually be working for.
- Asking advertisers to post their Joel’s Test score. Candidates who care about this are more likely to be passionate about their craft.
Despite my limited success with it, I’d still recommend the site given that there really is no financial risk. I can personally attest to Joel’s “If it doesn’t work, you don’t pay” guarantee. We got our money back promptly with no hassle when the listing didn’t net any interview-worthy candidates.
3. Use LinkedIn Strategically
I have it on good authority that LinkedIn is a pretty strong source of candidates who are only passively looking and currently employed, which are generally traits of the better candidates. However, programmers don’t seem to frequent the job board on this site as much as sales and management types.
That said, I can’t really vouch for its job board when looking for developers based on my experience. However, never before have you had such unprecedented access to the innards of another company’s org chart as LinkedIn provides. A few quick searches containing the name of other companies in your industry will usually reveal developers with relevant experience in your industry. This site is also used as a stealth way of looking for another job for people who don’t want their employer to catch them on a job board.
I was just NETWORKING, I promise!
4. The best candidates aren’t going to come to you.
There are exceptions to this, but I’m betting that you wouldn’t have read this far if you are recruiting within a company that the best programmers already yearn to work for. This advice is for the rest of us who don’t have the luxury of offering a job that would be a showstopper on a resume or turn heads at RenFest / Comic-Con.
Some managers, especially new ones, whose only experience with recruiting has been as a candidate desperately seeking an audience with a choice company, have the impression that their role as a hiring manager is akin to sitting atop a throne as candidates compete for their favor. Not exactly.
There is a pool of candidates who are going to come to you, and their names will quickly become familiar because they will apply to every job posting you open even over several years. In most cases, there is a reason that someone else hasn’t snapped up these people and absent evidence to the contrary you probably don’t want to hire them either. If you aren’t willing to be proactive in your search and sometimes take on a more subservient posture when dealing with candidates, you are eventually going to force yourself to choose from this pool.
The top guns may only hit the open job market once in their careers, and from that point forward get subsequent jobs through networking, which brings me to my next point.
5. Networking is as essential for you as it is for the candidate.
Networking as a job-hunting strategy is a no-brainer, right? So what are you doing to make sure you are on the other end of that network for the right candidate?
Your existing team of developers is often a great entry point into a pretty substantial network of developers. Referral bonuses are the tried and true way to enlist employee help with the recruiting process, but often the prospect of working with a favored peer is a more powerful motivator.
Other benefits of this approach include:
- The person who made the referral will to be invested in the success of the employee and likely will take an active role in bringing the new person up to speed.
- Barriers to acceptance into the team will be reduced because the new person already has a relationship with at least one person.
- You are more likely to get a true picture of what you are getting with the candidate without as much puffery as you might get interviewing strangers.
Warning: This doesn’t work so well with the mediocre programmers. The best developers try to hang with people smarter than themselves. Mediocre ones will seek out people to make them feel smarter. Don’t hire the wing-men.
6. Focus your search on finding developers, not job hunters.
Employers are going to hang on to their best people and keep them away from recruiters, recruiting events, and by extension you.
I’m not trying to imply that their bosses are actively prohibiting them from these types of contacts, but rather that they work hard to keep them happy and busy enough to not even try.
Developer conferences and user groups are a great way to contact engaged developers who may not be actively looking for work. They even triage themselves into sessions so you can more readily identify them by their area of expertise.
The best emissary to send to such an event is a development manager or supervisor. HR types are going to scare away the fish by being too sales-y and saying things like “Do you know Sea Pound?” and many programmers tend to be too introverted to make a lot of contacts.
I’ve a friend who recounted a tactic that had worked well at these events for him. He wore a t-shirt to the conference that read: “I’m hiring developers.”
7. Programming competitions
If you need a lot of developers and want them to triage themselves by skill AND aptitude, you might try sponsoring a programming competition. I’ve no personal experience with this approach, but I’ve seen a number of companies try it.
It definitely sounds good, but be careful to understand what you are looking for. These competitions seem to appeal to people who love puzzles, and those are types of programmers can often exhibit a pathology where they like tinkering and optimizing at the expense of getting a good-enough solution out the door.
8. Don’t expect to pay median salaries for top talent.
Often I see companies that claim to hire only the best, but their HR people argue that they should only have to pay the median salary as determined by salary surveys. Try that argument at a jeweler or sports car dealership and let me know how that works out.
How can you charge $200K for that diamond necklace when I can prove that the average piece of jewelry retails for $150?
If you want the top 10% of developers, you should expect to pay at least in the top 25 percentile, and you are only going to get off that cheap if you bring something else to the table like a cool product to work on, good benefits, private offices, or some other perk.
9. Get the muggles out of the process as early as possible.
If at all possible, don’t force the candidates to endure even a phone interview with a non-technical person. If you can’t avoid it, at least strip out any technical questions from the interview script that the person performing the interview doesn’t understand well enough to talk about competently.
Let HR/Recruiters manage the scheduling, resume screening, benefits discussions, etc. , but don’t give them a phone interview script with technical questions and let them lose on the candidate.
10. Be flexible with your requirements.
If you need a .NET developer, don’t be a stickler for C# or VB.NET. The best programmers can become quickly proficient in just about any language, make sure that the person screening resumes understands what keywords are acceptable substitutes for the ones in the job description.
11. Branding is not just for cattle and marketing.
Branding is the act of creating and maintaining a positive image to grease the skids for selling people on your team or company. It is often confused with advertising, but it is a distinctly different animal. Branding is about managing your reputation and advertising is just one means to that end.
Creating an identity for your team that is attractive to potential recruits not only helps with sourcing candidates, but also adds ballast to your side of salary negotiations.
Brand characteristics that resonate with developers:
- We have and hire the best developers – Top developers want to work with other top developers.
- We work on cool products that your friends and family will be familiar with.
- Our company is a meritocracy that values technical know-how above politics.
- Our team keeps up with the latest technology and invests in training for developers.
Some techniques for advertising and reinforcing your brand:
- Sponsoring developer conferences and events
- Developer Oriented User Groups – Often you can get a plug on the cheap by buying the pizza or contributing a few give-away items like t-shirts or books.
- Support Open Source Projects under the name of the company.
- Offer unusual perks that appeal to programmers and then submit a press release about it to local media outlets.
12. Understand your needs and recruit for that.
This seems too obvious to mention, but is probably the easiest mistake to make. Clearly define what you expect the new hire to do every day and hire someone that can do that job every day and enjoy it.
Some guidance in this area:
- Don’t hire based on interviewing skills unless you need a sales guy.
- Don’t hire based on management skills unless there is potential for them to lead or manage in the near term.
- Don’t hire a clone of yourself or your best employee, you already have that. Hire someone that complements what you already have.
- Hire for what you need NOW, not what you think you will need later.
13. Ignore your instincts during the interview
Your tendency during an interview is to form an opinion quickly at the start. Your mind is wired to preserve its own worldview and will often fight against all evidence to protect that initial judgment.
To remain objective and overcome jumping to conclusions, consciously decide to go harder on the people you like and easier on the ones you don’t. Otherwise you will be inclined to do the opposite and just reinforce a your initial impressions and waste a chance to learn more about the person in front of you.
14. Trust your instincts when making the final hiring decision
Trust your gut whenever you are the slightest bit uneasy. At my own peril I have several times learned the hard way that losing a good candidate is far preferable to hiring a bad one. For the dozens of people I have hired in my career, there have been a number of people I was sure would be great and turned out to be just so-so, but I have never hired someone that I was unsure about that turned out to be a great employee.
At each step of the process separate your candidates into two piles:
Yes: From what I know so far, I could hire this person without reservation.
No: Everyone that doesn’t pass the criteria for the yes pile. Includes anyone who is a “Maybe” or a “Yes, but…”
15. Just say no to puzzle problems.
First, see item 7 about the problem with logic puzzles.
Second, these things tend to annoy really good programmers who don’t like make-work or meta problems.
Don’t kid yourself that “you just want to see how they think.” Knowing that someone can come up with a clever way to estimate the number of boat trips required to determine which switch turns off Mt. Fuji is fun conversation, but a waste of everyone’s time.
Alternative approaches to evaluating a candidate:
- Rough-out an application architecture on the white-board for this scenario.
- Role-play with them a troubleshooting scenario for a challenging problem you have worked through.
- Get code samples.
- Ask them to describe an application they have built and ask probing questions to make sure you understand their level of contribution to that project.
16. Write an interview script and test it on your current team
Write interview scripts (for each job title/level) and keep your notes for each candidate.
Good reasons to use standardized interview script
- Less room for ad-hoc questions helps you avoid favoritism (see #13).
- Documentation of equal treatment of candidates to defend against potential hiring discrimination claims.
- Easier apples-to-apples comparison of candidates..
Tips for refining your interview script
- Test it on current employees – Did it draw out the important positive and negative aspects of that employee? Tweak it until it does.
- Get current employee feedback on the script – Any offensive/insulting questions? Do they think it would help or hurt the perception of the company for the interviewee?
- Review your interview notes one year after the hire. Were there any surprises? Tweak the script to prevent similar surprises next time.
- Review your script for and remove questions that require specialized knowledge that only a current employee would have.
17. Don’t leave people hanging.
If your company’s recruiting process is interminably slow and out of your control, take it upon yourself to call your short-list candidates and frequently re-assure them that things are progressing. The best developers are going to be highly recruited. Don’t assume that just because someone submits a resume that they are somehow locked-in and will be forced to give you first right of refusal.
I’ve heard and been part of stories of companies calling back EIGHT MONTHS after a resume was submitted to ask for an interview. This is crazy. Even if by some miracle that person was still on the market after that long, clearly they have been passed over by just about everyone else in the interim. Why would you even want them after so much time has passed?
18. Recruit former employees
Face it, your top people get recruited heavily and eventually will jump ship to see if the grass is greener, even if it isn’t.
Good employees that have left your team in are a great source of new hires for several reasons:
- You know what you are getting and so do they.
- Previous employees can become productive much more quickly.
- You can recoup some of your previous training investment.
Even if you can’t convince them to come back, the fact that you want them back is an ego boost for them and will often create some goodwill and improve your branding by creating an advocate that works with a lot of other developers who you might be interested in recruiting.
Some preemptive steps to increase your odds of re-hiring a good employee later:
- Give them a final chance to give honest feedback about the aspects of the job they didn’t like and communicate your desire to fix those things for the rest of the team.
- Organize a happy hour and give them a great send-off.
- Give them a souvenir of their employment to take with them that will remind them of their friends at the job.
- Keep in touch, and not just when you need something.
- Call to ask how their new job is going and solicit advice on things they like about the new job that you could try.
- Continue to make sure they are invited to happy hours to keep the ties with their former co-workers strong.
I have re-hired several employees during my career as a software development manager who have turned out to be some of the best programmers on the team.
19. Mind your karma and don’t make enemies
Don’t be an ass when developers leave the company, whatever the circumstances. It doesn’t matter if you never want to see this person darken your doorstep again. Also, treat every candidate who took the time to apply with respect, even if they were completely unqualified. Word of mouth is a powerful thing and this industry isn’t as big as you might think. Chances are that these people will talk to someone about your company that you one day will want as an employee or customer.
Filed under: Managing Software Development, The Recruiting Process | Tagged: recruiting, technical |
Improving Software 
Your links are broken, if I use the middle button to click them, they open in the same window.
Can you give me an example of a link that is broken? I went through and clicked them all and they seem to be working correctly.
The Snapshots javascript preview breaks typical mouse-use behavior. Middle-click typically opens the linked page in a new browser tab. However, middle-clicking on the links is trapped in an “on-click” event for the javascript and is submitted in the current page. This means that any attempt to open up interesting links in a new tab in order to read them once they are done reading this page is impossible. What was previously an “open to review later” action becomes an interruption of reading the article.
(Note that I know this is related to the Snapshot previews because I ran across the issue elsewhere earlier this week and spent a significant amount of time investigating)
Thanks for the heads up on that, but there isn’t much I can do about that. The blogging software I use automatically creates those snapshot previews.
akin to “Ask them to describe an application they have built and their contribution, ask probing questions about it.” I ask them to talk about a problem they’ve solved recently. Or something they’ve written. Anything. What I’m looking for is that point where their eyes light up, and they proudly describe something. It can be a great way to make them feel more comfortable, and show their technical depth on their own terms rather than my boilerplate.
I use that one too. Like you said, it is a good lead in question to the technical part of the interview because it lets them shake of some nervousness since they are usually prepared for that one. It also seems to identify programmers who have only done maintenance work or report building and have yet to have a project that they actually felt a sense of ownership of.
Also encourage them to go outside work. If their previous job didn’t give them any sense of ownership, perhaps they’ve coded a sliced break iPhone app.
Very nice. As a matter of policy, I won’t apply to places which are heavily into puzzle questions. I also won’t talk to a recruiter who won’t tell me where I’m going to work.
My cousin (also a programmer) once decided to be nice and spent an hour on the phone teaching a recruiter the differences between Java, SQL, JavaScript, etc. To many recruiters, these are just buzz-words.
Your #8 touches on another annoyance. I understand someone may want to know your current salary as a reality check. Far too many companies try putting people into some sort of caste system. They feel that a BS degree=X salary. They feel that 10% above your current salary is the target salary. They fail however to take into account all sorts of things like cost of living, etc. Many have no concept of the fact that *good* programmers often take a job that doesn’t pay well to work on something awesome. When you then want to move on, they place you in the ‘lower pay’ caste. I will say that small companies are less likely to do this though.
#10 is the big one. Too many companies expect people to be exact pluggable components. If someone knows Python well, likely they’ll pick up Ruby. I think this more than anything prevents companies from getting good people. It also prevents companies from picking good technologies.
Very nice list.
Thank you, thank you, thank you for #15. I can only hope that people read it, learn it, love it and live it. There’s nothing worse than this kind of question in an interview, and I think that this should be extended into most programming problems too. All to often you get questions like, “Can you write a Fibonacci number generator”. Yep, sure can, but when was the last time anyone had to write a Fibonacci number generator that wasn’t in college or an interview? Ask me something useful.
Trivial programming exercises are not mindbenders. It shouldn’t take more than a minute or two to write a string reverser, a factorial or fibonacci calculator. It’s a reality check, and the fact that at least half of the otherwise apparently fully qualified superstar candidates can’t write a simple program that would take the worst of programmers 10 lines and 15 minutes is deeply telling and useful.
So sorry that you can’t write a fibonacci generator, but you are a no hire. Bye!
This is a really good article.
Have you given any thoughts to Recruitments during this recession time? I’ve been hard pressed to find good resources, and judging from this article I’m guessing you may have something valuable to say. Thanks in advance!
I don’t understand exactly what you are asking, but assuming you want to know if these strategies would change during a recession…
Honestly, that is tough to say. I haven’t tested most of these strategies since things went sour with the economy. Like just about everyone else, I’m not doing much hiring these days.
[…] 19 Tips for Recruiting Great Developers 1. The big job boards like Monster and Dice have become practically useless for hiring top tier talent. It is easy to […] […]
“Get code samples of previous work.”
Are you joking? Steal source code from the last employer to show it to the next one???
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.
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.
great advice on the blog!
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.
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.
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.
Hello from Russia!
Can I quote a post in your blog with the link to you?
Go right ahead.
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.
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.
As a full-stack web engineer working with Rails, I sometimes want to educate recruiters sending cold emails about C++ positions. Looking at my Github profile would give them hints!
That’s why I may build this: http://githubprofilesforrecruiters.launchrock.com/ if people are really interested in it! (This is call Customer Development ;))
if I may add one point – evaluate candidates with programming test before inviting them to the interview.
don’t know how to test them or don’t have the time to make a test. well, there are some online solutions that do that for you for a small fee. one such is testdome.com
they have c# and java tests at the moment
and you probably heard of codility.com