The Better Way to Recruit Tech Talent
Strategies that work and common mistakes that are easily avoided
by Joe Honton
Finding the best software developer for your team is not as difficult as some hiring managers make it out to be. The key is to understand what motivates software developers. And the answer, which may be surprising to some, has nothing to do with money.
Just for reference, let me share something I learned in 1985. At that time I was working for a Fortune 500 company with a job title of "Programmer". Every year the Personnel Department would administer a job satisfaction survey, with an eye towards helping management do a better job with hiring and retaining good employees.
Among the results there were always a few findings that had nothing to do with salary or career advancement. First was the desire for greater acknowledgement for the work being done. Programmers felt that managers didn't appreciate the difficulty of the work being performed — that is, they simply wanted respect.
Second, programmers were always keen to be given more opportunities to work on the "cool" stuff. They were unhappy with being overlooked as candidates for new projects and new technologies. Simply put, they were worried about being left behind, about being stuck maintaining software that someone else had written.
Third, programmers wanted to work on projects where managers listened to their concerns and worked actively toward improving things.
Here we are 35 years later and those same currents of dissatisfaction and desire are prevalent.
Hiring managers can tap into the software developer psyche by preparing job postings and interviews with these concerns in mind. Here are some strategies for attracting top talent, and some common mistakes that can be easily avoided.
Strategies that work
First, be specific and narrow. List the computer languages, software packages, hardware devices, and protocols that your company uses. This is the essential stuff that every candidate will scan before reading anything else.
But be careful not to over-specify. For example, your company may have adopted containerization and orchestration as a general deployment strategy, but adding experience with Docker and Kubernetes to the list of job requirements doesn't make sense for most of your job postings. You only need to add those to your DevOps job posting, not your front-end and back-end postings — everybody else can learn what they need to learn during the onboarding process.
Second, list responsibilities rather than duties. Duties are things like: attending daily Scrum, developing test modules, submitting pull requests, peer reviewing code, being on-call for critical bugs. Duties like these are assumed to be part of the job. They do not provide any information that candidates can use to distinguish your posting from all the others.
Responsibilities on the other hand portray a picture for the candidate about the importance of this role in the bigger picture. If this is an entry level job the responsibility might be refactoring the existing codebase to be more robust against failure. Or a senior position may have the responsibility to design and deliver usability enhancements to your flagship product. Or a startup role may have the responsibility to architect a system for resiliency and performance under varying peak loads.
The benefit to writing responsibilities this way is that you are providing a basis for stratifying candidates. This is much more effective than simply giving a job title. Everyone thinks that they are a "senior software engineer". But are they really? Can they identify and recommend the best tools for the task at hand? Can they estimate costs, identify risks, deliver on time and within budget? When these types of responsibilities are spelled out, interviewers and candidates will have an easier time distinguishing between imposters, bravado, and self-confidence based on experience.
Third, make it clear whether you're posting for a greenfield project or a legacy project. Neglecting this is a mistake. Most software developers will perform better at one or the other. A greenfield project requires a mindset that knows how to create something out of nothing without wandering amid all the possibilities. In other words, an ability to focus on deliverables. A legacy project requires a mindset that can take something apart and put it back together without breaking it. Thus, someone who is methodical.
Fourth, remove the "nice to have" job requirements. We know that software development requires lots of technical skills: regular communication, careful code management, cloud computing, project tracking, etc. In today's world almost every software developer will have these skills, or will quickly gain them on-the-job. Which tools your company uses is simply part of your corporate culture. These types of requirements don't help you find the best possible candidates:
- Communication: Agile versus Scrum.
- Code management: Github versus Gitlab versus Bitbucket.
- Cloud: AWS versus Azure versus Google Cloud.
- Project tracking: Axosoft versus Jira versus Hive.
This goes for all other tool-specific choices your company has made. Making a hiring decision because someone is already familiar with your particular tools is a poor idea. It ignores the benefit you stand to gain from someone who may know a better way to do things.
Common mistakes to avoid
First, look forward, not backward. When one of your current employees leaves, it's tempting to simply grab their old job description and reuse it. But this is a mistake because it doesn't account for all the progress that's been made or all the new enhancements that need to be worked on.
Second, don't rely heavily on testing as a filter. Asking applicants to spend hours of their time to develop an algorithmic solution to a puzzle will needlessly exclude some very good candidates. If the applicant's level of expertise is not obvious from their resume, ask them to point out something from their online portfolio or Github account that exemplifies their best work.
Third, drop all the clichés. Say what you mean.
- Instead of rock star say, "this job will challenge you to solve a wide variety of technical problems."
- Instead of team player say, "you will mentor and learn from your peers as you enhance the product."
- Instead of fast paced environment say, "we prototype and iterate often, so you will need to be adaptable in the face of new design decisions."
- Instead of good communication skills say, "must be able to provide constructive feedback when appropriate."
- Instead of multi-tasking say, "ideal candidates should be able to gracefully handle interruptions while still making progress on their assigned tasks."
Marketing lingo has no place in a job posting. Exciting startup and ground floor opportunity and other phrases like these should be rephrased to be in a neutral tone, or better yet, just omitted.
Also, avoid anything that resembles a reference to the ninja/geek/nerd/guru trope. Those titles may still be appropriate for bare-bones startups, but probably not. Today's candidates are savvy enough to recognize when they're being asked to do two jobs for the price of one. The best candidate for the job may be a young mother whose primary motivator is a proper work/life balance.
Finally, don't embarrass yourself by listing technical requirements that make no sense. For example, specifying that applicants must have a minimum of three years experience with a particular technology that's only been around for a year.
Expectations and qualifications
Remember, when job seekers read your posting they are looking for three things. 1) A place where they will get recognition and respect for their work. 2) A place where they can advance their skills by learning and using new tools and technologies. 3) A place where managers listen, and co-workers are easy to work with.
Use the first two of these to craft a job posting that will narrowly target qualified applicants. Then, when interviewing applicants, ask them what it really means to work within a team. Find out more about that here.
Most important, give prospective candidates the information they need to self-select. In other words don't try to reach every possible candidate. Instead try to target as few candidates as possible. When all of your applicants are fully qualified, you wont have a big pile of rejections to go through. "A few good candidates" should be your motto.
