SDE Resume: Projects vs Work History, Stack, and Metrics

Most SDE resumes get the prioritization backwards. A fresher spends half the resume on a two-month internship doing Jira ticket cleanup, while a 5-YOE engineer still leads with a college project built in third year. The fix isn't a better template — it's matching what you lead with to how much real engineering work you actually have behind you.

Projects vs work history: the rule by experience level

Recruiters and hiring managers read resumes looking for evidence of engineering judgment, not just task completion. Where that evidence lives depends on your stage.

0–1 years (freshers, including service-company trainees)

• Projects go first, above any internship or training program, and get 3-4 bullets each — not one line.
• Pick 2-3 projects max. A resume with 6 one-line projects reads as unfinished side experiments, not depth.
• Include the problem you were solving, not just the tech used. 'Built a hostel mess management system' means nothing. 'Built a mess attendance system handling 400 students daily, replacing a paper register that caused 15-20% billing disputes monthly' means something.
• If you did a real internship with shipped code, that moves above projects — but only if you can describe actual contributions, not 'assisted the team with testing.'

1–3 years

• Work history takes the top slot. This is where recruiters expect to see you've operated inside a real codebase and real deadlines.
• Keep one strong project only if it's genuinely differentiated — an open-source contribution with merged PRs, a side app with actual users, a hackathon win with real judges. Drop generic tutorial-based projects entirely at this stage.
• If your day job has been pure maintenance (bug fixes, support tickets), a well-described personal project still earns its place because it shows initiative your job didn't require.

3+ years

• Work history is the entire resume, effectively. Projects section shrinks to nothing or one line under 'Additional' unless it's something like a published npm package with real downloads or a tool your own team adopted.
• At this stage, a resume still leading with college projects actively signals stagnation — it reads like nothing noteworthy has happened in your job since.

Listing tech stacks without the word-salad effect

The most common stack mistake is a single dense line: 'Java, Spring Boot, React, Node.js, MongoDB, PostgreSQL, Docker, Kubernetes, AWS, Redis, Kafka.' It tells a reviewer nothing about depth and invites exactly the kind of interview question you can't answer — 'walk me through how you used Kafka here.'

• Attach tech to the work, not to a generic skills block. 'Migrated the order service from MySQL to PostgreSQL to fix write contention during flash sales' says more than listing PostgreSQL in isolation.
• If you do keep a separate skills section (useful for ATS keyword matching), group it: Languages, Backend/Frameworks, Databases, Infra/DevOps, Tools. A flat list across all categories looks careless.
• Only list what survives a 10-minute grilling. If you used Kubernetes once to deploy a toy app following a YouTube tutorial, don't list it next to a skill you've debugged in production for a year — a good interviewer will find the gap fast.
• Order roughly by proficiency, not alphabetically. Recruiters and ATS parsers both tend to weight the first few terms more.

Quantifying impact when you don't have dashboard access to prove it

"Improved performance" and "optimized the codebase" are the two most common and least useful phrases on SDE resumes. The fix isn't always a bigger number — it's picking the right unit of measurement for your kind of work.

• Backend: latency (p95 response time cut from 800ms to 220ms), throughput (handled 3x traffic during a sale event without scaling infra), cost (reduced AWS spend by ₹40,000/month by rightsizing EC2 instances).
• Frontend: load time (reduced first contentful paint from 4.2s to 1.8s), bundle size (cut JS bundle by 35% via code splitting), conversion (A/B test showed 8% lift in signup completion).
• Data/ML: model accuracy, inference latency, data volume processed (pipeline handling 2 crore events/day), or time saved versus a manual process.
• Mobile: crash-free rate, app size, Play Store rating movement after a release.
• If you're in a service-based company doing maintenance work on a client project and genuinely have no access to production metrics, quantify scope instead of outcome: number of tickets resolved per sprint, size of the codebase you worked in, number of modules you owned, volume of records a migration script touched. Scope is honest and still specific — fabricating a latency number you never measured is not, and it falls apart in the interview.

The through-line across all three sections is the same: match the claim to what you can actually defend in a 45-minute technical screen. A resume that promises less but holds up under questioning beats one that impresses for thirty seconds and collapses after the first follow-up.