Thirty seconds. That is how long your CV will hold a hiring manager's attention before they decide whether to keep reading or move on. In a market full of technically skilled engineers, a document filled with acronyms, tool names, and domain jargon does not make you stand out. It makes you invisible.
Your CV is the only chance you get to make your case before anyone has spoken a word to you. Most software engineers treat it as a record-keeping exercise — a log of companies, dates, and technologies. That is a mistake. A CV is not a history book. It is a conversation you are not present for.
Your CV is not a list of what you did. It is the story of how you thought, grew, and contributed.
What Most CVs Get Wrong
A typical software engineering CV is a reverse-chronological list of companies, role titles, and bullet points describing technologies used. It answers one question well: Where have you been? It fails completely to answer the question that actually matters: What will you bring?
Jargon-dense bullet points may impress a recruiter scanning for keywords, but the moment your CV reaches a hiring manager or a senior engineer — the person who will decide whether to call you — all those acronyms disappear into the background noise. What they are looking for is evidence of thinking, growth, and impact. They are forming a picture of a person, not a skill inventory.
The other common mistake is writing a CV that only the engineer themselves could fully understand. Domain-specific context, internal system names, team-specific terminology — none of this travels. The person reading your CV may not share your industry background, your company culture, or your technical stack. Write for them, not for yourself.
What a CV Actually Is
A great CV does two things at once: it presents you as a skilled professional and as a thinking human being. Both matter. The professional dimension answers whether you can do the job. The human dimension answers whether working with you will be worthwhile.
When a hiring manager picks up your CV, they are silently running through a set of questions. They may not articulate these questions out loud — they may not even be consciously aware they are asking them — but they are searching for signals that answer them. Your job is to provide those signals, clearly and honestly, within the space of a page or two.
Here are the eight questions your CV must answer.
The Eight Questions Every Hiring Manager Is Silently Asking
How did you add worth and quality to what you built?
Show the hiring manager what your work actually contributed to the organisation. Not "implemented feature X" — but what quality, reliability, or performance outcome that feature produced. Did a system you improved handle more load? Did a refactoring you drove reduce incidents? Connect your work to outcomes the company cared about.
How did you add value for users and customers?
Engineers often write about the internal mechanics of their work. Hiring managers want to see the external effect. Who used what you built? How did their experience improve? If you built a checkout flow that reduced cart abandonment, say so. If you optimised an API that cut response time for thousands of daily users, make that visible. Users are the reason software exists.
How did you grow — and what values drove your results?
A CV that shows only what you did tells half the story. The other half is how you operated: your work ethic, your standards, the principles you held yourself to. Did you consistently deliver under pressure? Did you take ownership without being asked? Did you hold quality standards even when cutting corners would have been easier? These patterns reveal character, and character is what a manager is truly hiring.
How did you make your peers' and manager's jobs easier?
The engineers who are most valued in any team are not the ones who just complete their own tasks — they are the ones whose work reduces friction for everyone around them. Did you write documentation that saved others hours? Did you build shared tooling that your team relied on? Did you take on a difficult integration so others could focus on their strengths? This is collaborative leverage — and it is rare.
How did you handle your own failures and mistakes?
Every engineer has had production incidents, design decisions that did not age well, and moments where they delivered less than expected. A hiring manager does not expect a flawless record. They want to see honesty about what went wrong and evidence that you owned it, corrected it, and learned from it. An engineer who cannot talk about their mistakes has either not done meaningful work or lacks the self-awareness to grow from it. Neither is reassuring.
How did you handle what you did not know?
No engineer has encountered every problem they will ever face. What matters is not the absence of knowledge gaps — it is how you responded when you found them. Did you learn a new paradigm when a project required it? Did you ask for help early enough to avoid bigger problems? Did you deliver in unfamiliar territory by building the skill you needed? This reveals intellectual honesty and growth instinct — two qualities no amount of existing expertise can substitute.
How did you invest in the growth of those around you?
For senior engineers, this question becomes critical. Did you mentor junior members of your team? Did you run knowledge-sharing sessions, write internal guides, or pair on complex problems so others could learn? Did you make the team better — not just as a technical entity but as a group of people growing in their craft? Seniority in engineering is not only about technical depth. It is about the density of knowledge and capability you leave behind.
If you led people, how did you enable them to perform and grow?
Leadership is not a title — it is a set of behaviours demonstrated consistently. If you have led teams, show the environment you created: did your team members grow under your leadership? Did you protect them from unnecessary pressure while holding them to high standards? Did you value psychological safety, honest feedback, and individual development? The best hiring managers know that a great team lead multiplies the output and capability of everyone around them. Make the case that you were that kind of leader.
Making It Concrete
The eight questions above are not a checklist to answer mechanically — they are lenses through which to review what you have already written. For each role in your history, ask yourself: which of these questions does this entry answer? Which does it leave unanswered? Where can a single sentence shift a task description into an impact statement?
You do not need to answer every question for every role. What you do need is a document where something from each question appears across your career narrative. A reader finishing your CV should have a sense not only of where you worked and what stack you used, but of who you are as a professional — your standards, your growth, your way of operating with other people.
One more thing: honesty is not a weakness here. A CV that shows honest reflection on failure, genuine credit given to teams, and accurate representation of your role in outcomes is far more credible — and far more memorable — than one that inflates every contribution into a solo achievement. Hiring managers have read thousands of CVs. They know the difference.
Use them to show not just what you did — but how you thought, how you cared, and who you became in the process. That is the CV no hiring manager ever forgets.