What a software engineer CV needs in its first half page

The top of a software engineer resume should let a recruiter confirm three things against the posting without hunting: your stack matches, one piece of work is clearly yours, and that work had an outcome. Everything else can sit lower. "First half page" is a way of saying the part a recruiter reaches first, not a rule about how much of a CV gets read.

The rest of this piece covers why the top carries the weight, what each of the three things looks like, what can safely sit lower, and a before and after of a top section.

Why the top of the page carries the weight

A recruiter reads a CV against one specific job, and starts at the top. Whatever they find there either confirms a match or leaves them looking further down for one. The wider picture of how a recruiter judges a CV is in how a recruiter evaluates your CV.

For a software engineer the question at the top is narrow: do this person's stack and work line up with what this role builds. If the answer sits under a long skills grid or a generic summary, the recruiter has to dig for it, and evidence that is hard to find is easy to miss.

Stack match, shown not listed

Software engineer postings often name a stack, and a recruiter's first check is whether yours overlaps it. How to read a job description before you apply explains how to work out what a posting is actually asking for.

A list of languages and frameworks answers that only halfway. It says the words appear on the page, not that you used them. What closes the gap is attaching the stack to work. "Python, Django, PostgreSQL" is a list. "Built a scheduling tool in Django on PostgreSQL" is the same stack attached to something a recruiter can ask about.

Only list what you have used. A recruiter can ask about any line, and a stack you named to match the posting is the first thing that falls apart in an interview.

One piece of work that is clearly yours

Near the top, a recruiter should find one piece of work with your own part named. If it was a team effort, say which part was yours: the interface, the data model, the deployment. "Worked on a team project" leaves the recruiter unable to credit you with anything.

Whether a project without a job title counts at all is a separate question, covered in Do projects count without a job title?. The point here is placement. The piece of work that is clearly yours belongs in the part of the page a recruiter reaches first, not in the last section.

An outcome, without invented numbers

The third thing is what happened. It replaced a manual step, real people used it, it passed the tests it needed to, it was deployed and stayed up. Scale belongs on the page where it is real, such as how many people used it or how large the team was. Where there is no real figure, say what happened in words.

A number that was not true is worse than none, because a recruiter can ask about it and the whole entry falls apart. The Interview Score works the same way: it credits what a CV demonstrates and gives nothing for a claim with no evidence behind it. How the Interview Score works sets out the method.

What can safely sit lower

Once the top shows those three things, the rest is a matter of ordering by relevance to this posting. Education, older jobs unrelated to software, a long skills grid and interests can all sit lower. That is not because they do not matter, but because they matter less to this posting than the work at the top.

An older unrelated job can stay, shorter, below more relevant work. Nothing has to be removed. The test is whether the strongest evidence for this specific role is easy to find.

The top of a resume, before and after

Here is an invented resume top, written for this article and not taken from any real CV. The role is a front end developer position.

Before: the resume opens with a skills grid listing HTML, CSS, JavaScript, React, TypeScript, Git and several other tools. A summary follows, reading "Motivated developer looking for a challenging opportunity." Education comes next, and only near the bottom is a project called "Community site".

After: the resume opens with a short summary: "Front end developer working in React and TypeScript. Built the event pages for a community group's website, which its members use to find and sign up for events." Directly under it sits the same project, now with its own heading and one line: "Built the event listing and sign up pages in React and TypeScript, replacing a spreadsheet the group had used to track sign ups." The skills grid moves below, and education follows.

The skills are the same and the project is the same. What changed is order and specificity. The top now names the stack, says the interface was the candidate's own work, and says what happened. Nothing in it is more than the project actually was.

A five minute self check

Read the top of your own resume with three questions in mind.

• Is your stack attached to work, or only listed?
• Is there one piece of work where your own part is named?
• Does it say what happened, without claiming more than did?

If the top answers all three, a recruiter can confirm a match without hunting. If it answers none, the strongest evidence is probably sitting further down.

To see how the top of your resume reads against a specific posting, the software engineer resume checker compares the two and reports whether your stack, ownership and outcome are shown with evidence or only named.