Resume for Software Engineers: Projects vs Work, Explained

A recruiter screening SDE resumes for a Bangalore product company spends under 20 seconds on the first pass. In that time, they're not reading your objective statement or your list of soft skills — they're scanning for what you built, what stack you used, and whether your last role sounds like it involved actual engineering. Get the projects-vs-experience balance wrong and you lose that window before they even reach your skills section.

Projects vs. work history: what to lead with at each stage

The right balance depends almost entirely on how many years of real engineering work you have. Treat this as a hard rule, not a preference.

Freshers and final-year students (0 years experience)

Projects are your resume. If you're applying straight out of a B.Tech or MCA program with no full-time offer yet, lead with 2-3 projects that show you can ship something end-to-end, not just complete a college assignment. A single well-documented project with a live deployment link and a GitHub repo beats five half-finished ones listed as bullet points.

• Pick projects that solve a real (even small) problem — a hostel mess attendance tracker used by 40 students beats a generic to-do app clone.
• Include a live link or GitHub repo for every project — recruiters at companies like Razorpay or Zoho will actually click.
• Mention internships even if unpaid or short (4-6 weeks) — they carry more weight than a fourth project.
• Skip the 'objective' section entirely. Use that space for one more project or a stronger skills list.

1-3 years of experience

Work history takes over as the primary section. Projects move down and shrink to one or two entries — usually a side project or open-source contribution that shows initiative outside your day job. If your current role is at a service-based company like TCS or Infosys and you're not getting to build much, be honest about that in interviews, but on the resume, extract every piece of real engineering work you did, even if it was inside a larger maintenance project.

4+ years and senior engineers

Drop personal projects almost entirely unless they're genuinely impressive (a published npm package with real downloads, an open-source project with contributors you don't know personally). At this stage, a hiring manager wants to see ownership: did you lead a migration, mentor juniors, make architecture calls, own an on-call rotation. Two or three roles described with real depth beat five roles skimmed in one line each.

How to list your tech stack (without turning it into a keyword dump)

Don't write one giant paragraph listing every language, framework, and tool you've ever touched. It reads as padding and it fails ATS parsing on many portals used by Indian companies, including Naukri's internal matching. Structure it instead.

• Group by category: Languages, Frameworks/Libraries, Databases, Tools/Platforms, Cloud.
• Order within each category by actual proficiency, not alphabetically — put what you're strongest in first.
• Only list what you can defend in a live coding round or system design discussion. Listing Kubernetes because you followed one tutorial will get exposed in five minutes.
• Tie the stack to the project or role it was used in wherever possible, rather than listing it as an isolated block with no context.
• If you're targeting a specific stack (say, a Node.js backend role), reorder the list so that stack sits first, even if your strongest skill technically lies elsewhere.

Quantifying engineering impact

"Worked on backend APIs" tells a recruiter nothing. Every bullet point on an SDE resume should answer: what did you build, what was the scale or constraint, and what changed because of it. If you don't have exact numbers, a defensible estimate is far better than nothing — recruiters expect approximations, not audited figures.

• Instead of 'Optimized database queries' — 'Reduced average query latency from 800ms to 120ms on a table with 4M+ rows by adding composite indexes and rewriting three N+1 queries.'
• Instead of 'Built a notification system' — 'Built a push notification service handling 50,000+ daily events across iOS and Android using Firebase Cloud Messaging and a Redis queue.'
• Instead of 'Improved test coverage' — 'Increased unit test coverage from 34% to 78% over two sprints, cutting production hotfixes by roughly half the following quarter.'
• Instead of 'Worked in an agile team' — 'Shipped 12 features across 6 two-week sprints as one of three backend engineers on a team serving 200K MAU.'

If your work genuinely had no measurable metric — common in early internal tools or backend refactors — quantify scope instead: number of services touched, lines of legacy code migrated, number of engineers who now depend on what you built. Scope is still a number, and it's still more convincing than an adjective.

One last check before you submit

Read your resume back and cut any line that would be true of literally any engineer on your team. If a bullet point could sit unchanged on your teammate's resume, it's not specific enough yet. That single filter, applied honestly, fixes most SDE resumes faster than any template swap.