The Matching Problem

We launched Yara recently. It is the consumer surface of a collective hiring OS with one goal: to get billions of people hired. We captured ~40k users in 32 days, and we now process thousands and thousands of applications on a daily cadence.

When you sit in the middle of that flow, you stop seeing hiring as a marketing problem or a sourcing problem. You see it as a matching problem. Taking the talent on the platform and orchestrating it down to the companies that are actually a good fit.

The strange thing about the matching problem is that it changes shape with every company. The parameters that make a candidate obviously right for one team make them obviously wrong for the next. That is what makes it a real problem and not just a database query.

What the numbers show

Volume clarifies things. When you look at ten resumes, you form opinions. When you look at thousands a day, you start seeing patterns that hold.

The first pattern is that resumes are baseline. They are the floor, not the signal. A resume tells you where someone has been and almost nothing about what they can do next.

The second pattern is that the things that actually carry signal are the things almost nobody maintains. Writing. Blogs. Portfolio. The work itself. GitHub. More than 90% of candidates do not optimize any of these. They optimize the document that matters least and ignore the artifacts that would get them hired.

That gap is most of the difficulty people are feeling in this market. It is not that there is nothing to show. It is that nothing is being shown.

The candidate side

The candidate pipeline is not just a presentation problem, though presentation is a big piece of it. For senior and mid-to-senior roles in particular, applications tend to fall into a handful of recognizable buckets.

• Blatant lies. People write things that are obviously not true. Someone claims AWS, or that they could be at AWS, and then every technology in the body of the resume is Azure and adjacent tooling that has nothing to do with the company or stack they are claiming. It is not subtle. You catch it in thirty seconds.
• Great on paper, jargon in the bullets. The header is impressive. Then you read the bullet points and it is abstraction stacked on abstraction. You cannot tell what they built. When someone has actually built something, the writing gets specific fast: the outcome, what they delivered, how they delivered it. If I finish a resume and still cannot say what this person contributed, they land in this bucket.
• Job hopping. Six months here, a year there, already looking for the next thing. This one is common. From an employer's side, people who stay somewhere are demonstrating that they commit, and commitment travels. It suggests they will commit to the next thing too.
• Fake applicants. This is a real and growing category. Someone claims a location they are not in. Or the LinkedIn on the application belongs to an actual, real person, and the applicant is not that person. They are posing as them to get the interview. Then there is the lazier version: a nothing resume, a nothing LinkedIn, no verification anywhere. I now check that both sides are verified as a matter of course.
• Keyword stuffing. People overload the resume with every keyword they can fit, hoping something catches. It reads exactly like what it is.
• Mass-apply-tool applicants. A large number of people are firing applications through automation and putting whatever into the fields. It is not a good look, and at volume it is easy to see.

I do not list these to dunk on candidates. I list them because each one is a symptom of the same thing: people have been told the resume is the artifact, so they game the resume. The resume was never going to carry the weight.

The context problem

The matching problem is largely a context problem.

That is why static resumes and static applications do a disservice to everyone. A static document is a snapshot of claims. It cannot answer the question a hiring manager is actually asking, which is: can this person do the specific work in front of me, in the environment I have, at the speed I need.

Pedigree is a proxy

Because that question goes unanswered, people reach for a proxy. Usually pedigree. The logic goes, this person worked at X firm, X firm is versatile and hires well, therefore this person is capable. It is not stupid. It is cheap and it is directionally useful. But it is a shortcut, and shortcuts have a cost.

The cost is that a very large number of people are not just capable of doing the job, they are capable of doing the work in a way that would make hiring them a no-brainer, and they never get looked at. The hesitancy comes from the credibility not being there. When credibility is missing, something has to compensate. The work has to compensate. The work has to show.

Writing reveals thinking

For the hiring processes we've run, the thing that moved my decision was never the header. It was one of two things. Either their writing gave me a clear read on how they think, technically or about product or about design, or their actual work and contributions did.

Writing reveals thinking. That is the whole reason it matters. You cannot fake the shape of a thought for 800 words. You can fake a bullet point in eight.

The frustrating part is the sequencing. Today you have to go through interviews to get that context. The interview is where the context finally arrives, which means every unqualified conversation costs both parties an hour, and every qualified person who did not present well never gets to that hour in the first place.

A matching algorithm would work really, really well if it were built around gathering your work and your output potential. Not your history. Your work.

Proof of work

So the question becomes mechanical. How do you get context on someone's capability before you talk to them, by looking at the things they have actually contributed to.

For some categories this is close to solved. Research papers exist. Open source exists. With open source you can read the contributions, read how the person explains them, see how they argue in a pull request, see what they chose not to do. Product, design, and engineering all leave artifacts behind. There are things to reference.

For other categories it is genuinely hard. Marketing, growth, and anything where the output is voice. Leaning on someone's voice as evidence is difficult. The work is real but it is diffuse, it is often attributable to a team, and the numbers around it are easy to claim and hard to verify. I do not think this is unsolvable. I think it is the harder half of the problem and it deserves to be treated as its own design problem rather than shoved into the same template as a GitHub profile.

Three layers of context

Here is what I am actually after. Three layers of context, assembled before the interview phase.

One, context on the person's ability to do the work. Two, proof of work, the actual artifacts. Three, a read on their ability to perform in the specific environment the company has.

If you can get those three before anyone books a call, you save an enormous amount of time. That is obvious. The non-obvious part is how you take that and build it into something tangible, something a candidate maintains once and a company can trust on sight.

Presentation is the fixable part

There is another layer here that I keep coming back to. There is a large subset of candidates who are simply not sought after because of how their work is presented. Not because the work is weak. Because the presentation reads as low quality, and that feeling transfers to the work itself, fairly or not.

This is the most fixable problem in the entire stack. Presentation is fine-tunable. It responds to direct collaboration and optimization. You sit with someone, you look at what they actually did, you help them say it plainly, you help them put the artifacts where a hiring manager can find them. That is a solvable, mechanical thing, and it changes outcomes immediately. That is a large part of where Yara comes in, improving the resumes, the applications, the whole surface a candidate presents.

The missing standard

People have attacked this before and some of it worked.

The precedents

TripleByte built a pre-vetted marketplace of engineers. Plenty of recruitment shops pre-vet candidates by hand and sell that filtering as the product. Turing positioned itself as the vetting partner on the engineering side. These are real precedents and they proved the demand is there.

But not everyone wants to use a service. A service sits between the two parties and takes a cut of the trust. It works, and it does not generalize.

A standard, not a service

What generalizes is a standard. We already have standards for pieces of this. GitHub is the standard for showing your code. LinkedIn is the standard for professional history and who you are in a work context. Both are imperfect and both are universally understood, which is the point of a standard.

There is no standard for work presentation and proof of work. It is scattered. We tell people to build a portfolio, and then every portfolio is a different shape, hosted in a different place, with a different idea of what counts as evidence. A hiring manager has to reverse-engineer the format before they can even evaluate the content.

That is the gap. Encouraging portfolios is not enough. The thing itself needs to be standardized, so that showing your work is as legible and as expected as pushing a repo.

The scale problem

I keep zooming out to the size of this.

Supply and demand

We are trying to get billions of people hired, in one of the worst job markets in memory. At that scale, yes, it is a context problem, and that is a huge issue on its own. But it is also a supply and demand problem. The ratio of people getting employed to jobs sitting in the market does not feel proportional. The two sides are not finding each other even when both exist.

And here is the part that does not get said enough. The number of opportunities and jobs, in engineering and elsewhere, is drastically increasing. The demand is going up. What is not going up is the ability to prove capability. The way to prove it is not being shown properly.

Adapt drastically

There is also a subset of talent that is not improving their skills fast enough. That is uncomfortable to say and it is true. The tools changed. The expectations changed. The floor moved.

So I hold two beliefs at once. More opportunity is coming, and a lot of it. And capturing it requires candidates to adapt drastically and to keep improving against the new environment rather than the old one. Both of those things are going to be true at the same time, and the people who internalize both will do fine.

Building the talent infrastructure

Yara's job is to condense the interview process and to lean on actual work and capability rather than work history.

That means stripping out the artificial parameters. Where you worked, how long you were there, what the letterhead said. Those are weak signals that we have overweighted because they were the only things that fit on a page. Replace them with the strong ones: what you built, how you explain it, how you think on paper, what happens when you are put in an environment like the one hiring you.

What it means for each side

For candidates, the promise is simple. Get matched to roles that are actually worth your time, and get guidance on how to land them. Not mindless applying into a void, hundreds of submissions deep, learning nothing from any of them. Matched, and coached, with the presentation problem fixed rather than tolerated.

For employers, the promise is equally simple. You should not spend hours reviewing thousands of applications. You should see people who genuinely fit the specific role, with the context already assembled, before the first call.

I am figuring pieces of this out as we go, and I want to keep the human layer in it. Hiring is a judgment call made by a person about another person, and I do not think that changes. What changes is how much of the judgment is guesswork.

We are building the infrastructure to get billions of people hired. The matching problem is a context problem. Context can be gathered, structured, and standardized. That is engineering work, not magic. It is super early, but as Yara grows, it will naturally get closer to the billions of hires mark. The standard for proof of work does not exist yet. It is going to.