Free lesson · The Job Search System
The Anatomy of a Tech Resume
The Anatomy of a Tech Resume
Student: Alright Swati, I've done my discoverability audit and the resume is my focus. I have one, but I've never really thought about why it's structured the way it is. I just followed a template I found online. Can you break down what a tech resume should actually look like?
Swati: Absolutely. And I want to start by telling you something that might change how you think about your resume entirely. Your resume is not a document that describes you. It's a document that sells you. Those are very different things.
A document that describes you lists everything you've done - every technology, every project, every role. A document that sells you selects the specific things about you that make a hiring manager want to call you, and presents them in an order that's optimized for how that hiring manager reads.
Student: How does a hiring manager read?
Swati: Fast. Very fast. We covered the 6-second glance in Module 00 - Brandon is going to go much deeper on that in the next topic. But the implication for resume anatomy is this: the structure of your resume determines what gets read. If the most important information is buried on page two, it might as well not exist. The anatomy isn't arbitrary - it's engineered for how humans scan documents under time pressure.
The Section Hierarchy
Every tech resume has the same core sections, but the order of those sections changes based on career stage and what you want to emphasize. Here's the standard hierarchy:
graph TD
A["HEADER<br/>Name, Contact Info, Links"] --> B["SUMMARY (Optional)<br/>2-3 sentence positioning statement"]
B --> C["EXPERIENCE<br/>Work history with impact-driven bullets"]
C --> D["PROJECTS (If relevant)<br/>Personal or open source projects"]
D --> E["SKILLS<br/>Technical skills and tools"]
E --> F["EDUCATION<br/>Degrees and certifications"]
F --> G["ADDITIONAL (Optional)<br/>Awards, publications, languages"]
style A fill:#7950f2,color:#fff
style C fill:#51cf66,color:#fff
style E fill:#339af0,color:#fff
This diagram shows the standard tech resume section hierarchy from top to bottom. The header contains name, contact info, and links. Below that is an optional summary with a 2 to 3 sentence positioning statement. Then the experience section with work history and impact-driven bullets, which is the largest section. Projects section follows if relevant. Then the skills section with technical skills and tools. Education comes next with degrees and certifications. Finally, an optional additional section for awards, publications, and languages.
Let me walk you through each section - what it does, what goes in it, and the mistakes I see most often.
Section 1: The Header
The header is deceptively important. It's the first thing anyone sees, and it needs to do three things in one glance: tell the reader your name, make it easy to contact you, and link to your online presence.
What to include:
- Your full name (large, prominent)
- Email address (use a professional one - firstname.lastname@gmail.com, not gamer_tag_2003@yahoo.com)
- Phone number
- Location (city and state/country - not your full street address)
- LinkedIn URL (customized - linkedin.com/in/yourname, not linkedin.com/in/user-38472946)
- GitHub URL (if relevant for your career stage)
- Portfolio URL (if you have one)
Student: Should I include my photo?
Swati: No. Not in the US. In many European and Asian countries, photos on resumes are common. In the US, including a photo creates legal complications for the employer - they're trying to avoid unconscious bias in screening. Leave the photo off for US applications. Your LinkedIn has your photo - that's enough.
Warning: Header Mistakes That Cost You:
- Using a college email that will expire (john.doe@university.edu)
- Including your full address (privacy risk and unnecessary)
- Having an uncustomized LinkedIn URL (looks unprofessional)
- Putting your header in the actual document header/footer area (many ATS systems skip header/footer regions during parsing)
- Using icons instead of text labels for email and phone (ATS can't read icons)
Section 2: The Summary (Optional)
The summary is a 2-to-3-sentence statement at the top of your resume that positions you for the specific role you're targeting. It's optional - but when done well, it's incredibly effective.
Student: I thought summaries were outdated? My career counselor in college told me to remove mine.
Swati: Generic summaries are useless. "Motivated software engineer seeking challenging opportunities to leverage my skills" - that tells me nothing. It's filler that wastes precious space.
But a targeted summary is different. It answers the hiring manager's first question - "Is this person relevant to what I'm hiring for?" - before they even read your experience.
Compare these two:
Bad summary: "Passionate software engineer with 5 years of experience in various technologies. Looking for new opportunities to grow and contribute to a dynamic team."
Good summary: "Backend engineer with 5 years building distributed systems at Stripe and Razorpay. Specialized in payment processing infrastructure - designed a transaction pipeline handling 50K TPS with 99.99% uptime. Looking for senior backend roles at companies solving complex infrastructure problems at scale."
The second one does work. It tells me your domain (backend, distributed systems), your credibility (Stripe, Razorpay), your scale (50K TPS), and what you're looking for. I can decide in 3 seconds if you're a fit for my role.
Tip: The Summary Formula: "[Role] with [N] years building [domain] at [companies]. [Strongest achievement with a metric]. Looking for [target role] at [type of company/problem]."
This formula works because it front-loads the three things a hiring manager cares about: what you do, how well you do it, and what you want next. Customize it for each application - this is where AlgoInsight's AI Resume Builder saves you time by generating targeted summaries based on the job description.
Section 3: Experience - The Core
This is the section that matters most. It's where you tell the story of what you've built, what impact you've had, and how you've grown. We'll spend an entire topic on writing impact-driven bullets (Topic 03) and another on structuring this section (Topic 05), but let me give you the anatomy.
Structure per role:
Company Name | Location Dates
Job Title (Month Year – Present)
• Impact-driven bullet with metric
• Impact-driven bullet with metric
• Impact-driven bullet with metric
• Impact-driven bullet with metric
How many bullets per role?
| Years at the role | Bullets |
|---|---|
| Current or most recent role | 4–6 bullets |
| Previous role (relevant) | 3–4 bullets |
| Older roles (relevant) | 2–3 bullets |
| Very old or less relevant roles | 1–2 bullets or omit entirely |
Student: Wait - omit a role entirely? Isn't that dishonest?
Swati: No. A resume is not a legal document. It's not sworn testimony. It's a marketing document. If you had a 6-month internship at a company that's not relevant to your current career direction, omitting it isn't dishonest - it's editorial judgment. You're curating, not lying. There's a bright line: never fabricate experience you didn't have. But choosing not to include every role you've ever held is standard practice.
The experience section follows a recency principle - the most recent role gets the most space, and each preceding role gets progressively less. This is because your most recent work is the strongest signal of your current abilities.
Section 4: Projects
For experienced engineers (5+ years), this section is optional. For new grads and career switchers, this section can be more important than experience.
Student: How should I present projects differently from experience?
Swati: Projects follow a slightly different format because they don't have an employer name or a job title. Instead, they lead with the project name and a one-line description:
Project Name - Short description of what it does
Technologies: React, Node.js, PostgreSQL, Docker
• What you built and the problem it solves
• A specific metric or outcome (users, performance, scale)
• A technical highlight (architecture decision, algorithm, integration)
The key with projects is that they need to demonstrate decision-making, not just coding. Anyone can follow a tutorial and build a to-do app. What makes a project stand out is evidence that you made deliberate technical choices - "Chose PostgreSQL over MongoDB because the data model was heavily relational and required ACID transactions" is more valuable than "Used PostgreSQL as the database."
We'll go much deeper on this in Module 07 (Building Your Project Portfolio).
Section 5: Skills
The skills section is the most misunderstood section on a resume. Most candidates treat it as a comprehensive list of everything they've ever touched. That's wrong.
Student: How should I think about it?
Swati: The skills section has two jobs. First, it's a keyword bank for ATS matching - the ATS scans this section for specific technologies and skills from the job description. Second, it's a quick-reference for the human reader - when Brandon picks up your resume, he glances at the skills section to calibrate what technologies you work with.
Neither of those jobs requires you to list 40 technologies. In fact, listing 40 technologies hurts you because it signals that you're either inflating your skills or that you're a generalist with no depth.
graph LR
subgraph "❌ Bad Skills Section"
A["Languages: Python, Java, JavaScript,<br/>C++, C, Ruby, PHP, Perl, R, MATLAB,<br/>Bash, Go, Rust, TypeScript, Kotlin,<br/>Swift, Scala, Haskell"]
end
subgraph "✅ Good Skills Section"
B["Languages: Java, Go, Python<br/>Infrastructure: AWS (EC2, S3, Lambda),<br/>Kubernetes, Docker, Terraform<br/>Databases: PostgreSQL, Redis, DynamoDB<br/>Tools: Git, Jenkins, Datadog, Grafana"]
end
style A fill:#ff6b6b,color:#fff
style B fill:#51cf66,color:#fff
This diagram compares two skills sections side by side. The bad example lists 18 programming languages in a single undifferentiated block, which looks inflated and lacks focus. The good example organizes skills into four categories: Languages (Java, Go, Python), Infrastructure (AWS services, Kubernetes, Docker, Terraform), Databases (PostgreSQL, Redis, DynamoDB), and Tools (Git, Jenkins, Datadog, Grafana). The good example is focused, categorized, and credible.
Organizing your skills section:
Group by category - Languages, Frameworks, Infrastructure/Cloud, Databases, Tools. List 3 to 5 items per category. Only include technologies you could discuss confidently in an interview. If you haven't touched a technology in 2+ years and couldn't answer basic questions about it, remove it.
Important: Your skills section sets the interview agenda. Every technology listed on your resume is fair game for interview questions. If you write "Kubernetes" on your resume, an interviewer can and will ask about pod scheduling, service discovery, or horizontal pod autoscaling. Only list skills you're prepared to defend. This is advice that applies to your resume AND to your AlgoInsight technical prep - know what you're claiming, and be prepared to back it up.
Section 6: Education
Education placement depends entirely on career stage.
New grads: Education goes near the top - after the header and summary, before experience. Your degree is your primary credential. Include GPA if it's above 3.5 (or 8.0/10.0 in some international systems). Include relevant coursework if it directly maps to your target role. Include academic achievements - Dean's List, research publications, thesis topic.
Experienced engineers (3+ years): Education moves to the bottom. Your experience speaks louder. Include your degree, university, and graduation year. Drop the GPA. Drop the coursework. Nobody cares about your Data Structures grade when you have 5 years of production experience.
Career switchers: This is nuanced. If your degree is in a relevant field (CS, math, engineering), keep it visible. If your degree is in an unrelated field (economics, like Olena), still include it - but don't make it prominent. The education section for a career switcher should also include any coding bootcamps, online certifications, or self-study programs (like freeCodeCamp or The Odin Project). These demonstrate intentional skill-building.
Student: What about certifications? AWS Certified, Google Cloud, those kinds of things?
Swati: Include them if they're relevant to your target role. AWS certifications are genuinely valuable for cloud infrastructure roles. Google Cloud certifications matter for companies on GCP. But don't pad your resume with certifications for technologies you don't actually use - that's the same problem as the inflated skills section.
Section 7: Additional (Optional)
This section is for anything that doesn't fit elsewhere but adds value: publications, patents, speaking engagements, open source maintainer roles, language skills, awards.
Keep it brief. One to three lines maximum. This section exists to provide differentiating color, not to be comprehensive.
The One-Page vs. Two-Page Decision
Student: Everyone tells me different things about resume length. One page or two?
Swati: Here's the rule, and it's simple:
| Experience | Length | Reasoning |
|---|---|---|
| 0–7 years | One page | You don't have enough relevant experience to justify two pages. Trim ruthlessly. |
| 8–15 years | One or two pages | If you can fit it on one page without sacrificing important content, do it. If you need two, that's fine. |
| 15+ years | Two pages | You have enough career history that a single page would force you to omit significant roles. |
The common mistake is thinking more is better. It's not. A one-page resume that's tight, focused, and impactful beats a two-page resume that's padded with irrelevant detail. Every line on your resume should earn its place. If a bullet doesn't make you more attractive for the roles you're targeting, cut it.
Interview: Brandon's Take on Length:
"When I'm reviewing resumes as a Bar Raiser at Amazon, I have zero preference between one page and two pages. What I care about is signal density - how much relevant, impactful information is there per square inch? A one-page resume packed with impact-driven bullets and clear metrics beats a two-page resume full of task descriptions every time. And a two-page resume where every bullet is strong and relevant beats a one-page resume that left out important experience just to hit some arbitrary page limit."
- Brandon Carter, Amazon L7 Principal & Bar Raiser
Putting It Together
Here's what a well-structured tech resume looks like at the structural level. We'll fill in the content in the following topics - this is the skeleton:
graph TD
A["HEADER<br/>Name · email · phone · city<br/>linkedin.com/in/name · github.com/name"] --> B["SUMMARY<br/>Backend engineer, 5 years, distributed systems<br/>at Stripe and Razorpay. 50K TPS, 99.99% uptime."]
B --> C["EXPERIENCE<br/>Current Role: 4-6 bullets with metrics<br/>Previous Role: 3-4 bullets with metrics<br/>Earlier Role: 2-3 bullets with metrics"]
C --> D["PROJECTS (if relevant)<br/>2-3 projects with tech stack and outcomes"]
D --> E["SKILLS<br/>Languages · Infrastructure · Databases · Tools"]
E --> F["EDUCATION<br/>Degree · University · Year"]
style A fill:#7950f2,color:#fff
style B fill:#7950f2,color:#fff
style C fill:#51cf66,color:#fff
style D fill:#339af0,color:#fff
style E fill:#339af0,color:#fff
style F fill:#868e96,color:#fff
This diagram shows the complete resume anatomy from top to bottom. The header contains name, email, phone, city, LinkedIn URL, and GitHub URL. Below is the summary - a positioning statement with domain, years of experience, notable companies, and key metrics. The experience section is the largest, with the current role getting 4 to 6 bullets, previous role getting 3 to 4 bullets, and earlier roles getting 2 to 3 bullets, all with metrics. The projects section has 2 to 3 projects with tech stacks and outcomes. The skills section is organized by category: languages, infrastructure, databases, and tools. Education is at the bottom with degree, university, and year.
Student: This is really clear. I can already see problems with my current resume - my summary is generic, my skills section is a wall of 25 technologies, and my education is at the top even though I have 4 years of experience.
Swati: Good. That's exactly what this topic was meant to do - give you a structural map so you can see where your current resume deviates from the effective pattern. In the next topic, Brandon is going to show you exactly what he sees in those first 6 seconds when a resume lands on his desk. He's reviewed over 300 resumes as an Amazon Bar Raiser. He'll tell you where his eyes go first - and what makes him keep reading versus move to the next one.
Exercise: Starter: Take your current resume and label each section. Does it follow the hierarchy in this lesson? Is your experience section in the right place for your career stage? Is your education section in the right place?
Intermediate: Check your resume's signal density. Count the total number of bullet points across all sections. Now count how many of those bullets contain a specific metric (number, percentage, or scale). If fewer than 50% of your bullets have metrics, your signal density is low - we'll fix this in Topic 03.
Advanced: Rebuild your resume structure from scratch using the anatomy in this lesson. Don't worry about perfecting the content yet - just get the sections in the right order with the right amount of space allocated to each. Then upload it to AlgoInsight's AI Resume Builder and compare your structure against its recommendations. Note where they differ - those differences are your structural optimization opportunities.
Student: I feel like I've been looking at my resume wrong this whole time. I was thinking about what to put in it. Now I'm thinking about how it's structured.
Swati: Structure before content. Always. A great bullet buried in the wrong section is a great bullet nobody reads. In the next topic, Brandon is going to make that point viscerally clear.
Let's go.