Red Flags in Engineering Resumes

Engineering resumes are often filled with a sea of buzzwords, embellishments, and too often outright fabrications. An insatiable demand for talented engineers creates a beggars can’t be choosers dynamic, wherein recruiters and interviewers are forced to lower their standards for a phone interview candidate, or they have difficulty separating the charlatans from the real deal. As with all funnels, it’s desirable to spend the greatest vetting effort earlier on in the process, where the overall cost of filtering is cheapest, and this my friends brings us to the humble resume.

Let’s face it, most people hate writing or updating their resume. It’s a chore, it’s not engineering, and is just a means to getting or facilitating an interview. It’s also often the first impression given to a potential employer. You generally wouldn’t show up to an in-person interview in your underwear and unshowered, so why would you present a shoddy or disingenuous resume?

Here’s a list of red flags I’ve seen over and over in resumes over the years, and what this tells me about a candidate. Let’s be clear, there’s a difference between not having great resume-writing skills, and not giving a shit how a resume makes you look. Clarity and brevity are hard. No, these red flags transcend style, they are manifestly bad signs that do not bode well for how a candidate will perform in a technical interview, or on the job.

X years of experience in vague technology category

A well-written resume tends to include previous jobs, technologies used, and tasks performed. This is generally enough to get a sense of what someone has done, at least enough to grant a phone interview. Anyone who feels the need to throw a number of years of some kind of experience is throwing up a smoke screen to try to make themselves appear grand, where a closer inspection will reveal that, despite those number of years doing something, not much was learned.

In a phone interview, this is an invitation to be asked deep and complex questions about the given topic. In my experience, candidates almost universally fall apart here. It’s a shame, all they had to do was not include this statement in their resume, but since the resume is all there is to go on at first, this first impression means they think this is really important and true. Well, consider the bluff called, every, single, time.

List of skills disorganized, giant blob list, used for padding

A wall of buzzwords may come up in a filter from recruiters, but an actual engineer will balk at a wall of garbage cobbled together. This says “I can’t even be bothered to highlight my real, current skills for you, but hey, you need me more than I need you right?” Not really, no. Just because there’s more demand than supply doesn’t mean you won’t be filtered out. If you can’t even organize your set of skills, something with which you should be intimately familiar, what chances do you have of being able to communicate well with colleagues at work over email or chat? Communication skills matter. Your resume is your one shot to show that.

Including skills such as “Microsoft Word” “CSV” and “JSON”

Unless you’re working with a highly-technical file format in specific conditions, such as Apache Parquet, this is generally a red flag. You can’t have “CSV” as a skill any more than you can have “desktop icons” as a skill. It’s a file format, it merely is, its existence requires no skill on your part. Microsoft Word, while a great software, is unlikely to be a required skill for engineering. Remove the cruft, focus on the real content.

Including skills without qualification

Listing a skill means you’re ready to back it up in an interview, unless you qualify your level of expertise as more novice. A giant list of programming languages or frameworks is an immediate red flag. There are prolific engineers out there, but generally most programmers work in 2–3 languages regularly, with some rare cases working in 5–6. 10 languages listed without qualification is usually dishonest. It’s an invitation to ask technical questions on any of them, and in a real interview, candidates either backpedal saying they’ve only run “hello world” on them, or mention how they haven’t used it in 10 years. It’s simple, either don’t include them, or qualify the level of expertise. Otherwise, you’re asking for trouble.

Did you claim serious expertise in SQL? Be prepared to be asked about indexes, query optimization, and scaling. Scala? You’ll be asked about Futures, case classes, and if you listed functional programming in Scala, you’ll be asked about cats or scalaz, or type classes. Be prepared to back it up, or qualify your skills. “I’ve used map and reduce” are valid things to bring up in functional programming, but are rather basic, in contrast to discussions of monads. This is less about having that level of depth, and more about honesty about the depth itself. I’ve toyed with some functional programming, but you won’t me see me claiming heavy expertise there.

Excessive use of adjectives and fluff in previous job description

“Developed highly-technical fundamental architecture decisions to correctly implement coherent and cohesive highly-reusable content media solutions.” Come on, we both know you’re bullshitting, why are you doing this? This kind of business bullshit should be reserved for parody shows like Silicon Valley. They’re an extremely obvious red flag. If you can’t succinctly and accurately summarize your work on a project, chances are you did nothing of consequence, or worse, nothing at all. Be simple, be clear, be honest. That’s all you need to do. It’s not Shakespeare, it’s factual reporting with a light spin to highlight your individual accomplishments.

No details of what was implemented

“Built highly-tailored solutions to business problems. Language used: Python.” Ok… what exactly was built here? Unless it’s a top-secret project at a company, it’s better to give at least a general outline of what was built. If it is top secret, say as much, and this can be discussed in some generality in confidence during an interview, within the scope of NDAs and such. Or if not, some other evidence of skill such as other job experiences than the secret job, or a take-home assignment or open source project work can be used. In general, any fluff is a red flag. Remove the fluff.

Lying about experience

I want to tell you that this is a rare situation, alas, humanity is what it is, and lies are rampant. I’m not entirely certain what motivates people to be so brazen as to lie on their resumes, knowing they could be called out. It’s not that hard to get an interview (passing is another story). Being caught in a lie during a phone screen is immediate cause for ending the process. Someone who is willing to lie as their first impression can only go downhill. Huge red flag, although this one tends to get caught at phone interviews.

Out of date

Perhaps you were good at Perl a long time ago, but it’s unlikely you’ve used it recently. Update your skill levels to reflect your strongest skills first, and if you’re no longer great at something because it’s been a while, demote the skill. Continually adding everything you’ve done to a giant list of skills, potentially out of order of importance, leads to the red flag listed above in including skills without qualification. Updating the resume doesn’t take long, but helps to preserve integrity. Your career is a living thing, and your resume should be a living document.

Resumes matter

Resumes are just the first step in the process, but they’re the vital and proverbial first step in the journey of a thousand. Take the time to be organized, accurate, and clear. Get assistance. Avoid these red flags. Be honest, be yourself, be humble.

Phone interviews are a whole other can of worms I might cover at some point. That’s where the resume gets picked apart for deceit, and skill level begins to be measured in practice. So first, focus on making sure the resume doesn’t embarrass you later.

In an ideal world, everyone would get that first phone interview who should because their resume is an honest reflection of what they’ve done, that is well-organized and readable. More good candidates making it to phone interviews helps everybody. Candidates get more interviews, and companies get a larger pool of people to filter for actual skills and fit. So if you spot these issues, fix them, and we’ll all be better off. I look forward to working with great, conscientious engineers.