If you have been job hunting recently, you have probably noticed a shift. Fewer companies are asking for a PDF and more are asking for a link. "Send us something you built." "Walk us through your GitHub." "Record a short demo." That shift has a name: proof-of-work hiring. This post explains what it means, why it is spreading, and how to get on the right side of it.
What proof-of-work hiring means
Proof-of-work hiring is evaluating a candidate on evidence of things they have actually done, instead of on claims about what they can do. A resume says "proficient in React". Proof of work is a deployed React app, its commit history, and a candidate who can explain why the state lives where it lives.
The idea is not new — portfolios have existed forever in design and architecture. What is new is that in software, the evidence is now easy to produce, easy to share, and increasingly possible to verify.
Why the resume stopped working
The resume was designed for a world where applying was expensive: you typed it, printed it, posted it. Applying to twenty companies was a serious afternoon. Today one click sends the same PDF to four hundred openings, so companies receive volumes no human can read. Their fix was the ATS — software that filters resumes by keywords.
That created a game. Candidates learned to stuff keywords, buy certificates, and copy project descriptions from each other. The ATS cannot tell a project you built from a project you pasted. So companies ended up screening for the ability to write a resume, which is not the job. From the hiring side, the pile got bigger and the signal got worse. From your side, you got rejected by a regex.
Proof of work is the correction. It moves the decision from what you say to what can be checked.
What counts as proof
Not everything you can upload is evidence. In practice, four things carry weight:
- A deployed project. A live link that a stranger can open, use, and break. It proves the thing exists and that you finished it. Running-on-my-laptop does not count.
- Commit history. The record of how the project was built: small commits over weeks with messages that explain decisions. This is the part that is very hard to fake, and reviewers know it — one giant "final commit" reads very differently from two months of steady work. Our GitHub profile guide covers what reviewers actually look for.
- A demo video. Sixty seconds of you using the thing and naming the one hard part. It answers "what is this?" and "did you understand what you built?" in one artefact. Here is how to record one.
- A structured interview about the work. Someone — or something — asks you why you made the choices you made. Proof of work without a conversation is just a portfolio; the interview confirms the person behind it.
Notice what is not on the list: college name, CGPA, certificates, a "skills" section. None of those are evidence. They are claims.
How a fresher assembles proof in two weeks
This is the part people overestimate. You do not need a year. You need one honest project taken all the way to the finish line.
Days 1–3: pick something real and small
A problem you personally have, scoped so tightly that a working version fits in a week. A hostel mess-bill splitter. A tool that turns messy WhatsApp orders into a clean sheet. If you need ideas, these seven are built for exactly this.
Days 4–9: build it in the open
Commit every time something works. Write commit messages that say why, not what. You are not just building a project; you are building the record of building it.
Days 10–11: deploy and write the README
Free tiers on Vercel, Railway, or GitHub Pages are enough. The README should answer what it is, who it is for, what was hard, and how to run it — in that order.
Days 12–13: record the demo
Problem, one flow, one hard decision, link. Four or five takes. Put it at the top of the README.
Day 14: rehearse the conversation
Explain the project out loud, with a timer, using the problem-decision-trade-off-result script. If you built it, this is easy. That is the whole point of proof of work: it rewards the people who did the work.
How Iber applies this
Iber is a hiring platform built entirely on proof of work. Builders do not upload resumes. Instead, a profile is made of verified projects, 60-second demos, real GitHub history, and structured AI interviews that companies can compare across candidates.
The word verified matters. Anyone can paste a link, so every build on Iber is checked four ways: the commit history (was this built over time, by this person?), a live modification (can they change the running thing on request?), a deploy watermark (does the live app match the code?), and consistency (do the code, the demo, and the interview answers describe the same project?). A project that passes all four is evidence a company can act on without a phone screen.
For builders, it is free — always. For companies, the first hire is free. Wave 1 has limited spots and we pick from the applications, so if you have work to show, apply with your GitHub.
The short version
Resumes are claims. Proof of work is evidence. Companies are moving to evidence because claims stopped being reliable, and a fresher with one finished, deployed, explained project has more of it than most applicants with five years of keywords. Build the thing, ship it, show it, explain it. The pile of people who do all four is still very small.