What a recruiter actually scans first
A recruiter spends a few seconds on the top third of a software engineer resume before deciding whether to keep reading: your most recent title, the languages and frameworks in your skills line, and the first bullet under your most recent role. Everything below that either confirms the impression the top of the page already made or loses the reader's attention entirely.
That means the header and the first job entry carry more weight than any other part of the page. Put your strongest, most specific line first under each role rather than burying it as the third or fourth bullet, and keep the skills line close to the top so a scanning eye reaches it before moving on to the next resume in the pile.
A junior example: projects standing in for experience
A junior engineer with one internship and a few side projects can still write a complete, specific resume by treating each project like a job entry. Under a project called "Order Tracker,
âa junior candidate might write:â
Built a React and Node order-tracking app for a local cafe; added a search filter that cut average lookup time from 12 seconds to under 2." That is a specific, quoted illustration of the pattern, not a claim about a typical result.
The internship entry follows the same rule: name what changed, not just what you were assigned. A line like
âFixed 14 reported bugs in the checkout flow during a 10-week internship, three of which were blocking releaseâ
tells a reader more than "Assisted the engineering team with bug fixes." Keep this section to two or three projects, each with one or two bullets, rather than listing every repository you have ever pushed to.
A mid-level example: impact bullets that name the before and after
A mid-level engineer with three to six years of experience should replace duty-based bullets with a before-and-after number wherever one genuinely exists. For a backend role, that might read:
âCut p95 checkout latency from 1.8 s to 620 ms by batching three sequential queries into one, on a service handling roughly 40,000 requests a day.â
The number does the convincing; the sentence around it just gives it context.
A second example for a different kind of contribution:
âLed the migration of a monolith's authentication module to a separate service, coordinating with two other teams over six weeks with zero downtime during cutover.â
Not every bullet needs a percentage - a scope statement like "coordinating with two other teams" is still concrete, because it names who was involved and how long it took, rather than just calling the work "cross-functional collaboration."
When to keep a separate projects section
A dedicated projects section earns its place when you have side work that shows something your job history does not: a language you use outside of work, an open-source contribution, or a personal tool you built and still maintain. For a junior candidate it often does more work than the experience section itself; for a senior candidate it is usually optional unless the project is unusually relevant to the role you are applying for.
Keep each project entry to one line of context and one or two bullet points, the same density as a job entry, and link to the repository or a live demo if either exists. A projects section that lists ten items with no detail reads as padding; three items with one specific bullet each reads as evidence.
Skills and tools: specific, not exhaustive
List the languages, frameworks, and tools you would actually be comfortable being asked about in an interview, grouped in a way that makes sense for the role - languages, frameworks, infrastructure, and so on. Leaving off a technology you used once for a week is fine; the list should reflect what you can speak to, not everything that ever touched your resume.
Match the wording to the job posting where it is honestly accurate: if the posting says "PostgreSQL" and you used it, write "PostgreSQL" rather than just "SQL databases," since both an applicant tracking system and a human reviewer are often scanning for the exact term. Do not add a technology you have not used just because a posting mentions it - that gap surfaces in the first technical conversation.
Frequently asked questions
- Should a junior software engineer resume list projects or experience first?
- Projects first if you have limited paid experience, since that is where your strongest, most specific evidence lives; move experience above projects as soon as you have a real internship or job to show, and keep whichever section is stronger closer to the top of the page.
- How many bullet points should each project or role have?
- Two to four bullet points per entry is usually enough to show what you built and what changed as a result. More than that starts to dilute the page, and a reader tends to remember the first one or two lines under each entry far more than the fourth or fifth.
- Is it okay to reuse the same resume for every software engineering job?
- The structure can stay the same, but the skills line and the order of your bullet points should shift to match each posting's stated requirements, since both a human reviewer and an automated filter are often scanning for the specific terms that job listing uses.
- What should a mid-level engineer cut if the resume runs past two pages?
- Cut roles older than about ten years unless they are directly relevant, trim any bullet that only describes a responsibility rather than an outcome, and keep the projects section only if it shows something your work history genuinely does not already cover.