I hire a handful of engineers and researchers every year at Castle. That is not enough to make me a hiring expert, but it is enough to make me question the process every time we open a role.
Hiring is expensive, and the stakes are high. A bad decision can affect a team for years. At the same time, candidates invest time and energy in interviews, often while working full-time, with no guarantee of an offer. Companies have a responsibility to respect that time.
During interviews, I keep coming back to one question:
What is the next thing I need to learn about this candidate?
Early in the process, I am not trying to decide whether someone is a "good engineer." That question is too broad. I might want to understand their motivations, whether they would enjoy our work, how they communicate technical ideas, or whether we are simply looking for the same thing.
The answer should determine the next step.
This is why I tend to postpone take-home assignments. They can be useful, but they are expensive for candidates. If the main uncertainty is whether we are aligned on the role, a thirty-minute conversation is a much better use of everyone's time than a weekend assignment.
I see hiring as an information problem. Both sides have incomplete information, and each step should help reduce that uncertainty.
AI/LLMs is changing how we hire engineers, particularly how we evaluate candidates and interpret the work they produce. It made me question how much we can still learn from some of the signals we've traditionally relied on.
One disclaimer before going further: I am an engineer, and I tend to analyze things through technical models. Hiring is still about people, relationships, motivations, and judgment. This article is just one perspective that helped me think about part of the process.
Hiring is an information problem
Signaling theory starts with information asymmetry: one side knows something the other does not.
A candidate knows far more about their abilities, working style, and motivations than the company interviewing them. The company has to make a decision with incomplete information, so it looks for signals.
A signal becomes useful when it is difficult to fake.
That difficulty can come from knowledge, effort, reputation, or prior experience. The point is not that a signal must be expensive for the sake of being expensive. If there were a reliable way to evaluate a candidate in thirty minutes, that would be better for everyone.
But cheap claims usually carry little information.
Anyone can say they care about open source or understand distributed systems. Building and maintaining an open source project is harder to fake. So is publishing a thoughtful technical article or completing a technical exercise with clear reasoning.
None of these proves someone will be a great engineer, but they reveal more than a claim on a résumé.
This is where the comparison with proof of work became useful to me.
In Bitcoin, producing a valid block is intentionally expensive, while verifying it is relatively cheap. The cost does not make the block valuable by itself. It makes the proof harder to fabricate.
Some hiring signals have a similar structure.
A candidate may spend six hours on a take-home assignment that takes me thirty minutes to review. They may spend months building an open source project that I can review in a few hours (probably less with AI, ironically). The signal is useful not because of the effort itself, but because it reflects knowledge or experience that is difficult to imitate cheaply.
This model stayed in the back of my mind until I started receiving a new kind of candidate submission.
AI changed the cost of the signal
Over the past few months, several candidates have done something I had not seen before.
After an initial conversation, they sent me detailed analyses of a Castle component. That first call is usually simple: I learn about their experience and what they are looking for, explain the role, and see whether there may be a good fit.
The follow-up documents went much further. Some analyzed our JavaScript agent, SDKs, or other parts of the product. They included architectural observations, implementation ideas, and code suggestions. They were well structured, comprehensive, and often technically impressive.
A few years ago, I would have treated that kind of work as an extremely strong signal. Producing it would have required a significant investment of time and effort.
Today, I read it differently.
The issue is not that candidates use AI. I use AI every day, and I expect engineers to do the same. Some candidates may even build sophisticated workflows around these models, providing detailed context and encoding their own technical knowledge into the system. That is real work, and can itself demonstrate expertise.
But it changes what I can learn from the final artifact.
When I read a long AI-assisted report, I cannot easily tell which observations came from the candidate, which came from the model, and which were carefully validated afterward. Did they investigate each finding, reject weak suggestions, and refine the analysis? Or did the system produce a strong first draft from a well-designed prompt?
The document alone does not answer those questions.
Five years ago, writing fifty pages about an unfamiliar codebase would have required days of work. Today, generating fifty pages may be the cheapest part of the process.
The expensive part is evaluating them: separating useful observations from plausible ones, verifying technical claims, and deciding what the report actually tells me about the candidate.
The effort has not disappeared. It has shifted from the person producing the artifact to the person reviewing it.
Traditional proof of work makes production expensive and verification cheap. AI can reverse that asymmetry, making production cheap while verification remains expensive, sometimes even more so because of the volume of material.
I have started thinking about this as reverse proof of work.
What AI changed
Generating twenty observations about a codebase is now relatively cheap. Deciding which two are worth discussing is much harder.
Large language models are good at producing observations, suggestions, hypotheses, and possible improvements. But a long list of technically plausible findings doesn't necessarily tell me much about the candidate behind it.
What interests me more is how they evaluate and select those findings.
Which observations are correct? Which ones actually matter? Which ones deserve someone else's attention? Which ones reveal something important about the system?
A finding can be technically correct and still unimportant. An improvement can be sensible but irrelevant to the team's priorities. One carefully chosen observation, supported by a strong argument, may tell me more than a fifty-page report.
When I think about the candidates who left the strongest impression on me, I don't remember the longest reports or the largest number of findings.
I remember the person who pointed out something I had missed. The person who challenged one of my assumptions and explained why. The conversations where someone took a large amount of information and reduced it to the part that actually mattered.
Those moments were valuable because they compressed information instead of expanding it.
AI is making information production cheaper. Filtering, prioritizing, validating, and synthesizing it for a specific purpose remain expensive.
And that purpose matters in hiring. The goal is not to produce the most complete analysis of a company or codebase. It is to help both sides learn something relevant about whether they should work together.
Hiring processes should therefore spend less time rewarding volume and more time observing judgment.
Designing hiring processes
I am still not sure what the right hiring process looks like when every candidate has access to powerful AI tools.
But the basic principle should remain the same: every step should reduce a specific uncertainty.
If a conversation already shows that a candidate understands the role, communicates clearly, and has relevant experience, the next step should answer something new. It should not exist only because it is part of the standard process.
This makes generic take-home assignments harder to justify.
The question is not whether candidates will use AI. They will, and that is fine. The question is whether the exercise allows them to demonstrate judgment, prioritization, validation, technical depth, and the ability to explain trade-offs.
A shorter exercise followed by a discussion may reveal more than a long deliverable. So might asking a candidate to critique an AI-generated proposal, defend one recommendation, explain what they discarded, or walk through how they validated a claim.
These formats make the reasoning easier to observe, rather than rewarding the volume of material produced.
Of course, companies also need to consider the cost they impose on candidates. Every additional interview or assignment requires time, often from people who already have full-time jobs.
That does not mean take-home assignments are always wrong. It means their cost should be justified by the uncertainty they remove.
I don't know whether "reverse proof of work" will remain a useful model. It is simply a name I've given to a pattern I've observed during hiring.
But it has changed how I think about the signals we use to evaluate candidates. A polished technical artifact may still be valuable, but it no longer tells me as much about the person behind it as it once did.
As hiring managers, we need to adapt what we evaluate, how we evaluate it, and how much time we ask candidates to invest in the process.
The goal remains the same: reduce enough uncertainty for both sides to make a good decision. AI has just changed which signals help us get there.
