There are two types of software developers: ones who have gotten their first full-time job, and ones who are looking to land that first one. Based on which group you are in, recruiters and hiring managers will care about different details.
For people without full-time experience, your internships, education details, projects, and achievements are what will set you apart from the many other applicants who are also looking to land their first jobs. As soon as you have that first job, your work experience and the professional skills you use day to day become far more relevant for recruiters and hiring managers.
Based on which group you are in, you’ll want to structure your resume differently. And as you spend more time working professionally and start to build up more experience than can fit on a few pages, you’ll have the pleasant problem of deciding which one of your past experiences not to talk about.
When you are a student or new grad, you often feel like you have little to no experience to show. Make the most of what you have, though—and if you are truly low on experience, address this parallel to the application process. Here are the experiences that catch the eyes of people reviewing your CV the most, in priority order:
A Possible New Grad Resume Structure
Here is a structure that could work well for a new grad, using the Pragmatic Engineer’s Resume template:
Follow these guidelines for a resume that is easy to scan, with the most relevant parts being closer to the top:
From the inside out: how can new grads and interns grab the attention of recruiters? Sebastian Prieto Tovar and Claire Taylor have recruited hundreds of students and interns for Uber and other tech companies. Here’s the advice they have for people starting out: “The resumes that stand out from the hundreds of incoming ones are the ones that are a good match for the job description and show some relevant experience. This could be internships, but it can equally be projects the person has done. What we always tell students is read the job description, then amend your resume accordingly. And reach out directly to the recruiter, when you can. If you are a university student, ask for help from your career departments. They usually have lots of contacts. What we look for on a resume is your studies, relevant courses, and what you’re best at with your studies. Which class is a standout one that you mention? What are you most passionate about in your studies? We read through your relevant experiences in projects and internships. We also care about extracurricular activities, hackathons, working in teams outside school and apps, websites, and other cool things you created outside school. For intern recruiting, we do closely look at the timing of your studies. For example, if the internship would start in June, we will only consider candidates who are ready to start at this time. Or if the job description is for people in a certain year, we look at this. Make it crystal clear on your resume that you fit the requirements: clarify when you can start, or how much time you have left on your studies. Do spend plenty of time preparing for the interviews themselves. Read about the company, watch the videos, learn about the culture, read stories about employees, and understand the job description. Look up your interviewers on LinkedIn before your interview and read things that they might have published. You’ll not only show that you’ve gone the extra mile—but you’ll also learn a lot in this process.” |
Advice when applying to Big Tech: we’ll close with an opinionated set of advice from a thread shared by a grad recruiter at Fortune 100 on Twitter. These apply to all places that see hundreds applications per position, so to most of large tech company internships and new grad positions:
When you are no longer freshly out of school, follow this structure to make your resume easy to review.
From the inside out: what recruiters typically look for in a resume Victoria Farelly, who recruited for Uber, Booking.com, and ING explains how what recruiters typically look for in a resume is usually an extension of what the hiring manager asked them to screen for: “A hiring manager will often say to you, as a recruiter: ‘I want these five things, and if a person doesn’t have these five things, I’m not hiring them.’ If you’re a good recruiter, you’re there to advise them on the market and advise them that we have enough resources to take someone who only has three or four of those five things. Perhaps we have the resources to train or mentor them. Or perhaps they'll just pick it up in the first month. When the hiring manager is more flexible on the “must-have things”, you then look at if people have worked in similar environments, or on similar problems. For example, when hiring for Uber, you might look for signs that this person worked on something at scale. Did they work in multidisciplinary teams? What technologies have they been working with? And I’d look at not just your work projects, but also your personal ones. For example, if you’ve worked extensively with .NET at work, and knowing Java or Go is a must-have for the role, I’d expect to see some of those languages somewhere else, like in the projects or technologies section. And I’d stress how what really makes you stand out is having a tailored CV for the position. If you are applying for 20 different jobs, you should have 20 different CVs. Each one should be different and specific for that role. And while this might sound a “bad” thing to do, it’s not. It’s a necessary thing to do.” For an actionable way to tailor your resume for a position, see the Keyword Check for That Position section. |
“What languages and technologies is this person hands-on with?” This is one of the first questions recruiters and hiring managers have when they look at your resume. The easier it is to answer this question, looking at your resume, the better. There are a few common approaches in making this information clear— we’ll look at three different ones.
Approach #1: Separate Languages and Technologies Section
The most common approach is listing relevant technologies for the position that you are proficient in a separate section. People tend to give this section various titles: Skills, Tech, Tools, and many others. The name is less important; the contents are more so.
By moving the languages and technologies you use to a separate section, you make it easy for the recruiter and hiring manager to verify what overlaps you have with the role. You shouldn’t only list the technologies on the job advert, of course: but you shouldn’t go overboard, either. Only list areas where you do have enough knowledge to do work day-to-day. I usually advise against listing the level of expertise, unless you have extremely deep knowledge of a relevant technology. I advise against using a points system as well. Also, avoid listing trivial technologies or ones that are niche, and have nothing to do with the job. Same goes with applications that are trivial to learn. As always, use good judgment.
Even when having a separate section to call out relevant languages and technologies, do mention key technologies in your work experience when you talk about specifics. This information will reinforce that you have had hands-on experience with a specific language or a given framework.
Before and after: languages and technologies
This resume is sent for a job advert for a full stack position. The job advert listed that knowledge of at least one OO language is a must, ideally between JavaScript, Go, or Java. Experience with a popular frontend framework, ideally, React.js, is an advantage, as well as having designed APIs. While not in the job description, the engineering blog describes how this company runs most of its infrastructure off AWS.
Before:
This section is a dump of all the technologies this person has touched in the past. Some of the listed ones include ones that are implicitly assumed—if you’ve used Java, you likely know how to use an IDE like Eclipse. And some technologies have no relevance: Rational Rose is a tool rarely used outside academia, and phpMyAdmin as a skill raises the question if you can manage PHP without a GUI interface. For Trello and Word: is there anyone who doesn’t know how to use these?
The person is also using terms like “expert” and “proficient”. This is a double-edged sword, as it implies that the person is not an expert in other languages. Also, talking with recruiters, the self-evaluation of people means little: several technical recruiters mentioned that people who rated themselves as an expert in a specific language would often get rejected based on not having enough depth, after being grilled in the depths of that language.
As a rule of thumb, avoid listing your expertise level. Instead, list only languages that you feel proficient with, and list your strongest languages and technologies first.
Improvement areas visualized:
After:
The revised version is far cleaner. The formatting uses tabs, making it easier to scan. The tools and applications that anyone can pick up in a matter of hours are removed. The list is more relevant for the job description, and the languages that this person was actually hands-on with.
After talking with the person, it turned out that they have not used C++ or Perl in years, and they rated themselves as very rusty in these. Removing “old” languages makes sense both because they are not relevant. Also, languages that are no longer used can contribute to age bias - recruiters subconsciously assuming the person applying must either be old, or reluctant to pick up new languages.
Approach #2: work experience conveying languages and technologies
Another approach is to explicitly call out languages and technologies used at each of your positions, and not have a separate section for this. This approach helps convey the recency of the technologies you used, as opposed to having a big list of technologies—some of which you might not have used in a while.
This approach helps convey the recency of knowledge in a particular technology. Hiring managers and technical recruiters will have a better understanding of how up-to-date you likely are with certain stacks. This approach can work better when applying for tech companies hiring generalist software engineers, where it can be an advantage to show that you have moved between languages and stacks in the past.
Let’s look at a snippet from a resume using this approach:
Weaving in the technologies into the descriptions is an approach that can also work well. It makes for a more natural reading experience. I would suggest to be consistent in where you mention the technologies, to make these easy to spot. Here is an example of this approach:
Approach #3: splitting out not-so-hands-on languages and technologies
The downside of having a list of languages and technologies is that it does not differentiate between ones that you are hands-on with, and ones where you would need a refresher. In this case, adding technologies that you are a bit more rusty with—but differentiating these—can be an option.
Here’s an example of this, where a person is applying for a position for a company that is heavy on Ruby. They’ve done this in the past and wouldn’t mind picking it up again, but their Ruby knowledge is not on the same level as JavaScript and Java, which they both use day-to-day.
Tell a Story
Your resume should tell a story backward in time that people can glance at and understand. Take a look at this “story”:
It shows progression and clarity. This is the type of clarity you ideally want to convey. Here are a few things you can do to have a clear story:
From the inside out: is it ethical to change my job title on my resume? An experienced recruiter who has spent a decade recruiting for international startups and Fortune 100 companies shares their view on whether it is okay to change your job title: “The only ethical exceptions for changing your title are if your actual responsibilities in the past three or more months does not reflect your title. It is also fine to do so when your title is so company-specific that it does not transfer to the industry or other industry. For example let’s say you joined a startup with a software developer title. Due to the fast-paced environment you spent the last year acting as a team lead, leading a team of five. Your title has not been changed, though. Without a title change, your resume may be overlooked when applying to team lead or senior positions when recruiters skim the resumes. In these cases, I personally think that it’s okay to adjust your job title to reflect your actual work done. I would not recommend it otherwise.” As a hiring manager, my advice is similar. I know of a person who was hired as an iOS engineer to a company, and “iOS Engineer” was their title. However, three months in, they moved to backend development, and did this work for a year and a half, without a title change. For this person, I would suggest to change their title on their resume to one of “Software engineer (iOS & backend)”, “Software engineer”, or split out their time at the company as “iOS engineer” and “Backend engineer”. Do it depending on what they’d like to highlight, and the path they intend to carry on. |
Many resumes start with a section titled “Summary” or “Profile”. People often add from a sentence to a paragraph of text. Here are a few examples:
Here’s the thing: recruiters and hiring managers rarely read this section on the first scan, regardless of how much time and effort you put into it. They only do so when they have decided to proceed with your resume. For less experienced candidates, with a few years’ experience, I suggest to not have this section, unless you customize it for the job listing, highlighting things that showcase why you’re a great fit for the position. If your resume doesn’t catch the recruiter’s eye, they won’t read the summary section.
An overly ambitious summary section can also backfire. Say you are applying for a developer position and you say in your summary section that you are looking for opportunities to lead. If the hiring manager is not looking for someone with leadership ambitions, they might not call with you, thinking they do not intend to offer this growth opportunity. However, had you left this part out of the summary section, you might have gone through, got the position, then naturally grown into a lead on the team, over time.
When you do have a summary section, make it short, and add specific and practical information. For example, mention the years of experience you have, especially if this does not match up with when you graduated. Also, add highlights that showcase why you are a great fit for the position.
Cases where the summary section can be helpful:
From the inside out: crafting a powerful summary section Randall Kanna is a senior software engineer previously at Eventbrite and Pandora. She has reviewed hundreds of developer resumes, been on hiring teams and reworked the interview process at her companies. She suggests putting in the time and effort to create a summary section tailored for the job. Here is the advice she shares in her book, The Standout Developer: “The traditional, boring summary has become outdated: “Objective: Obtain a goal in Software engineering at a tech company.” Having a powerful summary section can mean you get noticed and stand out in a pile of resumes. More than that, your summary should immediately draw the recruiter in and make them want to keep reading. Show the hiring manager or recruiter who you are, and highlight an achievement. The key to writing a standout summary is to do it last. Write your resume first and then, once you've got it airtight, focus on your summary section. Look for the most impressive details in your resume and articulate what you delivered. The recruiter won’t really care that you are an avid gardener or reader or that you love to hike; they want to know that you'll create results for their company... period. I recommend tailoring your personal summary section to the job you are applying for, if possible. For instance, if I were applying for an iOS dev job, I would not highlight that I spent the last few years as a frontend developer. Instead, I would include that I taught myself Swift and Objective-C a few years ago. And I did it in a short period of time to step into a role my company needed. Finally, make sure your summary section isn’t too short or too long.” |
When you have more than 10 years of experience and have worked at multiple companies, you start to stand out from the crowd of applicants. At this point, your resume will be read far more often by the hiring manager, and not just the recruiter. And hiring managers will want to understand more of your history, and what you could bring to the table.
Here are a few ways you could consider “breaking” the previously suggested principles, to play to your strengths.
Do list your major deliverables and accomplishments—and while the two-page limit is not a hard one, try not to go over this length. Keep your resume focused. The one-page resume is for grads, and the two-page resume for everyone else. This is the rule-of-thumb guidance for today’s tech resumes. But when you have more relevant experience to speak to, don’t necessarily be hung up on the two-page limit many guides recommend. List all your experiences that the hiring manager would find relevant—while balancing to stay concise.
Consider having a summary section, where you briefly describe the standout part of your experience and what the company would get with you. Tailor this one for the job. While you could consider adding details about your motivation in applying for the position, I advise against this—talking about your motivation will be part of the hiring manager interview. Note that for senior developer positions, having a summary section will rarely be a tiebreaker. The rest of your resume will be.
Do have separate resumes for management and IC positions. Experienced engineers can often move between tech lead, engineering manager, and senior engineering roles. And this manager-engineer pendulum is a great thing. Some of the best staff engineers I’ve worked with have been managers beforehand. However, when crafting a resume, instead of a generic engineer/manager resume, create two separate ones. One should tell the story on why you want to go back to being an engineer in your next role, the other about why you’re a great fit as a manager.
Companies rarely hire for hybrid roles. And if a hiring manager receives a resume that is a mix of a senior engineer and manager experience, with no clear story on where to go next, they will likely put it in the “unsure what to do with this one” pile. Tailor your resume and the story towards each type of position—and you’ll get callbacks far more often.
Take this example on two resumes for the same person. One is targeted at going back to an independent contributor (IC), and the other on carrying on as a manager. This person is applying for different roles and is genuinely open to both options. They do miss coding day-to-day, but they would not mind staying on the leadership track given the right opportunity.
Resume 1—going back to an individual contributor role:
Resume 2—staying on the manager track:
Note how the two resumes tell a very different story, even though all of the facts in them are 100% correct. They still belong to the same person: but this person focuses on different parts of their journey, with different end goals. A few things to highlight between the two resumes:
When crafting different resumes, be very-very careful not to bend facts. Your resume will likely make its way around the company. I’ve heard recruiters talk about candidates who had up to 4 different versions of their resumes in the system: and the facts contradicted each other. Needless to say, this person was not invited to interviews after the team discovered that they seem to be fitting their resume to the job adverts, adding things that don’t add up.
From the inside out: can my resume go beyond two pages? Hiring managers and recruiters at different companies will have different opinions on the resume length for experienced people. They will all suggest keeping it relevant, though. Ken Liu, who has recruited for close to 10 years at Microsoft, puts it like this: “Keep it concise. One to two pages is ideal. However, if you are management/director level you can go up to 3—4 pages at maximum. Though I’d add that going this long isn’t desirable. Think about the fact most recruiters and hiring managers of larger companies will be reading through many CVs for this role and spend 10-15 seconds doing a first scan of the CV and making an initial judgment. This is the case even for more experienced candidates.” Long-time CTO Steve Ball notes how listing relevant details is important, even at the expense of length: “I've been at the tech C-level for 20 years; I've reviewed thousands of CVs that time and hired hundreds of software engineers. It's a bit of a modern thing to have a one- or two-page CV. As a CV reviewer, I am often left without enough details to make a decision on whether to proceed. In the cases where I had a glimmer of interest, I have asked recruiters to give me a fuller fleshed-out CV from the candidate. For candidates, I recommend you mention your major deliverables and accomplishments for each role. If you've had 5–10 roles then this will easily take you over 2-3 pages. If you've had a lot of major accomplishments in a role, then list them.” |
In this chapter, we’ve covered the recommended structure of your resume, based on your experience. You want to convey the most relevant details that recruiters and hiring managers care about on the first page. Telling a story, tailoring a summary section, and listing the relevant languages and technologies are all traits of well-structured resumes.
To further improve your resume, consider doing the following checks: