Most software engineers write for a living. That is they sit down at a keyboard and write code. If all goes well, Clean Code, a popular mantra that describes code that's readable, simplistic, and is shaped in logical clarity, is the final product.
In many ways, what goes into writing clean code is also useful for crafting an effective technical resume – or the other kind of writing that some engineers may find more foreign or challenging.
At Leet Resumes, where we’ve written thousands of experienced engineers’ resumes for free, we observe every day the errors, mistakes and miscommunications that result from software engineers trying to over-complicate, under-document, and jam too much unimportant stuff into their resumes.
While the analogy can be taken too far, the link between the maxims of Clean Code and best practices in writing a software engineer's resume are true. Clean code is easy to read, it is understandable, it follows conventions, it does one thing at a time, and it is performant. A great technical resume follows a similar path. Let’s walk through these parallels one at a time.
Make your resume easy to read
Time and again I've heard from hiring managers, HR staff, and resume parsing companies that it is important to keep your resume simple. You need to make it very easy for the human and computerized readers of your resume to digest the data regarding your background, goals, talents, accomplishments, skills, and capabilities.
There are plenty of ways to muck this up. Double- and triple-nested bullet points, multiple-column formats, novel and clever arrangements of data for aesthetic purposes, and leaving out specific numbers on outcomes, to cite just a few, all make for a more opaque reading experience for the hiring managers trying to assess your background.
Keeping your resume clean and simple leads to greater legibility and comprehension, in the same way clean code aids comprehension. That means the best format is the simplest one: a single-column design, in reverse chronological order, with each bullet point making the case for what you’ve successfully done in past roles. There are many temptations to deviate from this simplicity, though.
To take an example currently popular in the world of resume fads, many templates available on the internet today create a left-hand column with a colored bar chart to indicate your skill level in various fields. It is new, popular, aesthetically differentiated, and, unfortunately, useless and universally hated by recruiters.
Depicting each skill (Java, Agile, Python, or CI/CD) with a colored bar that extends to 60%, 75%, or 100% of the available area looks nice and breaks up the blocks of text in a way that many engineers find attractive. But this new fashion makes straightforward communication of your abilities more difficult to read.
Probably more important: The world’s resume parsers — the software that’s used to digest, comprehend, and store your resume in a company’s HR systems — can not read these graphic bar charts either. In fact, they typically view these graphic elements as unnecessary visual formatting and delete them.
Complexity on your resume makes it harder to read. Keep things simple.
Make your resume easy to understand
Now, making your resume readable is only part of the job of making it understandable.
Let's say you took that ill-advised skills bar chart I just mentioned and wrote it out as “8/10” to describe your mastery of Python. The data might now make its way to the reader, but that doesn't mean it's saying the same thing to a recruiter or hiring manager that it is to you. That's because this is hardly a common way of describing programming capability. I mean, how tough of a grader are you? Are you comparing yourself to BDFL van Rossum? Or to the kid who dropped out of your coding bootcamp?
As with clean code, a human ought to be able to read your resume and understand what you're best at. The most efficient way to get this done is to communicate your outcomes and accomplishments at past jobs and important projects clearly and effectively.
Too often, engineers will list what their tasks were and what tech they touched while doing it, which isn’t helpful. It’s the equivalent of commits that are all comments and no code - you’re telling readers what your career is about instead of what it’s done.
It’s better for you to make your resume understandable by focusing on the outcomes of your work. This means citing specific accomplishments, such as reduced latency, improved concurrency, reduced load time, or increased throughput – things that communicate your talents more clearly. It’s even better if you express these accomplishments in real numbers.
Quantified bullets that describe an outcome are more legible to the resume reader because they convey specific information about your performance on the job. It’s more understandable because your audience comes away knowing more about your capabilities and your proficiencies.
Similarly, do not copy-pasta and dump your job description into the bullet points. That’s the equivalent of pasting the story requirements into your code instead of actually engineering the solution. It tells us what you were supposed to do, not how you actually did it.
Related: Announcing program language quizzes
Your resume should do one thing at a time
Your resume’s overall goal is to generate interview requests for a job you want. That is its “primary directive,” and everything about the composition of your resume should follow that goal.
As in a job interview, where you want to be clear and specific about the type of growth you’re seeking for your next role, on your resume, you want to be clear and specific about the type of jobs you’re seeking.
It may seem obvious to you that a Software Engineer, Level I wants to be a Software Engineer, Level II. But it’s not. Some people have different career paths.
As a matter of fact, it’s likely that the hiring manager or HR person reading your resume today met someone just like you in the past seven days with a similar background but different career dreams.
Please make it easy on resume readers by stating your goals clearly on your resume. Share the three or four specific job titles you’d accept in your Professional Summary so that you’re declaring your intentions explicitly.
Further, resumes that take on too many tasks, and try to do too many things at once, end up failing in the same way that functions that try to do more than one thing fail.
If your resume’s goal is generating interview requests, then there’s probably a lot on your resume that doesn’t need to be there, regardless of how well it works
Remember: Code is judged by its success in the real world – or how performant it is – not on how nice it looks on a white board. In other words, a resume is judged as effective if it helps you get interviews, not how creatively you pulled off cramming in superfluous (and distracting) mentions of your multiple published papers, side hustle consulting business, every open-source project you've committed a line to, and jobs from fifteen or more years ago.
Engineers who get enamored with their own designs and feature creeping can spiral into the abyss of coding for coding’s sake instead of coding for real-world outcomes. The same can happen with engineering resumes.
Your resume should follow conventions
Finally, when stringing all these concepts together to package your resume, you'll want to be mindful of the final touch conventions of the humans who will engage with it. In the same way that Java variables should be written in camelCase and Python variables should be written in snake_case, your resume should follow the style that is common and appreciated among the consumers of resumes.
What are these conventions? At Leet Resumes, we’ve published our full technical resume style guide recommendations, including the order that recruiters and hiring mangers typically expect to find all of the important data in your resume: reverse-chronological order, with contact info at the top, followed by professional headline and professional summary, followed by work experience, education, and technologies. Honors, awards, projects, etc., are often left for the final section.
Understanding conventions like this (and the others we've gleaned from talking to technical hiring teams and posted in our guide) helps you, and your resume, perform better.
Now, look, variables are variables and programming languages can parse them whether they’re written camel, snake, kebab, or any other case. Computers aren’t that stupid.
But the reason conventions are important is that conventions make it more likely that you’ll be understood. When you communicate in an expected way to your expected audience, you may reasonably expect they will understand you.
In sum, your engineering resume should be simple, readable, easy-to-understand, conventional, single-focused and performant. That’s what we expect from Clean Code, and what you should expect from your resume.
Triplebyte helps engineers find great jobs by assessing their abilities, not by relying on the prestige of their resume credentials. Take our 30 minute multiple-choice coding quiz to connect with your next big opportunity and join our community of 200,000+ engineers.