Many companies use technical assessment to find a more reliable basis for evaluating developer work than relying solely on self-reported claims in a CV or interview. What is meant here is a technical assessment that shows what someone has actually contributed in real software work, rather than merely assessing tasks under artificial test conditions.
This is particularly important in hiring if you want to put candidates through less unpaid trial work while still needing a sound technical assessment. This article explains what that should sensibly mean, which components it includes, and how a repo-based audit with Acquispect works, from the Proof Engine methodology to credential verification for companies.
What a technical assessment should deliver
When people search for technical assessment, they usually do not mean a mere snapshot from an interview. They mean a traceable evaluation of technical work: the basis on which someone develops, how carefully changes are implemented, and which signals can be derived from real practice.
A CV, project list and self-description help only to a limited extent. They summarise roles and technologies, but often do not show how the actual work came about. Live coding, whiteboard tasks and short tests also have their limits: they usually capture only a small part of the picture and take place under conditions that do not always have much in common with real development work.
A useful technical assessment should therefore stay as close as possible to the actual work, for example by looking at:
- commits and change history
- tests and test coverage
- dependencies and their condition
- the technical evolution of a project over time
For hiring decisions, companies above all need traceable signals, not just impressions. That includes questions such as: How large is the identifiable personal contribution? How carefully is the work done? Are there signs of security awareness? What technical breadth is visible? And what overall impression does the approach create?
This is also relevant for candidates. If existing work is assessed, not every company needs to keep asking for additional unpaid tasks. If you want to see how a free repo audit for developers is described, you can find the approach there from the developer’s perspective.
What matters here is this: a technical assessment is not absolute proof of truth. It is a well-founded basis for decision-making with documented criteria. That is exactly where Acquispect starts: not with the CV, but with the audit of a developer’s Git repository. From an organisational point of view, the model is clearly set out in the pricing structure without a subscription.
Why a Git repository often shows more than a CV
In software development, the most meaningful traces of work often lie not in the CV but in the repository. That is where you find commits, authorship information, changes over time, tests and the technologies used. For a technical assessment, these are not side details but concrete indicators of how development actually took place.
The key difference from a CV is this: a CV condenses projects into roles and keywords. A repository shows contributions at code level. It makes not only the outcome visible, but also the process and the way of working: how changes were introduced, whether tests are part of the work, and which technical environment played a role.
That is precisely why work samples from an existing project are often more meaningful than one-off test tasks under time pressure. They arise in real contexts and are more likely to show how someone works in day-to-day development, rather than only how someone reacts in an artificial assessment situation.
Of course, a repository does not replace a conversation about teamwork, product understanding or communication. Those topics remain important. But a repo-based assessment complements them with technical evidence that goes beyond self-description.
For companies with many applications, this also matters organisationally: a standardised technical assessment based on repositories can create comparability without basing every judgement solely on interview impressions.
With Acquispect, developers can have their repository audited free of charge. If you want to see how this free repo audit for developers is described, you can find the explanation there from the developer’s perspective.
How technical assessment is structured at Acquispect
At Acquispect, technical assessment follows a three-stage audit framework: the Proof Engine. It does not evaluate claims about work, but traces of real developer work in the Git repository. The aim is a robust technical evaluation based on documented artefacts from the development history.
The first stage is Stage A: the Ghostwriter Detector. This carries out a forensic analysis of the .git history. It focuses on three types of signal:
- who authored the commits
- whether code was dumped into the repository in larger blocks
- an Impact Score
This stage is important for technical assessment because it helps to place the identifiable personal contribution in context. It does not provide absolute certainty, but it creates a more solid basis for understanding the plausibility of a work history. For hiring teams, this matters if they want to look not only at the end result, but also at how contributions emerged over the course of a project.
This is followed by Stage B: the Safety Check. This stage scans the repository for:
- leaked secrets
- known vulnerabilities in dependencies
- test coverage
- the tech stack
This means the technical assessment does not look only at whether software somehow works. It also takes into account aspects that matter in day-to-day development for maintainability and security. A repository may look technically interesting and still contain risks, for example through exposed credentials, vulnerable dependencies or missing test coverage. Stage B therefore adds practical quality and security aspects to the assessment.
The third stage is Stage C. Here, a panel of five AI expert personas assesses the results from the previous stages from different perspectives. These perspectives are:
- Tech Lead
- Security
- Performance
- Architect
- Craftsman
Instead of looking at just one isolated signal, this creates a combined technical assessment. The five perspectives work towards a shared verdict, which is issued with a confidence score. That is precisely how individual repository signals become a traceable technical assessment that brings together several relevant dimensions of developer work.
How verification works without disclosing raw data
After the audit, the verdict is not simply stored as an internal result, but issued as a W3C Verifiable Credential with did:web. This means the technical assessment exists in a standardised, verifiable format.
What matters here is this: the credential sits in the developer’s wallet. It therefore belongs to the developer, not permanently to the party carrying out or requesting verification. For hiring processes, this is a different approach from direct access to repository data or full project documentation.
A company then verifies the assessment when needed. It does not need ongoing access to the repository and does not receive blanket access to all raw data from the audit. Verification is designed to be selective:
- the verdict is visible
- a confidence score is issued
- the raw data from the repository audit is not disclosed
This is relevant for a technical assessment because it means the full development history does not have to be shared just to prove an assessment. At the same time, the assessment remains explainable: the full audit log shows how the result was reached, without giving up the core principle of selective disclosure.
For hiring processes, this creates a practical balance. Companies receive a traceable technical assessment, developers keep control of their evidence, and they do not need to disclose their complete work history every time.
How verification of these credentials is described from a company perspective is explained in more detail on the company page.
What this changes in practice for hiring processes
A technical assessment based on real repository work can reorganise the hiring process. Instead of starting early with abstract tasks, the conversation can first be grounded in documented technical evidence. Interviews can then become more focused, with follow-up questions about decisions, priorities, security aspects or handling changes over the course of a project.
This also changes how unpaid trial work is handled. If existing work is assessed first, additional tasks no longer need to be the default automatically. They can become the exception when something still remains unclear after reviewing the existing evidence.
What matters here is this: the assessment is one building block, not the only benchmark. It complements other parts of the process, for example:
- interviews
- references
- team fit
The model also remains clear from an organisational point of view. Developers are audited free of charge. Companies pay per verification and do not need a subscription. The pricing page shows how this model is structured.
Frequently asked questions about technical assessment
What exactly is meant by "technical assessment" in developer work?
Here, technical assessment means a traceable evaluation of real developer work. It is not just about what someone says about their work, but about the technical traces that work leaves behind. Such an assessment should help you evaluate contributions, care and technical practice more effectively. It is not absolute certainty, but a documented assessment.
Why is a Git repository often more meaningful for technical assessment than a CV?
A CV summarises. A repository shows how work actually came about. For technical assessment, that matters because it can show, among other things:
- how changes develop over time
- who authored commits
- whether tests are part of the work
- which technologies and dependencies are used
This creates a picture based on real project work rather than self-presentation alone. It does not replace a conversation, but it provides a different kind of evidence.
Which points does Acquispect check in the technical assessment of a repository?
Acquispect checks a repository in three stages. First, the Ghostwriter Detector analyses the .git history forensically: commit authorship, possible code dumping and an Impact Score. This is followed by the Safety Check, which scans for leaked secrets, known vulnerabilities in dependencies, test coverage and the tech stack. A panel of five AI expert personas — Tech Lead, Security, Performance, Architect and Craftsman — then assesses the results together and produces a verdict with a confidence score.
What does a company see during verification – and what does it not see?
During verification, a company sees the verdict and the confidence score. It does not see the raw data from the repository audit. The result exists as a W3C Verifiable Credential with did:web in the developer’s wallet. This keeps verification selective while the audit log makes it traceable how the assessment was reached.
How does a technical assessment fit into a hiring process without replacing interviews?
It works as an additional building block before or between interviews. Companies can first evaluate technical evidence and then ask more targeted follow-up questions. Conversations about collaboration, communication, responsibility or product understanding remain important. Technical assessment does not replace these points, but complements them with a structured view of real development work.
Conclusion: technical assessment closer to real work
A technical assessment is most useful when it is based on real developer work rather than on claims, keywords or interview impressions alone. For companies, this creates a more traceable basis for evaluating technical contributions.
Acquispect does this through a three-stage Git-based audit:
- Ghostwriter Detector
- Safety Check
- panel of five AI expert personas
The result is issued as a verifiable credential. The verdict comes with a confidence score and should be understood as a well-founded assessment, not absolute certainty. This creates more technical evidence for companies and less additional unpaid trial work for candidates.