Free lesson · The Job Search System
The Experience Section: Telling Your Professional Story
The Experience Section: Telling Your Professional Story
Student: Swati, we've covered resume structure, the 6-second review, impact-driven bullets, and ATS optimization. Now I want to zoom in on the experience section specifically, because that's where I have the most content and the most questions. How do I organize it? What do I include? What do I cut?
Swati: The experience section is where your resume either tells a compelling career story or reads like a list of jobs you've held. The difference is entirely in how you organize, select, and frame the information. Let me walk you through the principles.
The Recency Principle
Your most recent role gets the most space. This is non-negotiable. The hiring manager cares most about what you're doing now - it's the strongest signal of your current capabilities, your current domain, and your current level of impact.
Here's the allocation model I recommend:
graph TD
A["Current or Most Recent Role<br/>4-6 bullets<br/>~40% of experience section"] --> B["Previous Role<br/>3-4 bullets<br/>~25% of section"]
B --> C["Role Before That<br/>2-3 bullets<br/>~20% of section"]
C --> D["Older Roles<br/>1-2 bullets each<br/>~15% of section"]
style A fill:#51cf66,color:#fff
style B fill:#339af0,color:#fff
style C fill:#fcc419,color:#000
style D fill:#868e96,color:#fff
This diagram shows the space allocation for the experience section. The current or most recent role gets 4 to 6 bullets and about 40 percent of the experience section. The previous role gets 3 to 4 bullets and about 25 percent. The role before that gets 2 to 3 bullets and about 20 percent. Older roles get 1 to 2 bullets each and share the remaining 15 percent. The allocation decreases with age because recent work is the strongest signal.
Student: What if my most recent role isn't as impressive as a previous one? Like, I was at Google before but now I'm at a smaller startup.
Swati: Your most recent role still gets the most space - but you curate the bullets differently. At the startup, you probably have broader scope, more ownership, and more diverse impact. Frame those bullets around the things a Google hiring manager would find impressive about startup work: end-to-end ownership, wearing multiple hats, building systems from scratch, operating with fewer resources. The role might be less famous, but the experience is often deeper.
If the Google role was genuinely more relevant to your target position, give it strong bullets too - 3 to 4 solid bullets. Just don't make it the primary focus if it was three years ago.
Ordering Roles: Chronological vs. Relevance
Student: Should I always list roles in reverse chronological order?
Swati: Almost always, yes. Reverse chronological (most recent first) is the universal standard. Hiring managers expect it. ATS systems parse it. Deviating from it creates confusion.
The one exception is if you have a non-linear career path - for example, you're a career switcher who had a finance career, then transitioned to engineering. In that case, you might consider a hybrid format where you lead with your engineering experience and group your finance experience separately under a heading like "Prior Professional Experience." But even in that case, within each group, roles should be in reverse chronological order.
What to Include vs. What to Cut
Not every role you've ever held belongs on your resume. Here's my decision framework:
Always include:
- Your current role
- Any role at a well-known company (name recognition helps)
- Any role where you did work directly relevant to your target position
- Any role that shows career progression (promotion, scope increase)
Consider cutting:
- Roles shorter than 6 months (unless the company was notable or the impact was significant)
- Roles from more than 10-12 years ago (unless they're at brand-name companies or have unique relevance)
- Roles in completely unrelated fields (for experienced engineers - career switchers handle this differently)
- Internships (once you have 3+ years of full-time experience)
Student: What about freelance or contract work?
Swati: Include it if the work was substantial and relevant. Frame it as professional experience, not a side hustle. "Contract Software Engineer - Multiple Clients (2022-2023)" with strong bullets showing the work you did is perfectly legitimate. If you had one major contract client, you can name them: "Software Engineer (Contract) - FinTech Corp (2022-2023)."
Handling Tricky Situations
Short Stints
Student: I have a role that lasted 4 months. I left because the company did layoffs. Do I include it?
Swati: It depends. If you accomplished something meaningful in those 4 months, include it with strong bullets - the impact matters more than the tenure. If nothing notable happened, you can omit it. The gap on your resume will be small (4 months) and can be easily explained in an interview if asked.
If you were laid off, there's no shame in that - especially in the post-2022 tech landscape. You can include the role and be prepared to explain the departure matter-of-factly in an interview: "The company reduced headcount by 30%. My team was eliminated."
Multiple Roles at the Same Company
If you were promoted at the same company, show both roles to demonstrate progression:
Amazon Web Services Seattle, WA
Senior Software Engineer (L6) Jan 2023 – Present
• [Strong bullets showing L6-level impact]
Software Engineer (L5) Jun 2020 – Dec 2022
• [Strong bullets showing L5-level impact]
This is powerful because it shows internal promotion - evidence that the people who knew your work best chose to advance you. It's one of the strongest signals on a resume.
Overlapping Roles
If you had a side role (open source maintainer, part-time contract, advisory position) that overlapped with your primary employment, list it separately but with clear dates. Don't make the hiring manager confused about whether you had two full-time jobs simultaneously.
Quantifying Impact Across Different Role Types
Student: The XYZ formula works well when you have big production numbers. But what about roles where the impact is harder to quantify - infrastructure work, internal tools, migrations?
Swati: Every role type has quantifiable impact. You just need to know where to look.
Infrastructure and DevOps roles: Your metrics are availability, deployment speed, incident response time, and cost savings. "Maintained 99.95% uptime for 47 production services." "Reduced deployment time from 40 minutes to 6 minutes." "Cut monthly AWS spend by $23K through right-sizing instances and implementing spot fleet management."
Internal tools: Your users are other engineers. "Built an internal data pipeline tool used by 35 engineers daily, reducing manual data extraction from 2 hours to 4 minutes per report." Internal adoption numbers are legitimate metrics.
Migration work: Migrations have clear before-and-after states. "Migrated 14 services from monolith to microservices architecture over 6 months, with zero customer-facing downtime during the transition." "Upgraded authentication system from OAuth 1.0 to OAuth 2.0 for 8M user accounts, completing the migration 3 weeks ahead of the compliance deadline."
QA and testing roles: "Implemented automated regression suite covering 1,200 test cases, reducing manual QA time from 3 days per release to 4 hours." "Identified and filed 85 P1/P2 bugs in pre-release, preventing an estimated $400K in post-launch incident costs."
Support or maintenance roles: "Resolved 120 customer-escalated technical issues per quarter, maintaining a 96% satisfaction rating." "Created 15 knowledge base articles that deflected 2,000 support tickets monthly."
The key insight is that every kind of engineering work has stakeholders, inputs, and outputs. If you can identify who benefits and how, you can quantify the impact.
Warning: The "I was just a cog in a machine" trap. Many engineers undervalue their contributions because they were part of a larger team. But your resume describes YOUR contribution, not the team's. "Contributed to the migration project" is a team statement. "Designed the data validation layer for the migration, ensuring 100% data integrity across 50M records" is YOUR statement. Even on a 20-person project, you had a specific role, made specific decisions, and produced specific outcomes. Find those and write about them.
Writing the Story Arc
Student: You keep saying the experience section should tell a "story." What does that mean structurally?
Swati: When I read a good experience section, I can see a narrative arc - a career that's moving in a direction. The specific direction depends on what you're optimizing for, but the arc should be visible.
Here are the common arc types:
The depth arc. You started broad and went deep. Early roles show general software engineering. Recent roles show specialization - distributed systems, ML infrastructure, payments, security. The arc says "I found my domain and I'm going deep."
The scope arc. You started as an individual contributor and grew into leadership. Early bullets say "implemented" and "built." Recent bullets say "led," "architected," "mentored." The arc says "I'm ready for the next level of responsibility."
The impact arc. The numbers get bigger over time. Early roles show small-scale work - hundreds of users, local impact. Recent roles show large-scale work - millions of users, cross-team impact. The arc says "I'm operating at increasing scale."
graph LR
subgraph "Depth Arc"
A1["General SWE<br/>Full stack"] --> B1["Backend Focus<br/>API design"] --> C1["Distributed Systems<br/>Specialist"]
end
subgraph "Scope Arc"
A2["IC: Built features"] --> B2["Senior IC: Owned systems"] --> C2["Tech Lead: Led team<br/>of 5 engineers"]
end
subgraph "Impact Arc"
A3["100 users<br/>local product"] --> B3["500K users<br/>regional product"] --> C3["10M users<br/>global platform"]
end
style C1 fill:#51cf66,color:#fff
style C2 fill:#51cf66,color:#fff
style C3 fill:#51cf66,color:#fff
This diagram shows three types of career story arcs. The depth arc progresses from general software engineering to backend focus to distributed systems specialist. The scope arc progresses from individual contributor building features to senior IC owning systems to tech lead leading a team of 5 engineers. The impact arc progresses from a local product with 100 users to a regional product with 500 thousand users to a global platform with 10 million users. Each arc tells a clear story of professional growth.
Student: What if my career doesn't have a clean arc? I've bounced between frontend and backend, worked at startups and big companies.
Swati: Then you create the arc through selective emphasis. Your career might have been non-linear in reality, but your resume is a curated narrative. If you're targeting a backend role, emphasize the backend work in each role and deprioritize the frontend work. The frontend experience doesn't disappear - it just gets less space.
This isn't dishonest. It's strategic framing. Every role you've held had multiple dimensions. The resume highlights the dimensions relevant to where you're going, not every dimension of where you've been.
Important: Your resume is not your autobiography. It's your argument for why you're the right person for this specific role. Everything on it should support that argument. Anything that doesn't support it either gets cut or gets deprioritized. This is why tailoring matters - the same career can produce different resumes optimized for different roles.
Experience Entry Formatting Patterns
Student: Are there specific formatting rules for how each role entry should look?
Swati: Yes, and consistency matters more than any particular choice. Here are the elements and their standard placement:
Company name and location go on one line - typically left-aligned with location right-aligned. If the company is well-known, the name alone is sufficient. If it's a startup most people haven't heard of, add a brief descriptor: "DataFlow (Series B, real-time analytics platform)."
Job title and dates go on the next line - title left-aligned, date range right-aligned. Use "Month Year – Month Year" format for past roles and "Month Year – Present" for your current role. Don't use years-only formatting like "2020-2023" - it creates ambiguity about whether that's January 2020 to January 2023 or December 2020 to January 2023. That ambiguity matters when a recruiter is calculating your tenure.
Team or product context is optional but valuable. A one-line description of what the team or product does helps hiring managers who aren't familiar with your company. "Payments Infrastructure team - real-time transaction processing for 30M monthly active users." This line provides instant context for the bullets that follow.
Consistency across entries: If your first role entry includes location, every entry should include location. If your first entry uses "Jan 2023" format, don't switch to "January 2023" for the next one. These small inconsistencies are individually trivial but collectively they signal carelessness - and in a 6-second review, the overall visual impression is a real factor.
The Bullet Sequencing Within a Role
Student: Within a single role, does the order of bullets matter?
Swati: Absolutely. The first bullet of each role is the most read - we covered this with Brandon's 6-second review. But the sequencing of all bullets matters too.
Lead with your strongest bullet. The biggest impact, the most impressive metric, the most relevant accomplishment for your target role. This is what the hiring manager reads if they only read one bullet.
Second bullet: a different dimension. If your first bullet was about technical impact, make your second about leadership or process improvement. Show range.
Third and fourth bullets: supporting evidence. These fill out the picture. They can be less dramatic but should still follow the XYZ formula.
Last bullet: the differentiator. If you mentored someone, led a cross-team initiative, or contributed to something beyond your direct responsibilities, put it last. It leaves the reader with a sense that you're more than just your technical deliverables.
Tip: The "Would I Ask About This?" Test: For each bullet, imagine you're the interviewer. Would you pick this bullet as a conversation starter? If a bullet is too boring to spark a follow-up question, it's either too vague (needs rewriting) or too trivial (needs cutting). Every bullet should be something you'd be excited to discuss for 5 minutes.
Interview: Your Experience Section Writes Your Interview Script
Brandon made this point in Topic 02, and it bears repeating: interviewers use your resume as the roadmap for behavioral questions. They'll pick 2 to 3 bullets that interest them and ask you to elaborate.
This means your experience section isn't just a historical document - it's a menu of conversation topics you're offering the interviewer. Every bullet is an invitation. Make sure you're only offering conversations you can have confidently and in depth. If a bullet is on your resume, the STAR story for it should be in your head. AlgoInsight's Behavioral Interview Mastery course teaches you how to prepare these stories systematically.
Exercise: Starter: Look at your experience section. Does the space allocation follow the recency principle? Is your most recent role getting 40% of the space? If an older, less relevant role is taking up more space than your current role, rebalance.
Intermediate: Identify the story arc in your experience section. Is it a depth arc, a scope arc, or an impact arc? If you can't identify a clear arc, you need to reframe your bullets to create one. Choose the arc that best supports your target role and adjust the emphasis in each role's bullets accordingly.
Advanced: For your most recent role, write 6 bullets using the XYZ formula. Then rank them by relevance to your target role. Put the most relevant first. Now read just the first 2 bullets - do they tell a compelling story about your current capabilities? If not, reorder or rewrite until those first 2 bullets alone would make a hiring manager want to call you.
Student: The experience section is starting to feel less like a job history and more like a strategic document. I'm choosing what to show, how to show it, and in what order - all to support a specific argument.
Swati: That's exactly right. In the next topic, we'll cover the supporting sections - projects, skills, and education. For many candidates, especially new grads and career switchers, these sections carry as much weight as the experience section. Getting them right completes the resume's structural foundation.
Let's go.