software developer CV: that is exactly how this text begins, because many recruiters and engineering leads are looking for a quick, reliable way to assess one. A CV is useful as an overview, but weak as evidence of actual ways of working, code quality and individual contribution. The key question is: which statements in a CV genuinely help, which remain vague, and how do you move from claims to verifiable evidence?
This article covers the following:
- typical signals in a CV
- the limits of the document
- a practical way to check real work through a Git repository
If you want to explore this in more depth, you can find more on the Proof Engine methodology, the page for companies, the page for developers and the pricing model.
What a CV actually does for software developers
In developer hiring, a CV is above all an orientation document. It shows career stages, roles, time periods, technologies used and often the product or domain context as well. That helps you assess a profile quickly: who has mainly worked on internal business applications, who on platforms, who in regulated environments, and who in small product teams?
Even so, the signals in a CV should be weighed carefully.
- Roles and titles such as Software Engineer, Senior, Full Stack or Tech Lead are only comparable to a limited extent across companies.
- Technology lists initially show points of contact with a stack, but not automatically depth, recency or quality of work.
- Project descriptions often name goals, results and areas of responsibility, but rarely separate an individual's code contribution clearly from the team's contribution.
That is exactly why caution is sensible when drawing quick conclusions. Many skill lists read strongly, but say little about what someone actually implemented, reviewed, tested or maintained over time. If you want a better understanding of what tests and test coverage really indicate, you can assess tests as a signal in more detail.
You should also avoid overrating gaps, frequent moves or very linear careers in isolation. Without context, such patterns say little about technical substance. That applies particularly to assessing remote profiles and to junior profiles with only a few years of experience.
A practical rule of reading is therefore this: read the CV as a map, not as a piece of evidence. For questions of authorship and actual changes, it is more helpful later on to read commit histories properly.
Typical misinterpretations in developer CVs
Many misjudgements arise not because a CV is badly written, but because certain signals are read too quickly as evidence. In developer profiles especially, technical language often appears more precise than it really is.
Terms such as microservices, Kubernetes, AI or scaling sound strong. Without a link to concrete tasks, though, they remain vague. Was the person responsible for architectural decisions, did they build services themselves, support deployments, or simply encounter the topic within a team environment? The word on its own does not answer that question.
The same applies to long skill lists. They often show breadth and touchpoints, but not automatically depth. Whether someone used a tool once, operated a system with it, or was responsible for key decisions around it usually remains open.
You should be particularly careful with wording such as:
- “co-responsible for …”
- “involved in …”
- “worked on …”
Such statements may be accurate and still only outline the person's own contribution very roughly. For selection, however, what matters is what the person themselves delivered, changed, tested or improved.
Certificates, courses and self-assessments are also of limited help when the aim is to assess concrete engineering work. They show learning paths or interests, but not automatically the quality of real changes in code.
There is also a common halo effect: well-known employers or well-known products influence perception, but say little about the individual's own code contribution.
GitHub links in a CV are useful, but in practice they are often checked manually, inconsistently and therefore in a way that is hard to scale. That matters particularly in remote hiring.
The more important question is therefore not: does the CV look good? But: which statement in it can I verify against real work?
What recruiters and engineering leads should assess instead
Rather than treating the CV as the main piece of evidence, it helps to use a simple alternative model with three assessment questions:
- Did the person actually write the code themselves?
- Is the work technically sound?
- How robust is the overall judgement?
The first question is about individual contribution and authorship. That is central in developer work. In team projects, a CV quickly blurs who actually delivered what. On top of that, copy-paste, reused building blocks or large blocks of external code are not visible in a CV. Anyone hiring therefore needs a signal that sits closer to the actual changes than to the wording in the profile.
The second question concerns security and quality aspects of the real work. Whether secrets can be found in the repository, whether dependencies contain known vulnerabilities, what the test coverage looks like, and which tech stack actually appears in the code says more about ways of working and care than a simple list of tools. If you want a more precise understanding of tests and test coverage as a signal, you can assess tests properly as a work sample.
The third question is how resilient the overall picture is. A structured professional assessment from several perspectives is usually more meaningful than a single impression from a cover letter, screening call or short interview.
What matters here is choosing evidence in such a way that recruiters and engineering leads are looking at the same signal. Otherwise, separate assessment standards emerge.
For the process, that means: less gut feeling, a clearer basis for discussion and better follow-up questions in the interview.
From CV to verifiable evidence: Git instead of claims
A different approach is not to audit the CV itself, but the real work in the Git repository. That is exactly where the changes are made to which many statements in the CV refer indirectly. Acquispect therefore starts with the repository and checks traces of work rather than wording.
The assessment consists of three stages.
- Stage A: Ghostwriter Detector This stage analyses the .git history forensically. It looks at authorship, possible code dumps in larger blocks and an Impact Score.
- Stage B: Safety Check This looks for leaked secrets, known vulnerabilities in dependencies, test coverage and the tech stack.
- Stage C: AI Expert Panel Five AI expert personas – Tech Lead, Security, Performance, Architect and Craftsman – reach a consensus verdict with a Confidence Score.
Why are these signals relevant when assessing a developer profile? Because they help derive individual contribution and patterns of work from real changes. A CV can name projects. The commit history is more likely to show how someone worked, how contributions were distributed, and whether changes appear continuously or in larger blocks.
The second level goes a step further than typical CV information. A stack in a CV says little about whether, for example, the repository contains secrets, dependencies with known vulnerabilities, or tests at all. This is precisely where the Safety Check links technical substance with risk and engineering discipline in the actual codebase.
At the end, the result is not a claim of certain truth, but a traceable assessment with stated certainty in the form of the Confidence Score. The result is stored as a W3C Verifiable Credential via did:web in the developer's wallet. That means the evidence sits with the developer, not only in a recruiting system.
How this evidence fits into selection in practice
The CV still makes sense: as a quick introduction to career stages, roles, domains and possible topics of conversation. The evidence from the repository complements it where technical statements need to be made more robust. In this way, context is separated from evidence.
In practice, it makes sense to review the verified evidence before the technical interview or in parallel with it. Then interview questions are based not only on wording in the CV, but also on real work.
For recruiters, this is helpful because it provides a more robust signal than a purely self-written description, even without a deep pair review. For engineering leads, the audit log is particularly useful: it creates a more concrete basis for follow-up questions on
- architecture
- quality
- security awareness
- working style
The model is also clearly separated: developers are audited free of charge. Companies pay per verification, with no subscription.
Access is designed to be low-friction. Sign-in is possible with a crypto wallet or as a guest. That means the evidence can be built into existing selection conversations without replacing the CV: the CV opens the conversation, the verified evidence supports the technical assessment.
Frequently asked questions about software developer CVs
How informative is a CV for software developers, really?
A CV is useful, but only up to a point. It shows career stages, roles, time periods, technologies and often the professional context as well. That works well for an initial assessment.
It becomes weaker where the actual engineering work is concerned. A CV usually does not allow you to infer with confidence:
- how large the person's own code contribution was
- how cleanly they worked
- how they dealt with tests, dependencies or security risks
- whether the wording reflects the real work precisely
For selection, that means: yes as an overview, only to a limited extent as evidence.
How can I tell from a CV whether someone really masters technologies or merely mentions them?
From the mere mention, hardly at all. A CV only becomes more meaningful when technologies are tied to specific tasks. Descriptions such as built, migrated, tested, operated, secured or improved are helpful.
Pay particular attention to the link between the tool and the responsibility. A long list often shows contact with a stack, but not automatically depth. If it remains unclear what the person implemented themselves, the signal is limited.
Should I give GitHub or Git profiles more weight than the CV?
Not automatically more weight, but they are often more technical. A Git profile can be closer to real work than a CV. At the same time, without a clear assessment method, such profiles are difficult to evaluate consistently. Individual repositories, commits or contributions are quickly read selectively.
That is why the combination makes sense: the CV provides context, Git provides traces of work.
How can I assess a developer's individual contribution to team projects more accurately?
The core lies in the change history. Relevant questions are:
- Who authored the commits?
- Are there larger code dumps?
- What impact do the changes show?
This is exactly what Stage A at Acquispect, the Ghostwriter Detector, examines through forensic analysis of the .git history.
What does verified evidence from a Git repository give me compared with a classic CV?
It shifts the assessment from statements to evidence. Instead of simply reading project descriptions, the repository is checked in three stages: authorship and patterns in the .git history, a Safety Check for secrets, known vulnerabilities in dependencies, test coverage and tech stack, and a consensus verdict from five AI expert personas with a Confidence Score.
The result is stored as a W3C Verifiable Credential via did:web in the developer's wallet. During verification, a company sees the verdict rather than the raw data and can read the audit log. In this way, the evidence complements the CV with a traceable technical signal.
Conclusion: read the CV, but assess the work
A software developer CV is a sensible starting point. But it is not enough for the actual assessment. Individual contribution, quality and technical maturity can only be inferred from it to a limited extent.
The practical rule is:
- first assess the statements in the CV
- then check them against real work
That is exactly where Acquispect starts: not with the claim, but with the repository. The assessment produces a verifiable verdict with an audit log and Confidence Score. This turns a self-description into a traceable technical signal.
If you want to understand commit authorship and changes in Git in more depth, read Git Blame properly and in context.