When you hire developers, you cannot rely on a CV, portfolio, interview impression or coding session alone. Presentation and actual work do not always match. Application fraud in software development starts with embellished profiles, extends to outside help with tasks, and includes work samples where authorship, responsibility and depth of involvement remain unclear. For recruiters and HR, the task is therefore not only to identify deception, but to set up fair, repeatable and transparent checks. Assessment becomes more robust when, alongside self-reported claims, you also look at real developer work — including its traces in repositories. This is exactly where free repo audits for developers, verification for companies and the Proof Engine methodology come in; the model behind this is also explained in the pricing overview.
What application fraud among developers looks like today
Application fraud in the developer space is often less spectacular than a completely invented CV. More common are mixed forms: profiles are heavily exaggerated, positions sound more senior or responsible than they really were, references are adopted vaguely, or demo repositories are prepared in a way that makes them appear to reflect more personal contribution than they actually do. There is also support from third parties in interviews or take-home tests.
Typical patterns include, for example:
- Experience with frameworks or architectures is presented as more extensive than the person’s actual role would justify.
- Repositories serve as shop windows, even though their origin, maintenance and ownership remain unclear.
- Tasks in the application process are completed with external help, without that being disclosed.
- Third-party or borrowed code is presented as if it were the candidate’s own work; the guide to third-party code explains what can give this away.
Particularly in software development, a convincing appearance can conceal these issues. Someone who uses technical terminology confidently, mentions familiar tools and presents projects neatly will quickly seem plausible. But that still says little about how deeply they have actually worked in the code, taken responsibility for changes or carried technical decisions.
Remote processes intensify the problem. When assessment, interview and task all take place digitally, it becomes harder to judge independence. You can find more on this in remote hiring processes.
An important distinction is needed here: research, documentation, standard tools and AI assistance are not automatically problematic. It becomes critical where performance, authorship or degree of responsibility are misrepresented. In practice, it is therefore worth looking at warning signs in pull requests, in ownership and in AI-supported work, without treating any single signal as conclusive.
Why CV, interview and coding test are often not enough
A CV is a useful document in hiring, but only a weak signal. It condenses positions, roles and technologies into a self-description. What it usually lacks is a robust answer to other questions: how does someone actually work in code? How do they deal with changes, defects and legacy systems? And at which points have they genuinely supported technical decisions rather than merely referring to them?
Interviews also have clear limits. They show whether someone commands technical language, can explain relationships and appears structured in conversation. That matters, but it remains a snapshot. Whether someone develops consistently over weeks or months, isolates problems cleanly and takes responsibility in an ongoing project can only be inferred from this to a limited extent.
The same applies to take-home tests and live tasks. They can be prepared, influenced or completed with outside help. They also often reflect an artificial situation:
- a clearly defined task
- little historical context
- hardly any grown dependencies
- rarely any real maintenance pressure
That is precisely why a single code snippet or GitHub link often says less than it first appears to. Without history, the context is missing. Contributions only become more meaningful when you look at changes, iterations, discussions and the technical consequences of decisions. If you want to go deeper, the technical assessment of developer work provides a suitable framework.
There is also an important distinction: ability is not the same as ownership. Someone may explain a concept, pattern or implementation convincingly without having built it, developed it further or been responsible for it over the long term. Indications of this difference can often be found in pull requests and review history, in a look at the issue tracker and in questions about responsibility and ownership.
How genuine developer work can be identified more reliably
A more robust view often emerges when the assessment shifts from what is said to what has been done. Instead of mainly evaluating statements about projects, roles and responsibility, it is worth looking at the traces of real work. The version history of a repository is particularly revealing here.
It shows more than just an end result. Commits, change rhythm, intermediate states and the context of individual contributions provide clues as to who actually did the work, how continuously development took place and whether contributions are embedded in a plausible development history. Not every commit is equally meaningful, but taken as a pattern they often produce a clearer picture than an isolated project example.
Generally understandable forensic signals include, for example:
- implausible authorship in the history
- large code dumps with no recognisable development steps
- changes with little visible connection to real responsibility
- contributions whose history does not match the claimed share of the work
It is also important to note that functionality alone is not enough as a benchmark. Security aspects, the dependencies used, test coverage and the visible technical environment also say something about how someone works and how mature the way of working appears within a project. If you want to explore third-party code and its traces, or the assessment of real developer work, in more depth, those are useful next steps.
Assessment usually becomes more meaningful when several perspectives come together: technology, security, performance, architecture and craftsmanship complement one another. This is more likely to produce a balanced assessment than a single judgement or one strong signal alone. The methodology page explains in detail how such an assessment path can be structured.
Even so, the assessment remains a probabilistic statement. Even a good review does not provide absolute knowledge, but a transparent judgement with uncertainty.
How Acquispect compares application claims with evidence of work
Acquispect starts at a different point from traditional application documents. Instead of primarily assessing the CV, developers have their Git repository audited and receive a verifiable proof from it. For recruitment and HR, this creates an additional view of real work traces — in other words, of what can actually be traced through the development history.
The assessment path consists of three stages:
Stage A: Ghostwriter Detector Here, the .git history is analysed forensically. The review checks who authored commits, whether code may have been added to a repository in bulk, and how the contribution is classified through an impact score. So the point is not just whether code exists, but whether its origin and attribution appear consistent.
Stage B: Safety Check At this stage, the audit looks at leaked secrets, known vulnerabilities in dependencies, test coverage and the tech stack used. So, alongside authorship and history, signals relating to technical diligence and security level also feed into the assessment.
Stage C: Panel of five AI expert personas The perspectives of Tech Lead, Security, Performance, Architect and Craftsman arrive at a shared verdict with a confidence score. The result is therefore not absolute certainty, but a transparent assessment with stated uncertainty.
Important for HR departments: the result is not a raw data collection for companies. What is verified is the verdict, not the entire repository in plain text. The proof is sealed as a tamper-proof W3C Verifiable Credential via did:web in the developer’s wallet; the developer owns it.
If a company wants to verify the proof, this happens selectively and only when needed. It sees the verdict and can read the full audit log for context, without needing blanket access to all raw data. Particularly when teams compare an offer, such an assessment path helps to separate claims and evidence of work more clearly.
This gives HR and recruitment an additional, transparent step between self-reported claims and detailed technical review.
Common questions from recruitment and HR
Does a repository audit replace the technical interview?
No. A repository audit is not a replacement for the technical interview, but an additional assessment path. The interview remains important for judging communication, decision logic and collaboration. The audit complements that impression with verifiable signals from real developer work.
In practice, this means:
- Interview and technical discussion show how someone thinks and explains.
- The audit shows what traces the work leaves in the repository.
- Together, they create a more complete picture than either method alone.
Does our company see the full source code during verification?
No. During verification, a company sees the verdict, not the raw data of the entire repository. The proof is sealed as a W3C Verifiable Credential via did:web in the developer’s wallet and is held by the developer.
Verification is selective. This means the company verifies the proof when needed, sees the verdict and can read the full audit log for context. It does not automatically receive access to the complete source code.
How binding is a verdict with confidence score for a hiring decision?
A verdict with confidence score is not an absolute statement and does not replace a hiring decision. It is a transparent judgement with stated uncertainty. For recruitment and HR, it is primarily useful as an additional signal.
A sensible way to interpret the result is:
- as a basis for follow-up questions
- as a supplement to interview and references
- as a way to compare self-reported claims with evidence of work
Who pays for the audit and how does the model work without a subscription?
For developers, the audit is free. Companies pay per verification. No subscription is required; the verifier pays. For larger requirements, an enterprise offering is available on request.
This keeps the model separate:
- Developers obtain the proof at no cost.
- Companies pay when they want to verify a proof.
Conclusion: fewer claims, more verifiable work
Application fraud among developers is difficult to detect through documents, conversations and tests alone. Much of this can be prepared, staged or supported with outside help. That is precisely why selection becomes more robust when not only claims are checked, but also the traceable evidence of genuine development work.
The most helpful signals are those from the actual course of the work:
- repository history and authorship
- safety checks for secrets, known vulnerabilities, test coverage and tech stack
- an overall AI assessment from 5 perspectives with a confidence score
Acquispect positions exactly this assessment path as an additional proof: not as a replacement for interview and technical evaluation, but as an evidence-based complement. For recruitment and HR, this can help make decisions more transparent without treating a single signal as certainty.