Taking references is standard practice for many teams when hiring developers. Anyone searching for “taking references” usually wants to know which statements in the process are genuinely useful, where references reach their limits, and how developers’ work can be assessed more reliably.
For recruiters and engineering leads, the key is to distinguish between assessments that sound good and evidence that can be substantiated. Particularly in technical work, a positive impression on its own is often not enough.
A clear distinction is therefore helpful:
- References provide context.
- Evidence of real work shows substance.
That is exactly what topics such as assessing competence properly, what employment references can achieve, and what pull requests reveal are about. References can be useful, but for developers they should be supplemented by assessing real work.
What references can do when hiring developers – and what they cannot
In hiring, references usually mean statements from former employers, managers or colleagues. They describe collaboration, role, scope of responsibility and, from their point of view, a developer’s performance.
Why are such responses so common? Because they provide context that a CV alone does not. References can help clarify questions such as:
- How reliable was the person in day-to-day work?
- How did collaboration within the team work?
- How did they communicate?
- How much responsibility did they actually take on?
For recruiters in particular, these are valuable pointers. They can also be useful for engineering leads when it comes to team behaviour, coordination and ways of working. Much like formal credentials, they provide orientation, but not a complete assessment. A good complement is to look at what formal credentials can achieve.
What matters, however, is this: references are almost always condensed retrospectives. They contain memory, interpretation and the perspective of the person giving the information. That does not make them worthless, but it does limit what they can tell you.
This limitation is particularly obvious in software development. Technical quality can only be reflected to a limited extent in verbal or written assessments. A reference can say that someone was “strong” or “very good”. It still does not show how cleanly someone writes code, structures changes, identifies risks or maintains tests.
This is exactly where it helps to distinguish between behaviour within the team and technical substance. Both matter, but they are not the same thing. Anyone hiring developers should therefore see references as one building block, not the sole basis. The article on assessing competence properly also shows how competence can be assessed closer to real work.
Why real developer work is often more meaningful than a reference
Technical competence is most reliably assessed through real work, not just through self-descriptions, wording in a CV or third-party assessments. In developer roles in particular, what matters is what someone has actually built, changed and maintained.
One particularly relevant source for this is Git repositories. They do not just show that code exists, but often also how it came into being. Anyone who wants to understand developer work should therefore not look only at the final state of a codebase.
Important signals often lie in how it was created:
- how commits are structured
- how changes are organised
- whether development remains traceable
- how maintainable the code appears
- whether contributions fit consistently into the history
These traces of work are especially important in distributed teams and remote hiring. When collaboration cannot be observed on site, traceable evidence becomes more important. A repository then shows more than a brief comment from a previous role. It provides concrete indications of how someone works and what contribution they actually made. This also matters when teams want to identify application fraud more effectively or make sense of what an AI application really reveals.
Work samples are therefore closer to real work than purely theoretical questions. A good interview can explore this further, for example with interview questions about a work sample. Topics such as prompt engineering in the context of developer work can also be assessed better from real outcomes than from claims alone.
Take-home tests can provide additional clues, but they have limits. They often create artificial tasks and do not always show real work in the context of an evolved project. The article on take-home tests for developers explains more.
The key point is simple: references say what others remember about the work. A repository shows what was actually produced. If you want to understand more precisely which signals become visible there, you should also look at what pull requests reveal about developers.
How a repo audit adds verifiable evidence to traditional references
A repo audit complements traditional references where statements alone are no longer enough. Acquispect’s approach does not put the CV at the centre, but a developer’s real work in the Git repository. This gives teams an additional level of assessment: not just what is said about the person, but what can be traced in real development work. The Proof Engine methodology describes how the process is structured.
Stage A is the Ghostwriter Detector. It examines the .git history forensically and looks at three questions:
- who authored the commits
- whether code was introduced in larger blocks
- what impact the work appears to have had
For recruiters and engineering leads, this is helpful because it allows contributions to be classified more precisely. If an interview or references describe someone as having played a central part in a project, authorship and working patterns provide additional indications of how robust that statement is.
Stage B is the Safety Check. It scans for leaked secrets, known vulnerabilities in dependencies, test coverage and the tech stack. It does not replace a reference, but supplements it with signals that usually do not become visible in a verbal account at all. This gives teams a clearer view of how carefully and securely software was handled.
Stage C brings the previous signals together. A panel of five AI expert personas — Tech Lead, Security, Performance, Architect and Craftsman — reaches a consensus verdict with a confidence score. What matters here is this: the result does not claim absolute certainty. It is a verdict with stated confidence, nothing more and nothing less.
This verdict is stored as a W3C Verifiable Credential via did:web in the developer’s wallet. The credential therefore belongs to the developer. Companies can verify it when needed and see the verdict rather than the raw data; in addition, the full audit log can be reviewed. The for developers page explains how the free audit for developers works. The for companies page shows how verification works for teams. The model is straightforward: developers are audited free of charge, companies pay per verification with no subscription; more details are on the pricing page.
How teams can combine references, interviews and verification effectively
References should not be abolished in developer hiring. It is more useful to put them into a clear sequence. First come work evidence and the discussion about real developer work. Then follows a targeted reference check to add context to open questions.
This keeps the order clear:
- first, substantiated signals from work
- then the technical interview
- afterwards, references for context
Recruiters and engineering leads can take on different tasks here. Recruiting structures the process, gathers information and ensures that the process remains consistent. Technical leadership, by contrast, assesses how relevant the signals from the repository, interview and work sample really are.
Looking at contradictions is particularly important. If a reference sounds very strong but the work evidence remains vague, that should not simply be overlooked. This is where targeted follow-up questions help: What exactly did the contribution consist of? What was visibly the person’s own work, and what was more of a team effort? What responsibility actually became evident?
A verifiable assessment of work is especially useful when the CV, interview and reference do not produce an equally clear picture. It supplements statements with a traceable verdict with a confidence score, rather than simply adding further claims.
The process can also be classified clearly: developers are audited free of charge, companies pay per verification with no subscription. The model is explained in more detail on the pricing page.
Frequently asked questions about taking references for developers
At what point in the hiring process should you take references for developers?
In most cases, not right at the beginning. First, it should be clear that the role, the interview and the work evidence broadly fit together. References then help to put open points into context instead of replacing the first impression.
In practice, this means:
- after an initial professional assessment
- before the final decision
- specifically where there are open questions or contradictions
This makes the reference conversation more concrete. Instead of asking in general about a “good person”, you can check specifically whether previous collaboration matches what became visible in the process.
Which questions are particularly helpful in a reference conversation with a view to developer work?
Questions that separate observable behaviour from concrete contributions are helpful. Not just “Was the person strong?”, but: What showed that?
Useful questions include, for example:
- What kinds of tasks did the person handle independently?
- How did they deal with changes, feedback and coordination within the team?
- How visible was technical responsibility in day-to-day work?
- How were quality, tests or risks handled in the project?
- In which situations was the contribution particularly clear to see?
Follow-up questions asking for examples are useful. General assessments often sound positive, but say little about the actual developer work.
Are references enough to judge a developer’s technical quality?
No, as a rule they are not enough. References are useful for context, collaboration and perceived responsibility. But technical quality itself only becomes visible indirectly through them.
Particularly in software development, you need additional evidence from real work. A repo audit can provide more robust signals for this. At Acquispect, the Git repository is audited in three stages and turned into a verdict with a confidence score.
What does a Git repository show that a traditional reference often does not?
A Git repository makes the course of the work visible. It shows not only the result, but also how it came into being. This allows you to assess questions that a reference can often answer only in broad terms.
What may become visible includes:
- authorship of commits
- unusual code dumps
- impact of contributions
- test coverage
- known vulnerabilities in dependencies
- leaked secrets
- tech stack used
At Acquispect, this is then supplemented by a panel of five AI expert personas: tech lead, security, performance, architect, craftsman. It produces a consensus verdict with a confidence score. Companies verify this verdict when needed and see the finding rather than the raw data; the full audit log makes the assessment traceable.
Conclusion: take references, but assess developer work directly
Taking references remains useful — as long as the team is clear about which questions they can answer and which they cannot. They help with putting collaboration, responsibility and perceived performance into context. On their own, however, they are usually not enough for a technical assessment.
The decision becomes more robust when real developer work is assessed alongside statements about a person. This creates a more complete picture:
- references provide context
- work samples show concrete substance
- a verifiable audit complements both with traceable evidence
Anyone who looks at these levels together can conduct interviews more purposefully and classify contradictions more cleanly. Particularly in developer roles, the focus should therefore not be on the claim, but on what can be traced in real work and its verification.