Hiring a Software Engineer? Look Out for These Resume Red Flags
Recently, I read Joel Spolsky’s book, Smart and Gets Things Done . It’s a book about hiring software engineers based on Joel’s experience running a successful software company. It’s an old book at this point, but this is the guy who founded Stack Overflow and Trello (among other things), so it is definitely still a good read.
One of the points Spolsky makes is that, when he was doing hiring at Microsoft, the company was looking for two things:
- Smart people
- People who get things done
You can have smart people who are very academic and spend lots of time on minute details but fail to deliver a working product. You can also have people who are very productive but deliver something that ends up not working because they just didn’t do quality work. Either way, you have a problem.
When it comes to building software, you need people who are both smart and capable of getting things done.
6 Red Flags to Watch For
I’m a software engineer, so I am writing this from the perspective of what scares me off from having somebody as a coworker. The last thing you want is to give a spot on your team to someone who will not help you ship your project on time.
These are a few red flags that I think indicate a candidate will fail the “smart and gets things done” test:
1. Super Long Resume With a Ridiculous Amount of Buzzwords Crammed In
When I was recently interviewing people for an open role, I saw a lot of six-page resumes crammed with buzzwords. I literally saw sentences with 20-30 terms in them.
If a candidate is rattling off jargon instead of describing the work they did at a given job, they are just trying to satisfy an applicant tracking system’s keyword filters. If they have to work so hard to get past the automated gatekeeper in a profession as in demand as software engineering, that in itself is a red flag!
Whenever I interviewed these people, they gave me boilerplate answers and their behavior felt coached. They had trouble providing real answers about technology, and it was easy to tell they lacked working experience with the relevant tech.
2. No Github, No Portfolio Site, No Web Presence (for a Front-End Developer)
To be clear, this only applies to front-end developers. A back-end developer without a website or major web presence is not a red flag because these developers are not typically working on the client side of a website. A front-end engineer would be.
When evaluating a front-end developer, you need to be able to see that they’ve produced a working website in the past. Front-end roles have become more complex over the years, demanding a strong understanding of JavaScript and skill with large frameworks like Angular and React. These developers also need the ability to create a website that looks good on every screen size you can throw at it.
For more expert recruiting insights, check out the latest issue of Recruiter.com Magazine:
3. Very Basic Skills and Technologies Listed on the Resume
When I see things like Microsoft Word, HTML, and JSON on a resume, I start to worry. Why is a software engineer talking about how good they are at using Microsoft Word? Or a basic technology for transferring data like JSON, which just about every application built in the last 10 years is using? Does it make sense for a web developer to list HTML — the foundational markup language for all websites — as a skill? No, probably not.
4. Claiming to Be Too Skilled in Too Many Programming Languages
Even if you have programmed professionally in 10 different programming languages, you should never write this on your resume.
Normally, software developers are working or primarily experienced in 2-3 key programming languages. If you list eight programming languages, that makes me wonder whether you are actually good with any of them. I think a good engineering resume should only list the technology a given candidate is best with and can answer in-depth questions about.
Even worse than listing eight programming languages is a chart or graph on which an engineer has ranked their skill level in several different languages all above 7/10. This is cute and looks nice, but it just invites criticism from engineers on the interview panel. For example, I started writing JavaScript code more than 10 years ago (it was the first language I learned) and have consistently worked with it professionally since then, and I’m not even sure I’d rate myself a 7/10 skill level.
5. Long Tenure at the Same Job With No Advancement
When I see the resume of a person who has been working at the same job with the same job title for 5-10 years, that signals to me their skills might be stagnant. For example, five years ago, React was basically unheard of. Now almost every company has some major application being rewritten in React. Missing that whole trend would really hinder an front-end engineer.
6. Lots of Extremely Short Full-Time Roles
I know that it’s generally understood that you want to see candidates with some longevity at previous positions, but in software engineering, it’s common for good candidates to switch jobs every year or two for a variety of reasons.
It’s also common to see people doing short contracting gigs in one-, three-, or six-month blocks. Some of the best-paying contracts in the industry are short-term in nature.
The only time you have a red flag is if you see lots of short-tenure full-time positions on someone’s resume. Is this candidate being let go during the probation period repeatedly? It’s something to double check.
—
Engineering resumes can be all over the place, and I wouldn’t rule a candidate out on their resume alone. That said, these red flags — especially when more than one appears on the same resume — can signal that the candidate you’re looking at won’t be the right fit.
Aaron Decker is a full-stack software engineer specializing in Node.js and React. He is building a video course over at iteachrecruiters.com to help train new technical recruiters in software engineering jargon.