Hiring guide
How to verify a developer's skills without relying on certificates
Look for evidence that costs a lot to fake. In order: what their own code is built with and how long they have committed to it; code that maintainers of other projects reviewed and merged; a short work sample or structured technical interview scored against written criteria, with follow-up questions on their own answers; and a structured reference from a colleague reached at a verifiable work email. Treat certificates, keyword lists and self-rated proficiency as claims, not proof.
Rank evidence by how hard it is to fake.
None of these detects lying on its own. Combine two or three, and weigh each by how much effort it would take to fake.
| Evidence | What it shows | Effort to fake |
|---|---|---|
| Self-rated skill or certificate | That they say so, or passed a test once | Low |
| A specific claim ("cut p95 latency 900 to 220 ms") | A story you can probe in an interview | Low to medium |
| Their own code: dependencies and commit history | The tools they actually use, over time | High |
| A concept and approach check with follow-ups | That they understand what they claim, and how they think | Medium to high |
| A colleague at a work email confirming one claim | Someone who saw the work | High |
| Code merged into other people's projects | Strangers reviewed and accepted their work | Very high |
| An employer who interviewed them confirming it | Independent judgement after meeting them | Highest |
What the research says works.
The most recent large review of selection methods found structured interviews among the strongest predictors of job performance, with job-knowledge tests and work samples close behind, and unstructured interviews well below them. Structure means the same job-related questions for everyone, follow-up probes, and answers rated against written descriptions of what weak and strong answers look like.
Rating scales anchored in observable behaviour make different reviewers agree more than bare 1 to 5 numbers do. Write the anchors before you read any answers.
- Sackett, Zhang, Berry & Lievens (2022): revisiting the validity of selection methods, Journal of Applied Psychology
- Campion, Palmer & Campion (1997): a review of structure in the selection interview, Personnel Psychology
- Roth, Bobko & McFarland (2005): a meta-analysis of work sample test validity, Personnel Psychology
- Smith & Kendall (1963): behaviourally anchored rating scales, Journal of Applied Psychology
How to read a developer's GitHub honestly.
- Read the dependency files (package.json, requirements.txt, pyproject.toml, go.mod), not just the language bar. They show React, FastAPI, Terraform, the actual tools.
- Check that the commits are theirs and spread over time. A single bulk upload can be anyone's code; forks are someone else's work.
- Pull requests merged into other people's projects are strong evidence: a maintainer with no reason to be generous reviewed them.
- A package they publish whose registry page points back to their repository shows they shipped something others can install.
- Absence proves nothing. Most professional work is private, so treat a thin GitHub as unknown, not as a weakness.
Test understanding, now that AI writes much of the code.
Most developers now write and review code with AI assistants, so whether someone can produce or spot code in a test says less than it used to. What still separates people is whether they understand what they use: how it works, why they would choose it, what it costs, and when it is the wrong choice. Research on learning separates this conceptual knowledge from procedural know-how, and it is the part that carries over to new problems. Experts also frame problems by their underlying principles where novices go by surface features, which shows in how someone approaches an open problem.
- For each skill they claim, ask them to explain a mechanism or a decision in a situation built from their own claim: what happens when the cache goes cold, why that isolation level.
- Add one open problem that needs several of their skills, and listen for how they frame it, what they would find out first, the options they weigh, and how they would know it worked.
- Follow up on their own answer: why that over the obvious alternative, what breaks at ten times the load. Rehearsed or borrowed answers tend to break here.
- Score against written anchors, require a quote from the answer for every score, and reward a plain explanation of the right mechanism over correct buzzwords.
- Keep it short, and never use real backlog work: unpaid real work is unfair and puts good candidates off.
References that say something.
Ask the referee to rate specific claims ("led the payments migration"), say whether they saw it directly, and skip anything they did not observe. A free-form "would you hire them again?" invites politeness.
Reach them at a work email on the company's own domain, not a free mailbox, and discount references that two people trade with each other.
How Kif puts this together.
On Kif every skill is labelled with its strongest backing: self-reported, described with specifics, shown in their code, passed Kif's skill check, vouched by a colleague, code accepted by other projects, or confirmed by an employer. Stronger proof counts for more in matching. Kif's skill check is not a coding test: it asks candidates to explain the tools they list and approach a real problem, with a follow-up on each answer, and each skill passes or not on its own. Hiring teams can read the answers for passed skills, and after meeting a candidate they can confirm, in one tap per skill, how it held up.
Common questions
Are coding certificates worth anything when hiring developers?
As a signal of interest, a little. As proof of skill, very little: many can be passed by memorising questions, and certificates are easy to fake. Weigh them below a candidate's own code, a structured work sample, or a reference about specific work.
How can I tell if a GitHub profile is really theirs?
Ask them to put a one-time code in their GitHub bio, as Kif does, then check that commits are authored by that account and spread over time. Forks and single bulk uploads should not count.
Can candidates use ChatGPT to pass a take-home test?
Often, yes, if the test is generic or asks for code. Ask instead for explanations built from their own claims, follow up on their own answers under a time limit, note pasted text, and confirm in the interview.
As a developer, how do I prove my skills without certificates?
Keep real work public where you can, contribute fixes to projects you use, ask colleagues to vouch for specific work from their work email, and take short, structured checks. On Kif, each of these raises the level shown next to the skill.
Your next step
Make the role worth matching.
Describe the work, confirm the requirements, and review the fit.