I’m a Software Engineer with two years experience. I was recently laid off with about 20 other engineers with varying years of experience, all of us extremely talented. On the job hunt recruiters have all been telling us how to format our resume’s, cover letters, and profiles to get noticed. After searching through hundreds of job posts it’s become apparent to many of us that no one is telling recruiters what they should be doing to fill their positions faster. After all, the longer a position stays open the more it costs the company and the worse it looks on the recruiter. I have noticed some odd and sometimes shocking job posts on my hunt. To help recruiters fill their job posts faster, and with the right candidate, I decided to put together a short list of 5 red flags that recruiters should avoid in their Software Engineer posts if they want to hire top talent more quickly.
Not Titling The Position Accurately
This should be a no brainer, but it’s unfortunately very frequent. I’d say at least 1 out of every 5 posts I see has an issue between the title and the body of the post. If the position title is for a “Software Engineer” and the body of the post is asking for a senior software engineer, either you copy pasted the job post and didn’t proof read it or you titled the post incorrectly. Either way, you’re confusing job applicants and you’re going to be flooded with applications that don’t fit the role, elongating the time it takes you to fill the position.
Perhaps the most egregious example of this I saw was for a “JR/SR Software Engineer” position. I asked myself which position as are you filling the JR or SR? If in the body of the post you’re asking for 7 years of experience, then JR shouldn’t be in the title. If you want to hire for 2 positions with 1 job post, remove the years of experience requirement and focus on the qualities and skills that you want from a JR or SR Engineer like eagerness to collaborate, willingness to learn and/or mentor, etc. Otherwise you’re not likely to fill both positions and you’ll be lucky to fill one.
Not Knowing How Many Years Of Experience The Position Can Afford
A lot of these job posts ask for Engineers with 7+ to 10+ years of experience. Engineers with that much experience are going to be Staff Engineers, Architects, Managers, or something that pays close to 200K annually if not more. If the position pays 120k-160k then you are looking for someone with 2-5 years of experience. If you can only afford to pay 80K -100K you shouldn’t be requiring more than 2 years of experience.
It pays to research the salary requirements of your position to see how many years of experience the position can actually afford instead of trying to force engineers to accept pay that’s less than what they’re worth. Forcing engineers to take lower pay will ensure the position, if filled, won’t stay filled for long. It’s better to make an offer for what you can afford instead of haggling for what you can’t.
Not Googling A Skill Or Language’s Age
In the world of modern Software Engineering there are a lot of frameworks and libraries that are still pretty new. When you ask for a React Engineer with 10 years of experience you’re telling me that first you don’t know anything about React, and second you don’t know how to value a React Engineer.
React was invented in 2013 which means an engineer with 10 years of React experience is in a group of maybe a hundred or so people. Someone with that many years of React experience may not have stayed up to date with React as it’s gone through a few iterations since then. For instance, someone with 10 years of experience in React may not code anymore since they’re likely at a managerial level at this stage in their career. They may still be building with Class based components which isn’t the modern way to write React. Do you want someone with 10 years of experience? Or would you prefer someone who is experienced but is also up to date on the latest React features? I was surprised to learn how many job posts favor years of experience over functional up to date knowledge.
Requiring Any Physical Capabilities At All
Software engineering is one of the few jobs that people with motor or other disabilities can do to participate fully in society. Coding doesn’t really require any physical capability at all. Computers and assistive technology offer many disabled people with the means to contribute meaningfully to the world around them. This is why Web Accessibility Content Guidelines( aka WCAG) matters and why many Engineers are dedicated to making the web accessible for all.
Recently there was a job post that required an engineer to be able to walk or run for 4 miles per day. If this post wasn’t specifically written to discriminate against disabled people it doesn’t really matter because in the end that’s exactly what it does. Any self respecting engineer would swipe right past this job post because the requirements make no sense. Beyond the ethical concerns of a job post like this, generally, Software Engineers are smart enough to know that flouting the noncompliance to federal regulations so blatantly means this company is likely to be sued out of existence, and is therefore not a stable career opportunity.
Using The Term “10-X” Anywhere In The Post
Using the term 10-x anywhere in a job post should be avoided. Employers might think a 10x developer is a good thing. They might think a 10x developer will save them money because they’ll do the job of 10 developers. Those employers would be dead wrong. If you ever hear a group of engineers talking about someone as a “10x developer” it’s not a compliment.
10x developers are known in the business to be impossible to work with. They don’t write code that other developers can work with meaning when they leave the company you’ll have code you’ll never be able to debug or patch. They don’t take criticism well meaning their code won’t improve so the bugs will just get more plentiful. 10x developers also they think they can automate human positions that should actually be done by humans. Unit testing cannot, and should not, take the place of Quality Assurance. A real person is needed to test the quality of your product and a unit test is only as good as the developer who writes it.
If you want a good developer that will save you money then you want a staff engineer that is collaborative, humble, and always willing to teach AND learn. That’s what will ultimately save your company money and make your company money in the long run.