Can They Do the Job? Will They Want To?

Would someone who’d built their career on open source software be happy building closed source products? That was the question nagging at me as I interviewed a core Python developer. They had an impressive background, the kind of resume that makes you want to skip straight to the offer. They’d spent years contributing to open source software that millions of developers rely on.

I asked directly. The conversation made clear that what energized them was the community, the public impact, the collaborative development model. We were building proprietary software. The fit wasn’t there.

We passed on each other. They went on to a company where they could primarily work on OSS. No six months of mutual frustration. No wasted time. Just an honest conversation that got both sides to the right answer faster.

The hard part isn’t the conversation itself; it’s being willing to have it. Most hiring processes never do. Coding tests, system design interviews, and take-homes all answer the same question: Can this person do the job? A well-designed technical interview will filter out candidates who can’t write working code or reason about systems.

But there’s a question technical vetting can’t answer: Will this person want to do this job, on this team, with these tradeoffs? Technical skills get someone through the door, but alignment determines whether they stay and succeed.

When I say alignment, I don’t mean “culture fit” in the vague sense that phrase often gets used. That term has become suspect for good reason: too often it measures whether someone feels familiar, reinforcing sameness rather than predicting success. Alignment measures whether someone’s goals and your reality overlap. Culture fit is a feeling. Alignment is a question you can ask directly and get a real answer to: “We’re building proprietary software with no open source component. Is that something you’re excited about, or something you’d tolerate?”

The Question Coding Tests Don’t Ask

You can verify that someone knows Python, can design a distributed system, or can debug a tricky race condition. This is what most technical hiring optimizes for: confirming that credentials are real while revealing little about fit. What you can’t verify with a coding test: Do they want to work on internal tools or customer-facing products? Are they energized by greenfield projects or do they prefer optimizing existing systems? Will they stick around when the work gets unglamorous?

Consider someone I interviewed who had significant experience doing exactly what we needed: optimizing inference servers for LLMs. On paper, perfect. But as we talked, it became clear they weren’t interested in inference optimization itself. They’d done that work because it was necessary for what they actually cared about: building parsers. The inference work was a means to an end they found meaningful. We were hiring for the means, not the end. If we brought them on, they’d be doing the task without the context that made it satisfying. That’s someone who’s technically productive but quietly disengaged. The resume said yes. The conversation said no.

These examples point to the same gap: technical interviews are designed to identify people who can do the work, not people who want to do it. Closing that gap requires a different kind of conversation.

The Framework: Radical Transparency

After hundreds of interviews and building multiple teams from scratch, I’ve settled on one core principle: radical transparency about what you’re actually building and who succeeds on your team. Alignment doesn’t happen by accident. It requires honesty from both sides about what they actually want.

This works in two directions. First, you have to be honest with candidates about what you’re actually offering, constraints and all. Then you have to draw out what they actually want, not what they think they should want.

Be Specific About the Problem

Candidates can only self-select if they know what they’re selecting into. “We need a senior ML engineer” describes a role, not a problem. The more specific you get, the better candidates can self-select.

Every role has a defining constraint. Maybe it’s performance and cost: you need someone who can take your LLM prototype from demo to 1M requests/day while staying under $50K/month. Maybe it’s shipping speed: you need a team lead who can get a production feature out in 6 weeks, not 6 months, even if it means cutting scope. Or maybe the constraint is ambiguity itself: a small team where someone might own the ML pipeline this quarter and help with backend infrastructure the next.

Whatever the constraint, name it. The more specific you are, the better you can evaluate whether someone can solve it. And the more honest you are, the more likely candidates will self-select correctly.

Be Honest About the Opportunity

In 2019, I joined one of my consulting clients full time to launch their data science and ML engineering team. Ampersand is the largest cable television ad sales company in the world, but the team I was building was essentially a startup embedded in a 700-person organization. Here’s what I told candidates: we had autonomy to chart our own course, we were building ML systems from scratch, and we were going to run like a tech company within a company.

The tradeoffs were real. You could probably make more money at Meta or find faster advancement at an early-stage startup. We offered stability without bureaucracy. Not everyone wants what those alternatives offer.

Find Out What They Actually Want

You’ve told them what you’re offering. Now find out if they actually want it. Most interviewers dance around alignment because it feels too personal or too blunt, but vague questions get vague answers.

What work actually energizes them? The skill that gets them hired isn’t always the work that keeps them engaged. Someone can be good at something and hate doing it. I’ve interviewed engineers who were excellent at performance optimization but lit up when talking about developer tooling. Listen for energy, not just competence. Push past the first answer. If someone says they want to mentor, ask them to describe the last time they did it and what they liked about it.

Where are they heading? If they want to manage a team and there’s no path to management here, that’s a conversation to have now, not six months in when they’re frustrated and looking elsewhere. The goal isn’t to find someone with no ambition. It’s to find someone whose trajectory runs through what you’re offering, not around it.

But even direct questions have limits. You’re relying on candidates to know themselves well enough to answer honestly. Sometimes they don’t. Not because they’re lying, but because self-knowledge is harder than it sounds, and what someone wants in the abstract doesn’t always survive contact with the reality of a job.

When the Right Questions Get the Wrong Answers

The theory behind radical transparency is that honesty begets honesty. If you’re upfront about your constraints, candidates will be upfront about theirs. But interviews are still interviews. People want the job. Sometimes they convince themselves they want something they don’t. This happened on the same Ampersand team, despite following this process.

I hired someone I’d known for a while. I asked the hard questions. They gave thoughtful answers that seemed aligned. They were genuinely excited, and I think that excitement was real in the moment. But excitement about working together isn’t the same as wanting to do the actual work. Four months in, it became clear that ad tech wasn’t going to satisfy someone who cared deeply about environmental impact, no matter how good the team or the learning opportunity.

That’s four months none of us will get back.

Looking back, the information was there. I’d asked if they were sure they wanted to do this, given that their long-term interest was environmental work and we were building ad tech. They said yes, and I took that at face value. But certainty in an interview is cheap. What I should have weighted more heavily was the uncertainty itself. People often don’t know exactly what they want, so you’re always working with incomplete information. But when someone expresses doubt, or when their stated goals point in a different direction than what you’re offering, that’s real signal. When you’re working with limited information, any signal to the contrary deserves serious attention.

The Courage to Pass

Sometimes, despite your best efforts, you’ll get it wrong. But more often, the signal is there if you’re willing to act on it. Radical transparency means admitting when someone’s amazing but wrong for this team. It means having the courage to be honest about your constraints, your tradeoffs, and your reality.

This is hard. When you’re underwater and need to hire, every impressive resume feels like a lifeline. But a misaligned hire doesn’t solve your problem. It creates a new one.

The alternative is the standard playbook: pattern matching, credential checking, and “culture fit” interviews that select for people who look like you instead of people who want what you’re building. That’s how you end up with talented engineers who leave before they’ve shipped anything meaningful, or worse, stay and disengage.

I think about that Python developer sometimes. In a different process, we might have talked ourselves into it. Their resume was strong enough to justify almost any decision. We could have told ourselves that smart people figure it out, that passion for open source would translate to passion for our problems, that the technical skills would carry the day.

Six months later, we’d have had an unhappy engineer and a hole in the team. Instead, we had a 45-minute conversation that got us both to the right answer. They’re still doing open source work. We found someone who actually wanted what we were building.

That’s what radical transparency buys you. Not a perfect process, but an honest one. And honest processes fail faster and cheaper than dishonest ones.