Jake's Resume After Your First Job: How to Adapt It for Mid-Level and Senior SWE Roles

You used Jake's Resume to land your first engineering job. It worked. Clean single-column layout, projects section front and center, a couple of internships, your degree, a skills line. You sent it out, got callbacks, interviewed, got an offer. Congratulations. Genuinely.

Now it is a year or two later. Maybe three. You have shipped real features. You have been on-call. You have opinions about database indexing and strong feelings about code review etiquette. You are applying for your next role, so you open up that same Jake's template, add your current job to the top, and start sending it out.

And the callbacks are not coming the way they used to.

The template is not the problem. Jake's Resume is still one of the best foundations for a software engineering resume. The problem is that you are using a junior resume structure for a non-junior career. The layout that made you look like a promising new grad now makes you look like you have not grown. The sections are wrong. The emphasis is wrong. The bullets read like someone who is still learning rather than someone who is delivering.

Let me walk through exactly what needs to change and when.

The Junior Resume Worked for a Reason

Before we change anything, it is worth understanding why the original structure worked so well at entry level. Jake's template solves the fundamental problem every new grad faces: you do not have much professional experience, so you need to prove capability through other signals.

That is why the classic Jake's layout looks like this:

1. Education (top, because your degree is your strongest credential)
2. Experience (internships, part-time roles, maybe one full-time position)
3. Projects (the workhorse section, proving you can actually build things)
4. Skills (languages, frameworks, tools)

Projects do the heavy lifting. You do not have two years of production experience, so your React dashboard, your CLI tool, your capstone project fill the gap. They show you can write code, scope a problem, and ship something. Hiring managers reading junior resumes know this. They are not expecting production-scale systems. They are looking for signal that you can learn, build, and communicate.

This structure stops working the moment you have real experience to show. And most people do not notice when that moment arrives.

The Shift: When Projects Should Shrink

Here is the career math. As a new grad, your projects section might have 3 to 4 entries with 2 to 3 bullets each. Your experience section has maybe one internship. The ratio makes sense: projects are 70% of your resume because they are 70% of your evidence.

After your first full-time role, that ratio needs to flip. You now have 1 to 2 years of professional experience building production software used by real people. That experience is worth more than any side project, no matter how impressive the project was. A hiring manager evaluating a mid-level candidate cares far more about 'maintained a payment service handling 50k transactions/day' than 'built a to-do app with React and Firebase.'

The transition looks like this:

The hard part is letting go. That distributed systems project you spent 3 months on feels important. It was important, at the time. But keeping it on your resume next to two years of professional experience makes you look like someone who peaked in college. It signals that your side projects are more notable than your professional work, which is not the message you want to send.

Keep a project only if it is genuinely exceptional (thousands of GitHub stars, published research, something that went viral) or directly relevant to the role you are targeting in a way your professional experience is not. Otherwise, reclaim that space for more experience bullets.

Bullets Need to Evolve

This is the change that matters most, and the one people get wrong most often.

Junior bullets describe what you built and what tools you used. They read like this:

• Built a REST API using Node.js and Express to serve product data to the frontend
• Developed a React dashboard for visualizing user engagement metrics
• Implemented JWT authentication for the internal admin portal
• Created unit tests using Jest, achieving 85% code coverage

These are fine for a junior resume. They show you can use real tools to build real things. The hiring manager reads them and thinks: this person can write code and ship features. That is exactly what they need to know about a junior candidate.

But after 2+ years of professional experience, these bullets become a liability. They describe tasks, not impact. They say what you did but not why it mattered. They read like a ticket description, not a career story. A mid-level engineer's bullets need to answer a different question: not 'can this person code?' but 'can this person own something and make it better?'

The same work, written at a mid-level:

• Owned the product catalog API serving 200k daily requests, reducing p95 latency from 340ms to 90ms by redesigning the query layer and adding Redis caching
• Led the migration of the analytics dashboard from a legacy jQuery app to React, cutting page load time by 60% and unblocking the data team's self-serve reporting initiative
• Designed and implemented the authentication system for internal tools used by 150 employees, replacing a shared-password spreadsheet that had been flagged in a security audit
• Established the team's testing practices from scratch, building a CI pipeline with Jest and Cypress that caught 3 production-impacting bugs in the first month

Notice what changed. The technology is still there, but it is no longer the point. The point is ownership ('owned,' 'led,' 'designed'), scope (200k daily requests, 150 employees), and outcome (latency reduction, security fix, bugs caught). The reader finishes each bullet knowing not just what you built but why it mattered and how big it was.

When to Drop Coursework

Short answer: the moment you have a full-time engineering role on your resume.

Coursework exists on a junior resume for the same reason projects do: to compensate for missing professional experience. 'Relevant Coursework: Data Structures, Operating Systems, Distributed Systems' tells a hiring manager that you have the academic foundation even if you have not applied it professionally yet.

Once you have applied it professionally, the coursework line is redundant. You do not need to prove you took a databases course when your experience section shows you designed a database schema for a production service. The work speaks louder than the class.

Drop coursework entirely after your first full-time role. Use that line of space for another experience bullet. If your education section feels thin after removing coursework, that is fine. At the mid-level, education should be thin. One line: degree, school, graduation year. That is all a recruiter needs.

Exception: if you have a graduate degree in a directly relevant specialty (MS in Machine Learning applying to ML roles), keep it prominent. The advanced degree is a differentiator, not filler.

Handling Multiple Roles at One Company

This is a formatting question that trips up a lot of people. You joined Company X as a junior engineer and got promoted to mid-level after 18 months. How do you represent that?

Option 1: Two separate entries. This works but wastes vertical space because you repeat the company name, location, and context.

Option 2 (recommended): One company header, multiple role entries nested under it. This is cleaner, saves space, and visually communicates career progression within the organization.

It looks like this:

A few things to keep in mind with this format:

• Put the most recent role first. The reader's eye goes top-down.
• Tailor bullet count by recency. Your current role gets 3-4 bullets. The previous role gets 2-3. Do not give equal weight to a role you held two years ago.
• Differentiate the bullets. If both roles describe the same type of work with the same scope, the promotion does not come across. The senior role should show a visible step up in ownership, scope, or complexity.
• Do not repeat the same achievements. If you mention a system in the earlier role, the later role should show how you evolved it, scaled it, or moved beyond it. Not the same story twice.

Showing progression within a company is a strong signal. It tells the hiring manager that your employer saw enough growth to promote you. That is third-party validation of your trajectory, and it is worth more than you might think.

The One-Page Question

Jake's Resume is built for one page. For juniors and most mid-level engineers, one page is correct. You do not have enough experience to justify two pages, and padding a resume to fill space is worse than leaving it lean.

But at senior level (roughly 7+ years, or 5+ years with significant scope), the one-page constraint starts working against you. Here is why:

A senior engineer's resume needs to communicate a different story than a mid-level resume. It is not just 'I can build things and own them.' It is 'I can identify what needs to be built, align a team around it, execute across multiple systems, and deliver outcomes that moved the business.' That story requires more space. Not because you are padding, but because the work is genuinely more complex and cross-cutting.

Consider what a senior engineer might need to communicate:

• 3-4 roles across 2-3 companies, each with meaningful bullets
• Technical leadership on projects spanning multiple teams or quarters
• System design decisions with long-term architectural impact
• Mentoring, hiring, or process improvements that shaped the team
• Open source contributions, patents, publications, or talks (if applicable)

Cramming all of that into one page means either cutting important context or writing bullets so compressed they lose meaning. Neither serves you well.

One important caveat: two pages does not mean fill two pages. If you go to a second page, it should be because the content demands it, not because you relaxed your editing standards. A two-page resume with filler is worse than a tight one-pager. The second page is earned, not given.

The Skills Section Evolves Too

On a junior resume, the skills section is a laundry list of technologies. It exists partly to trigger keyword matches and partly to show breadth: look, I have touched Python, Java, JavaScript, React, Node, Docker, AWS, PostgreSQL, MongoDB, Git, and Linux.

At mid-level and beyond, a flat list of 20 technologies sends the wrong signal. It says 'I have used all of these' without indicating depth in any of them. A hiring manager reading it cannot tell whether you have 3 years of deep Python experience or whether you wrote one script in a college lab.

Structure your skills section to communicate depth, not just breadth:

Grouping by category immediately communicates where your depth lies. A reader scans this and understands: this person is a backend-leaning full-stack engineer who works in AWS. That is useful information. A flat comma-separated list of 25 technologies does not communicate anything that specific.

Also: remove technologies you cannot discuss in an interview. If Kubernetes is on your skills section and an interviewer asks about pod scheduling, you need to have something to say. If your Kubernetes experience is limited to running kubectl get pods once, take it off. Every item in your skills section is an implicit invitation for the interviewer to ask about it.

Education Moves Down

On the original Jake's template, education often sits at or near the top. For a new grad, this is correct. Your degree is your strongest signal.

After your first job, education moves to the bottom. It does not disappear. It just stops being the headline. The recruiter scanning your resume for 6 to 10 seconds should see your most recent role first, not your university. Your professional work is now the thing that gets you interviews. Your degree is context, not the lead.

The layout progression:

Notice that the bones of Jake's template stay the same across all stages. Single column. Clean lines. Standard headings. ATS-friendly structure. What changes is the content hierarchy: what gets emphasis, what gets space, and what gets cut.

A Common Mistake: The Senior Resume That Reads Like a Junior One

I review a lot of resumes from engineers with 5+ years of experience that still read like slightly longer versions of their new grad resume. The tells are consistent:

• Every bullet starts with 'Developed' or 'Built' or 'Implemented.' These are doing-verbs. They describe task execution. Senior bullets should include leading-verbs: 'Designed,' 'Architected,' 'Led,' 'Established,' 'Drove.'
• No bullet mentions scope beyond the immediate task. There are no team sizes, user counts, request volumes, or business outcomes. Everything is local: I did this thing. A senior resume needs to show the blast radius of your work.
• Projects section is still 40% of the resume. If your best evidence at the 5-year mark is still a college project, something has gone wrong with how you are presenting your professional experience.
• No evidence of technical decision-making. Every bullet describes execution, never the 'why.' Senior engineers are valued for judgment: choosing the right approach, evaluating trade-offs, making calls under uncertainty. If your resume does not show this, you read as a mid-level who has been executing for 5 years without growing.
• GPA is still listed. Remove your GPA after your first role unless it is truly exceptional (3.9+) and you are applying to companies that explicitly value it. After 2+ years of experience, nobody cares.

The resume does not need to be radically different. It needs to reflect where you are, not where you started.

Putting It All Together

Here is the full evolution, stage by stage:

Year 0-1: The original Jake's

• Education at or near the top, with relevant coursework
• Experience: internships and first role, 2-3 bullets each, focused on technologies used
• Projects: 3-4 entries, your primary evidence of capability
• Skills: flat list of technologies you have worked with
• One page. No exceptions.

Year 2-4: The mid-level shift

• Experience moves to the top, 2-3 roles with 3-4 bullets each
• Bullets evolve from 'built X with Y' to 'owned X serving [scope], achieved [outcome]'
• Projects shrink to 1-2 entries or disappear entirely
• Coursework is gone. Education is one line at the bottom.
• Skills section is categorized by type, not a flat list
• One page. Tight editing.

Year 5-7: The senior transition

• Experience is 70%+ of the resume. Multiple roles, nested if at the same company.
• Bullets show leadership, system-level thinking, and cross-team impact
• Projects section is gone unless something is genuinely notable
• Skills section reflects deep expertise, not breadth
• One page if it fits. Page and a half if cutting content weakens the resume.
• Education is a footnote, not a feature.

Year 8+: The staff/principal resume

• Two pages are justified if every bullet earns its space
• Bullets describe initiatives, not tasks. 'Led the 6-month effort to...' not 'Implemented a feature that...'
• Scope is organizational: teams influenced, systems redesigned, roadmaps shaped
• Skills section might include architectural patterns, not just languages
• Publications, patents, conference talks, or open source maintainership if applicable

The Foundation Stays the Same

Jake's Resume got popular for a reason. The single-column layout parses cleanly on every ATS. The formatting is scannable. The structure is logical. None of that changes as your career grows.

What changes is what you put inside the structure. The template is a container. At the junior stage, you fill it with potential: projects, coursework, technologies you have learned. At the mid-level stage, you fill it with evidence: production systems you have owned, problems you have solved, outcomes you have driven. At the senior stage, you fill it with leverage: initiatives you have led, teams you have shaped, decisions you have made that had lasting impact.

The container grows with you. But only if you let it.

Start Here

If you are still on the original Jake's template and it has been a couple of years, start by restructuring your sections. Move experience to the top. Cut or shrink your projects. Rewrite your bullets with ownership and scope, not just technologies. That single pass will do more for your callback rate than any other optimization.

Once you have restructured, run your bullets through the Rejectless linter. It checks for the exact issues mid-level and senior engineers hit most often: vague impact, missing scope, filler language, and bullets that describe activity without outcome. It will not rewrite your resume for you, but it will show you exactly where your bullets are still reading junior.

If you are starting a major rewrite from scratch, the builder walks you through each section with guided prompts designed for your experience level. It helps you think through ownership, scope, and outcome for each bullet before you write it.

More Guides