{"title":"Experience Section","description":null,"content":"The experience section is where a hiring manager looks for proof. They want to understand what you worked on, how much responsibility you had, and whether your past work is close to the work they need done.\n\nThis section should not read like a job description. It also should not be a paragraph of everything you touched. A strong experience section is selective. It gives the most space to recent, relevant work and uses bullets to show what you actually contributed.\n\n---\n\n# Weighting Your Work History\n\nThink of the experience section as your work history, edited for relevance. Your most recent and most relevant roles usually deserve the most space. Older roles can be shorter, especially when they no longer say much about the kind of engineer you are today.\n\nThat does not mean hiding your history. It means using the space wisely. A current backend role with strong production work may need five bullets. A role from six years ago may need one bullet or just a concise listing. The page is limited, so the strongest evidence should get the most room.\n\nInside each role, bullets should show what you built, improved, fixed, led, or owned. A hiring manager is trying to answer practical questions: Did you work on real systems? Did you make good technical decisions? Did your responsibility grow? Can you do the kind of work this team needs?\n\nThis chapter is about the section around those bullets: role order, job headers, how many bullets to use, what to keep from older jobs, and how to handle internships, contracts, and short roles.\n\nThe guiding idea is simple: make your timeline easy to understand and your best work easy to find.\n\n---\n\n# Structuring Each Role\n\n### Use reverse chronological order\n\nList your most recent role first, then work backward. This is what recruiters and hiring managers expect, and it helps them understand your career timeline quickly.\n\nThere are rare cases where grouping by relevance can make sense, such as returning to software after a different kind of role. But for most engineering resumes, reverse chronological order is the clearest choice.\n\n### Use one job-header format\n\nKeep every role header consistent. Use the same order each time: job title, company, location if useful, and dates.\n\nFor example:\n\n\n```javascript\nSenior Software Engineer, Acme Corp, Bengaluru | Jan 2021 - Present\n```\n\n\nThe exact format is up to you. The important part is consistency. When the reader scans down the page, they should not have to relearn the structure for every role.\n\nUse normal date ranges such as \"Jan 2021 - Present\" or \"2021 - 2024.\" If a role was remote, contract, part-time, or an internship, label it plainly. Clear labels are better than making the reader guess.\n\n### Give more bullets to recent, relevant roles\n\nAs a starting point:\n\n- current or most recent role: 3-5 bullets\n- previous role: 2-3 bullets\n- older roles: 1-2 bullets\n- very early roles: one line or one strong bullet\n\nThis is not a strict rule. If an older role is highly relevant to the job you want, give it the space it deserves. If your current role is less relevant, keep it clear but shorter and give more room to the work that supports your target role.\n\nDo not give every role the same number of bullets just to make the resume look balanced. The resume should be useful, not symmetrical.\n\n### Keep accomplishments, not routine duties\n\nEvery role has routine duties: standups, bug fixes, code reviews, documentation, meetings, sprint planning. Some of those can matter, but only when you explain the outcome.\n\nWeak:\n\n\n```javascript\n- Participated in code reviews and fixed bugs.\n```\n\n\nStronger:\n\n\n```javascript\n- Reduced repeat production bugs by adding review checklists and expanding\n integration tests around the payment flow.\n```\n\n\nThe stronger version tells the reader what changed because of the work.\n\nThis does not mean every bullet needs a big metric. It means the bullet should show why the work mattered. \"Reviewed pull requests\" is routine. \"Reviewed high-risk payment changes and caught edge cases before release\" gives the reader a clearer reason to care.\n\n\n```mermaid\nflowchart LR\n A[Routine duty
Reviewed pull requests]:::dim --> B[Add the outcome
What changed?]:::step\n B --> C[Accomplishment
Caught payment edge
cases before release]:::good\n classDef dim fill:#ffd43b,stroke:#000,color:#000\n classDef step fill:#00ceff,stroke:#000,color:#000\n classDef good fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe duty on its own tells the reader what you were assigned. Attaching the outcome turns the same activity into evidence of judgment and care.\n\n### Include internships when they add evidence\n\nInternships belong in the experience section when they include real engineering work. Label them clearly as internships, and write bullets the same way you would for a full-time role.\n\nIf you are early in your career, a strong internship may be one of your best signals. If you are several years into full-time work, older internships can usually be shortened or removed.\n\n### Label contracts clearly\n\nContract work is normal. Mark it clearly so the timeline makes sense:\n\n\n```javascript\nBackend Engineer, Northstar Health (Contract) | Mar 2023 - Sep 2023\n```\n\n\nIf you had several short contracts, you can group them under one heading when that makes the resume easier to read. The goal is not to hide anything. The goal is to avoid turning the experience section into a long list of tiny entries.\n\n### Handle short roles with judgment\n\nA short role can still belong on your resume if it is recent, relevant, or helps explain your timeline. Keep it concise and focus on the work you actually did.\n\nIf a short role was unrelated and leaving it off does not create a confusing gap, it may be fine to omit it. If omitting it creates questions, include it briefly and be ready to explain it simply in an interview.\n\n### Use stack lines only when they help\n\nA short stack line can help when technologies changed meaningfully between roles:\n\n\n```javascript\nStack: Go, PostgreSQL, Kafka, Kubernetes, AWS\n```\n\n\nUse this only if it adds clarity. If the stack line repeats your skills section without adding role-specific context, skip it and save the space for stronger bullets.\n\nHere is a simple way to think about space in the experience section.\n\n\n```mermaid\nflowchart TB\n A[Current role
3-5 bullets]:::current --> B[Previous role
2-3 bullets]:::prev\n B --> C[Older role
1-2 bullets]:::old\n C --> D[Earliest role
1 line]:::oldest\n\n classDef current fill:#69db7c,stroke:#000,color:#000\n classDef prev fill:#38d9a9,stroke:#000,color:#000\n classDef old fill:#00ceff,stroke:#000,color:#000\n classDef oldest fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThe taper is a default, not a rule. Space should follow relevance and strength. Recent work usually matters most, but there are exceptions.\n\n---\n\n# From Paragraph to Bullets\n\nHere is a role written as a paragraph. It has useful material, but the reader has to work too hard to find it.\n\n**Bad:**\n\n\n```javascript\nSenior Engineer, Acme Corp, 2021 - Present\nI was responsible for the billing platform where I worked on many features\nand fixed bugs and also mentored junior engineers and participated in\non-call rotations and helped improve the overall system performance over\ntime while collaborating with product and design teams.\n```\n\n\n**Better:**\n\n\n```javascript\nSenior Engineer, Acme Corp, 2021 - Present\n- Reduced billing reconciliation time from 6 hours to 35 minutes by\n replacing a nightly batch job with an incremental pipeline.\n- Cut invoice-related support tickets by 28% by fixing rounding behavior\n that affected monthly billing reports.\n- Mentored 3 junior engineers through design reviews, pairing sessions, and\n onboarding plans.\n```\n\n\n**Why the better version works:** The bullets separate the main accomplishments and make each one easier to evaluate. The reader can see the problem, the work, and the result without sorting through a long sentence.\n\nNow here is an older role taking more space than it needs.\n\n**Bad:**\n\n\n```javascript\nJunior Developer, OldStartup, 2016 - 2018\n- Wrote unit tests for the web application\n- Attended daily standup meetings\n- Fixed bugs reported by the QA team\n- Updated documentation for internal APIs\n- Helped with the migration to a new framework\n```\n\n\n**Better:**\n\n\n```javascript\nJunior Developer, OldStartup, 2016 - 2018\n- Expanded unit test coverage from 20% to 70% for the customer dashboard,\n reducing repeat regressions during monthly releases.\n```\n\n\n**Why the better version works:** The shorter version keeps the strongest point and removes routine duties. That leaves more space for recent roles, where the hiring manager is likely to spend more attention.\n\n---\n\n# Mistakes That Cloud Your Timeline\n\nA recruiter spends only a few seconds on the experience section, so the habits below hurt most because they make your strongest roles harder to find in that short window.\n\n- **Writing roles as paragraphs.** Paragraphs make accomplishments harder to scan. Use bullets.\n- **Giving every role the same amount of space.** Recent and relevant roles usually deserve more room than older ones.\n- **Keeping routine duties.** Do not list normal job activities unless you can connect them to a useful result.\n- **Using inconsistent job headers.** Changing date formats, title order, or spacing makes the timeline harder to follow.\n- **Handling short roles too defensively.** Include short roles when they matter, omit them when they do not, and be honest either way.\n- **Hiding strong internships.** Early in your career, a good internship can be valuable experience.\n- **Repeating the same stack everywhere.** Stack lines help only when they add role-specific clarity.","pageType":"job-search"}

Get Premium