When every credential a candidate presents can be manufactured
Technical screening rests on artefacts a candidate controls: what they say they did, a profile they wrote, and a repository they populated. Each was a weak signal that worked because forging it took effort.
What screening signal survives cheap generation?
Almost none of the ones in use. A CV, a profile and a repository are all self-asserted artefacts, and all three are now cheap to manufacture convincingly. What survives is anything a third party signed — an employer, a client, a maintainer — because that requires compromising someone else.
- Every artefact in technical screening is self-asserted, and generating a plausible version of each is now inexpensive.
- Repository history is the most trusted and among the easiest to fabricate, because commit dates are attacker-controlled fields.
- Verifiable contribution — attested by the party that accepted the work — is a different class of evidence and is achievable incrementally.
Part of Remote workforce identity
What screening actually relies on
| Artefact | Who asserts it | Cost to fabricate |
|---|---|---|
| CV | The candidate | Minimal, and always was |
| Professional profile | The candidate | Low — including plausible connections |
| Portfolio site | The candidate | Low |
| Code repository | The candidate | Low — including backdated history |
| References | The candidate selects them | Moderate — requires a cooperating person |
| Technical interview performance | Observed | Moderate — requires ability or a proxy |
The fourth row deserves attention because it is the artefact screeners have come to trust most, on the reasoning that code does not lie.
Why repository history is weak
Commit timestamps are fields in the commit object, set by the committing client. They can be any value.
# Commit dates are inputs, not observations
GIT_AUTHOR_DATE="2019-04-11T09:22:00" \
GIT_COMMITTER_DATE="2019-04-11T09:22:00" \
git commit -m "initial parser implementation"
# Result: a repository with three years of plausible history,
# created this afternoon.Combined with generated code and generated commit messages, a convincing multi-year project history is an afternoon's work. Contribution graphs on hosting platforms reflect these dates, so the visual signal reproduces the fabrication faithfully.
What cannot easily be faked is interaction: pull requests reviewed by other people, issues discussed, contributions merged into repositories the candidate does not control.
The signal that survives
Attestation by a party other than the candidate. Not because those parties are infallible, but because obtaining a false attestation requires a cooperating third party — which is the cost that fabrication removed everywhere else.
- A contribution merged by a maintainer who is not the candidate
- A review performed on someone else's code, with the review visible
- An employer confirming the work, bound to a specific project and period
- An open source project attesting to a contribution's authorship
None of these is available in the form a screener needs today, which is the gap.
What a contribution attestation would look like
{
"attestation": "code_contribution",
"contributor": "[credential id enrolled to the candidate]",
"repository": "github.com/org/project",
"commits": ["7f3a91c8...", "c19e4a77..."],
"merged_by": "[maintainer credential id]",
"merged_at": "2025-08-14T11:02:00Z",
"role": "author",
"signature": "..." # by the maintainer, not the author
}The load-bearing element is who signs. An attestation signed by the contributor is a CV entry with extra steps; one signed by the party who accepted the work is evidence.
What employers can do now
The ecosystem-wide version does not exist. Two things are available immediately.
- Weight interaction over volume. A candidate with twelve merged pull requests into projects they do not own is a stronger signal than one with three years of solo commits, and the distinction is visible today.
- Attest your own leavers. When an employee leaves, issue them a signed attestation of what they worked on, in what role, over what period. It costs almost nothing and it is a genuine benefit to them.
The second is how this bootstraps. An attestation is only useful if employers issue them, and an employer that issues them to leavers gets to receive them from candidates.
The obvious objection
A verification regime in hiring disadvantages people without conventional backgrounds: career changers, self-taught engineers, people from smaller markets, anyone whose work was not in a public repository.
This is a real cost and it should shape the design. An attestation should be one supporting signal, not a gate. A candidate without one should be assessed on work they do for you — a paid trial, a take-home, a pairing session — which was always the better signal and is unaffected by any of this.
The purpose is to reduce the weight placed on artefacts that no longer carry information, not to add a barrier in front of the ones that do.
A worked example: two candidates, same evidence
| Evidence | Candidate A (real) | Candidate B (generated) |
|---|---|---|
| CV | Consistent, well written | Consistent, well written |
| Public profile | Complete, with endorsements | Complete, with endorsements |
| Repository | 40 commits over 8 months | 40 commits over 8 months, backdated |
| Code quality | Good | Good — generated code often reads better |
| Third-party signature | Merge countersigned by a maintainer | None |
Every row but the last is indistinguishable, and the last row is the only one whose forgery requires compromising an account that is not the candidate's.
Objections and honest limits
“Commit timestamps are checkable.” They are author-controlled. A repository's history can be written in an afternoon with any dates you like, and the platform's own timestamps only record when it was pushed.
“This disadvantages people without an existing network.” A genuine cost. It argues for issuers that are easy to obtain from — bootcamps, open-source maintainers, short contracts — not for abandoning countersignature.
Screening for what survives
- Stop treating self-asserted artefacts as evidence. Treat them as claims to verify.
- Ask for one countersigned item. One is enough to change the economics.
- Verify the issuer's key, not the platform's badge. Badges are rendered images.
- Accept a wide range of issuers. Otherwise you screen for network, not skill.
- Bind the interview to the hire. Signature at interview, same credential on day one.
Terms used here
- Self-asserted artefact
- Evidence whose content and provenance are controlled entirely by its subject.
- Contribution attestation
- A signed statement from a maintainer or employer that a specific person did specific work.
- Issuer JWKS
- A published key set letting anyone verify a signature offline, without calling the issuer.
Frequently asked questions
Why is a code repository weak evidence? Commit timestamps are fields set by the committing client. A convincing multi-year history is an afternoon's work, and contribution graphs reproduce the fabrication.
What signal survives? Interaction with parties other than the candidate — merged contributions, reviews of others' code, employer attestation. Faking those requires a cooperating third party.
Who should sign an attestation? The party who accepted the work. An attestation signed by the contributor is a CV entry with extra steps.
Doesn't this disadvantage unconventional candidates? It would if used as a gate. Treat it as one supporting signal and assess candidates without one on work they do for you, which was always the better measure.
Is repository history still useful? As colour, not evidence. Author dates are attacker-controlled and generated code is often cleaner than the real thing.
What makes a countersignature different? Forging it requires compromising an account that is not the candidate's — a second, independent obstacle.
Does this disadvantage newcomers? It can, which is why the set of acceptable issuers should be broad: bootcamps, maintainers, short contracts, volunteer work.
Where this fits in Manav
Manav lets an employer, maintainer or client sign a statement about a named person, verifiable offline by anyone with the issuer's key.
Sources and further reading
- Git documentation on commit object fields and date handling.
- FCC — protecting consumers from SIM swap and port-out fraud
- Research on signalling and credential verification in labour markets.
- FTC — business guidance on marketplaces and consumer protection
- NIST — Digital Identity Guidelines (SP 800-63)