It was once quite straightforward to recruit software engineers. As resume’s arrived HR sent them to the hiring Software Engineering Manager who forwarded them to senior software engineers. They scanned them for obvious yeas or nays. Yeas were called by HR for interview ASAP with the Software Engineering Team. If yeas were good, they got an offer and didn’t wait for a closing date before starting to interview. It wasn’t unusual from interview to verbal offer to be within 24 hours or the time between application and offer to be within one week. We rarely lost a great software engineer due to process. When somebody was right we closed the deal.
The world is covered by water. A fisherman’s job is to choose the best parts to cast that net. We can learn a lot from fisherman. The way we build and recruit our team is all determined by our chosen fishing grounds and the bait we use.
A complaint from HR today is there are too many applicants – and they have automated tracking systems (ATS) to make filtering easier. Applicants now work extremely hard to customize resumes for the ATS search algorithm. Before there were just as many software engineers looking for work and they had little customization to do to their resumes. They were read by software experts who understood them. We never had such a deluge of resumes even during hard times. Why is that? What did we do that was different?
Software engineering managers wrote well targeted job descriptions (JD’s) for a specific job title, function, and experience level which included a salary range – they used recognized descriptive terms. They selected who to invite for interview. Only software engineers with the majority of requirements and happy with the salary applied. It let software engineers know they were a good fit, and software engineering teams know only those who were likely good fits apply. That limited the resumes from 100’s to 10’s. We got to the ideal software engineers in one or two steps. Equally important software engineers could target the employers that wanted them and not waste time on employers with unclear JD’s.
Today’s JD’s are written by HR have fanciful non-standard job titles such as ninja and superhero. They are not what software engineers search on. The requirements cover every function and experience level in a software engineering department – and more. They also have no salary range. Now anyone with just a fraction of what is being asked applies – because they don’t really know what is wanted but it may be them. We have a deluge of mainly unsuitable resumes. HR use ATS to filter software engineers on non-software-engineering criteria to get resumes down to a manageable number. In that filtering we lose great software engineers. Often those who get through the ATS are unsuitable or if not decline when they discover the real JD and salary. The best drop through the net and ghosted – because they didn’t use the right customization to get through the ATS. It now takes many steps and much longer to find software engineers.
A carefully constructed JD targeting the specific software engineer we are after will encourage the correct person and no more to apply – and less steps in the interview process. Broad JD’s get a broad response and difficult to filter. The ATS could be used to much greater fruition if we only fed it suitable applicants.
I normally get JD’s between 20 and 30 lines – I have seen them 100’s of lines long. Here is what I use in a JD to keep it short and get who I need:
- Employer Name – links to employers’ site for more information, don’t put all the organization stuff in the JD as it hides the job.
- Location – Be specific. Using neighboring cities to attract applicants not wanting to travel wastes time.
- Job Description – use recognized descriptive terms and avoid internal, domain specific terms so you don’t have to describe them.
- Department (or job function)
- Job type (full time, part time etc.)
- Job Title
- Seniority level
- Seniority level reporting to:
- Salary range
- Qualifications and Skills – List only the hard and soft skills, languages, and technologies used and level of importance. Don’t add qualifications or skills that are a standard part of that job title and seniority level.
- Summary – project types, team size, culture, methodologies, main appeals of the job and what makes it unique. List any responsibilities and duties that are in addition to recognized job title and seniority level.
- Benefits – vacation, retirement savings etc.
Photo by Quang Nguyen Vinh from Pexels
