I built hunr because the first screen in engineering hiring rewards the wrong things. A resume filters on pedigree, keywords, and years of experience. None of those ship software. The strongest signal of whether someone can do the job is what they can build, reason about, and maintain, and almost no hiring process starts there.
This post is the story of why that bothered me enough to build a company around it.
What I kept hearing from both sides
Before writing any code, I spent a long time talking to coders and to hiring teams. The striking thing was that both sides described the same failure.
Developers were disappointed that deserving candidates never got shortlisted, because the first screen rewarded the wrong things. Someone who had spent three years shipping solid production systems at an unknown company would lose, on paper, to someone with the right university and the right keywords. Their work was better. Their profile was worse. The profile won.
Hiring teams told the mirror image of that story. I also sat through interviews myself, on the hiring side, where the resume promised far more than the candidate could actually ship in code. A confident document, a strong first call, and then a technical round where nothing held together.
So good people were being missed, and teams were still spending hours on candidates who did not fit the skills required. Both sides were paying for the same broken filter.
Why is a resume such a weak signal?
Because it is a proxy, and a badly correlated one. A resume tells you where someone has been and what they claim to have done. It tells you very little about whether they can take a real requirement, in a real codebase, and turn it into working software.
The question a hiring team actually needs answered is simple: can this developer actually build and structure working software? A resume cannot answer that. Neither, honestly, can most of the things we bolt on after the resume. Competitive-coding screens select for puzzle-solving under time pressure, which is its own skill and mostly not the job. Candidates who clear LeetCode-style rounds can often solve puzzles but cannot ship real, production code.
Meanwhile the unfairness compounds quietly. Filtering on proxies is not just inaccurate, it is systematically biased toward polish: polished universities, polished employer names, polished profiles. Great engineers should not disappear because their profile is less polished than their work. That sentence has been on our principles list since the first version of hunr, and it is still the one I care about most.
What does a fair first screen look like?
It looks like the work.
If the job is to ship features into a codebase, the screen should be shipping a feature into a codebase. Not a trivia quiz about the language, not a whiteboard puzzle, not a keyword match. Practical work, inspectable evidence, and a fairer reason to say yes.
That conviction became hunr. Today, hunr is the agent-allowed, understanding-verified technical hiring platform: candidates ship real code against role-specific challenges using any AI agent they like, and hunr then verifies they understood what they shipped. But it started from something much smaller and plainer: the belief that the strongest signal is what someone can build, reason about, and maintain.
Three things follow from taking that seriously.
The challenge has to reflect the role. A generic exercise produces a generic signal. If you are hiring a backend engineer for a payments product, the work sample should smell like payments: money handling, correctness under retries, the boring critical details. Role context is the input, not an afterthought.
The evaluation has to be trustworthy. If a hiring team is going to shortlist on the result, the result cannot be vibes. From the beginning we put deterministic checks first: clear pass/fail tests establish the baseline before any deeper review adds context. A report a team can inspect beats a score they have to take on faith.
The candidate has to get something out of it too. A fair screen is not just fair in aggregate; it feels fair to the person taking it. Candidates should be able to attempt real challenges without uploading their life story first, and they should see the evidence behind their own evaluation. If we ask someone for hours of real work, we owe them a real, inspectable result.
Who is this actually for?
hunr is built for the teams that feel this problem hardest: startups and small-to-mid-size engineering teams that need technical screening but do not have armies of interviewers. A 30-person company cannot spend two senior engineers' afternoons on every maybe. Their alternative today is the resume filter, which is exactly the thing that fails them.
For those teams, a work-sample screen is not a nice-to-have. It is the difference between hiring on evidence and hiring on hope. Teams should move faster because the signal is clearer, not because the evaluation is thinner.
And for candidates, it is a different kind of door. You do not need the right logo on your resume to take a challenge. You need to be able to do the work. That is the whole point.
Where it goes from here
We started building hunr from Bengaluru with a simple belief: engineering hiring should reward real ability. The product has evolved a lot since that first version, and it will keep evolving, because the industry underneath it is changing fast. AI has changed what engineers do all day, and it is changing what a meaningful hiring signal even is. I will write more about that separately, because it deserves its own post.
But the founding conviction has not moved. Deserving engineers were being filtered out before anyone saw their work, while some resumes said far more than the candidate could actually deliver. Hiring needed proof that someone can ship real code.
Resumes don't ship. People do. We built hunr so hiring could finally tell the difference.