Friction Is Not Rigor: The Economics of Bad Senior Hiring

Over the course of my career, I have been through more than 350 interview processes as a candidate, and I have hired or participated in hiring more than 150 engineers and engineering leaders, including senior and top-level roles.

That does not make me infallible. It does make one pattern very hard to ignore.

A lot of companies are not running rigorous senior hiring loops. They are running expensive, noisy, badly bounded evaluation systems and mistaking the resulting friction for a high bar.

That distinction matters.

This is not an argument against evaluating candidates. Strong hiring should test judgment, technical depth, communication, trade-offs, and the ability to operate under real constraints. The problem is not technical evaluation itself.

To be clear, I am not arguing against synchronous technical evaluation either. A well-run whiteboard, collaborative coding, or system design interview can reveal reasoning, structure, trade-offs, and communication far better than an oversized take-home. The failure mode is not live evaluation itself. The failure mode is badly designed evaluation — punitive, theatrical, badly bounded, or disconnected from the actual signal the role requires.

The problem is that many companies replace quality assessment of thinking with a badly designed process: expensive for the candidate, weak at isolating the right signals, and strangely effective at creating the illusion of seriousness while reducing the effectiveness of hiring itself.

Or more simply: many companies confuse friction with rigor.

That is not a fairness problem first. It is a systems problem. It is a design problem. And, at senior and managerial levels especially, it is often a sign of weak organizational judgment.

The expensive illusion

Heavy unpaid take-homes are usually sold with familiar language. They are “practical.” They are “closer to real work.” They “reduce the pressure of live coding.” They “show ownership.”

In theory, all of that can be true.

In practice, a large share of take-homes are not work samples. They are candidate-funded mini-projects with vague boundaries, hidden expectations, uneven review quality, and unclear return on effort.

Interviewing.io surveyed almost 700 engineers about take-homes. The picture was not subtle: 85% had encountered them, candidates overwhelmingly said they should take no more than four hours, 58% thought candidates should be compensated, and only 4% had ever actually been paid. The same research highlights the real complaint behind most negative reactions: not difficulty, but value asymmetry. The candidate absorbs the time, uncertainty, and effort. The company mostly absorbs the artifact.

When a company asks a senior or managerial candidate to build something substantial, document it, maybe deploy it, and then defend it later, the company has not designed a “high-bar” process. It has simply moved a meaningful portion of the evaluation cost onto the candidate.

This is not rigorous hiring; this is badly designed evaluation economics. And once you see the process in economic terms, the next question becomes unavoidable: how much does the company ask the candidate to spend, and how much real signal does it actually get in return?

Candidate Cost / Signal Ratio

The simplest way I know to judge a hiring step is to ask two questions:

How much does it cost the candidate?

And how much clean signal does it produce for the employer?

I call that the Candidate Cost / Signal Ratio.

Candidate Cost includes the obvious things: hours spent writing code, reading requirements, debugging, and preparing for follow-up discussion. But at senior levels, the real bill is larger. It includes context switching from your current job, evenings and weekends, and the mental overhead that bleeds back into your actual work. It includes documentation overhead, deployment overhead, and in some cases the use of your own tools, infra, and personal accounts.

Employer Signal is a different question. Does this step actually predict performance in the role? Does it isolate judgment, or just polish? Can candidates be compared fairly? Is the output meaningfully about their thinking, or mostly about how much time they had and how much effort they were willing to sink into an unpaid process?

A strong hiring step keeps candidate cost bounded while producing high-quality signal.

A weak hiring step does the opposite.

Heavy unpaid take-homes for senior and managerial roles often have a terrible Candidate Cost / Signal Ratio.

That is why they feel wrong even when nobody is being overtly rude. The candidate is not reacting to “hard work.” The candidate is reacting to a badly priced exchange.

What companies think they measure — and what they often measure instead

Companies usually believe they are measuring ownership, practical engineering ability, initiative, execution, and real-world problem solving.

Sometimes they are.

But oversized take-homes often measure something else:

how much spare time the candidate has;
how willing they are to absorb unpaid ambiguity;
how much polish they can add under uncertainty;
how much operational burden they will silently accept;
how effectively they can use AI and tooling to package a strong-looking artifact.

That last point matters more every quarter.

Anthropic’s engineering team published a remarkably honest account of this problem in 2026. They had to redesign a performance engineering take-home because frontier models kept collapsing its value as a discriminator. In their own write-up, they describe how Claude Opus 4.5 could match roughly the best human two-hour performance on their original exercise, and how preserving signal now required a deliberately more unusual, constrained, less realistic task. Their summary is hard to miss: what used to be a work sample became less useful as a hiring filter because the model capability curve moved faster than the interview design.

The deeper implication is larger than one company or one exercise.

Once strong models can generate respectable first-pass code, architecture, tests, and documentation quickly, any asynchronous artifact becomes a noisier hiring signal by default. The floor rises. The visible variance compresses. Candidates with very different underlying judgment can now produce outputs that look surprisingly similar, especially when the task rewards completeness, formatting, and polish more than unusual thinking.

That does not mean every take-home is suddenly useless. It means employers need to stop treating polished artifacts as if they were clean evidence of independent engineering ability. If the signal still matters, it has to be recovered elsewhere: by bounding the exercise tightly, by discussing the work live, by probing trade-offs and decisions, or by moving more of the evaluation back into collaborative conversation.

AI did not just make take-homes easier. It exposed how much of their supposed rigor depended on assumptions that no longer hold. My point is not that AI created the weakness. It is that AI made an existing weakness impossible to ignore by making polish dramatically cheaper, faster, and more uniform.

This is the part many hiring loops are not ready to admit.

In the AI era, a large polished take-home is no longer a clean proxy for individual engineering judgment. It may still produce some signal. But it also produces far more noise than many employers seem willing to recognize.

And if your process got noisier while also becoming more expensive for the candidate, the answer is not to call it “rigorous” louder.

The strongest defense of take-homes is not foolish. A bounded work sample can be better than trivia, more realistic than abstract puzzles, and less performative than a bad live interview. The problem is not the existence of take-homes. The problem is what many companies quietly turn them into.

The problem is scope.

A one-hour or ninety-minute bounded exercise with explicit constraints, clear inputs and outputs, and no delivery theater is one thing. A pseudo-product with code, structure, polish, documentation, hosting, and debrief preparation is something else entirely.

Once the company crosses that line, the exercise stops being a focused work sample and becomes a badly bounded delivery simulation. The employer still gets to pretend it is “just one step.” The candidate knows better.

And even the more sympathetic industry data points in the same direction. Greenhouse’s 2023 Candidate Interview Experience Report found that 49% of candidates somewhat or strongly dislike take-home assignments. The same report found that 70% consider lack of communication the biggest red flag in hiring, and 57% cite a negative interview experience as a major warning sign. In other words: candidate burden does not happen in isolation. It compounds with every other sign that the process is poorly run.

A badly designed take-home does not just evaluate the candidate.

It evaluates the company.

Why this breaks hardest for senior and managerial hiring

This is where I think many teams are least calibrated.

At senior and managerial levels, the most important signals are rarely hidden inside an unpaid mini-project. The strongest signals tend to come from technical discussion, system design, architecture critique, trade-off reasoning, behavioral depth, product judgment, and the ability to communicate under ambiguity.

That is where leverage lives.

A senior engineer is not especially valuable because they can grind through a weekend task and wrap it in clean markdown. An engineering manager is not especially valuable because they can absorb free-form delivery work on demand. Those are not the scarce traits.

The scarce traits are judgment, prioritization, decision quality, organizational thinking, and communication. This is the core calibration mistake in managerial hiring.

An engineering manager is not valuable because they can still behave like a strong IC under interview pressure. They are valuable because they can decompose ambiguity, make priorities explicit, sequence work under constraints, recognize people risk early, handle disagreement without losing momentum, and connect technical decisions to delivery reality.

When a company gives a senior or managerial candidate an oversized unpaid assignment, it often thinks it is measuring ownership. Too often it is measuring willingness to tolerate a badly bounded system instead.

That is not the same thing. And it usually points to the same underlying problem: weak calibration about where senior and managerial signal actually comes from.

Those signals do not show up cleanly in a large asynchronous artifact. They show up when you put a candidate inside a concrete operating situation and listen carefully to how they think. Give them a roadmap that is slipping. A fragile legacy system that keeps blocking product delivery. A strong but disruptive senior engineer. A hiring trade-off under pressure. A team split between urgent commitments and long-term technical health. Then watch what happens. What information do they ask for? What do they optimize for? What do they challenge? What do they protect? How do they balance technical, organizational, and business consequences?

That is managerial signal. And it is far more predictive than whether someone can produce a polished coding artifact over a weekend.

Whiteboard and live coding are not the real enemy

That distinction matters for synchronous interviews too.

Live coding is not inherently bad. Badly designed live coding is bad.

When it becomes punitive, unnatural, interviewer-dominant, or performative, it turns into stress theater. And there is real evidence that interview conditions can distort performance. In a randomized controlled study with 48 computer science students, performance dropped by more than half simply from being watched by an interviewer, while stress and cognitive load were significantly higher in the traditional interview setup.

The lesson is not “never do live evaluation.” The lesson is “design it like an adult.”

If the point is to reveal how someone thinks, then create a setting where they can think with you, not perform for you.

Candidate experience is not cosmetic

Companies still talk about candidate experience as if it were mostly an employer-branding issue. It is not. It is a hiring-outcome issue. CareerPlug’s 2024 Candidate Experience Report found that 76% of candidates said a positive candidate experience influenced their decision to accept an offer, while 52% had declined an offer because of a poor one; 35% had also left a negative online review after a bad experience.

A bad process does not just frustrate candidates. It reduces acceptance probability, damages reputation, and quietly pushes stronger candidates toward companies with lower-friction, higher-signal loops. This is one of the reasons oversized take-homes are so self-defeating: the candidates most likely to walk away are often the ones with the strongest alternatives, the clearest sense of opportunity cost, and the least appetite for unpaid ambiguity. So the company tells itself a flattering story — “we are filtering for quality” — while actually selecting for a different mix: more free time, more tolerance for asymmetry, and more willingness to absorb candidate-side cost. That is not high-bar hiring. That is selection bias with better branding.

To be fair, this is rarely the fault of the individual interviewer alone. Most interviewers are trying to do the right thing inside a loop they did not design, with criteria they did not set and constraints they do not control. The failure is usually upstream: process ownership, calibration, and the inability to distinguish meaningful signal from expensive ritual.

What better hiring looks like in practice

A diagnosis is only useful if it changes the design. So here is what better hiring actually looks like in practice.

For junior and some mid-level roles, a short bounded exercise can be perfectly reasonable. A narrow debugging task, a data transformation problem, a focused implementation exercise with explicit inputs and outputs — all of that can work if the scope is real, the time expectation is honest, and the company is not quietly expecting unpaid overinvestment. The important part is not whether there is code. The important part is whether the task is small enough to preserve the signal and cheap enough to remain fair.

Senior and managerial hiring is different.

At that level, the strongest loop I have seen is deliberately simple.

First, a technical deep dive into a real system the candidate has actually owned. Not a polished success story. A real operating discussion: what problem it solved, what constraints mattered, what trade-offs were made, what went wrong, what they would redesign now, and what they learned too late.

Second, a collaborative system design session around a bounded scenario with explicit constraints: delivery pressure, reliability requirements, legacy realities, team size, product urgency, organizational limits. The point is not to see whether the candidate can produce a perfect diagram. The point is to see how they structure the problem, what they prioritize, what they challenge, what they make explicit, and how they reason with another human in the room.

Third, for managerial candidates, a scenario-based discussion that tests operating judgment rather than artifact production. A roadmap is slipping. A key engineer is underperforming. Product wants speed while platform health is already deteriorating. A team has commitments it cannot realistically meet. A critical incident hits a part of the system nobody truly owns. What do you do first? What do you clarify? What do you defer? What do you escalate? What trade-offs are you willing to make, and which ones are too expensive?

That loop usually produces better signal than an oversized take-home because it tests judgment in context, not unpaid execution in private.

The principle is simple: evaluate people in the shape of the role.

If the role depends on decomposition, prioritization, communication, architecture judgment, and organizational clarity, then the loop should surface those things directly. If the role depends on implementation fundamentals, test implementation fundamentals directly — but keep the exercise bounded. Do not wrap it in delivery theater. Do not require candidate-funded hosting. Do not confuse polish with predictive value. And do not turn a hiring step into a badly disguised transfer of operational cost.

Strong hiring is not the art of making candidates work harder for free.

It is the discipline of extracting the right signal, at the right cost, for the right role.

The real signal

The real signal in a hiring process is not just what it extracts from the candidate. It is also what it reveals about the company.

A badly bounded, high-friction, low-signal process says something. It says the company is comfortable externalizing cost. It says process ownership is weak. It says interviewer design may be compensating for a lack of clarity somewhere else. It says the organization may not be very good at distinguishing seriousness from inconvenience.

That is not rigor. That is organizational confusion with a professional tone of voice.

The strongest companies do not confuse friction with rigor. They know how to extract signal without outsourcing the bill.