A few years ago I helped a fintech scale-up grow their engineering department. They'd been searching for a senior backend engineer for four months. Five rounds of interviews per candidate. A take-home project. A "culture fit" panel. After all that, they made an offer to someone who quit within eight weeks.
When I asked what happened, the CTO shrugged. "He just wasn't a fit." I asked: fit for what? Silence. They'd spent months interviewing but never wrote down what they actually needed the person to do. The interviews tested whether candidates could whiteboard algorithms and discuss system design in the abstract. They never tested whether someone could solve the actual problem they were hiring for: untangling a mess of overcomplexity and technical debt.
The person who quit was technically brilliant. He could have solved the problem. But nobody told him that was the problem. He joined expecting greenfield architecture work. He got legacy system archaeology. Eight weeks of mutual frustration, and now they were back to square one with another four months of searching ahead.
Total cost: €30k in recruiter fees, two months of wasted salary, and eight months with a critical role unfilled while problems festered. A year of lost progress, for a role they still hadn't filled.
This is the most common failure mode I see. Companies have elaborate processes with no clarity underneath them. Or they skip process entirely and hire on gut feel. Both fail for the same reason: nobody defined what success looks like before they started looking.
Two failure modes
Bureaucratic theatre. Five interview rounds. Panel discussions. Competency matrices. Personality assessments. The process becomes so heavy that good candidates drop out, and the ones who survive are selected for patience, not ability. Meanwhile, the hiring manager still can't articulate what the role actually requires.
Cowboy chaos. The founder meets someone at a conference, has a good conversation, and makes an offer. No structured evaluation. No clear expectations. Three months later, there's a mismatch that everyone saw coming but nobody named.
Theatre feels rigorous but isn't. Chaos feels decisive but isn't. Both avoid the hard work of defining what you need.
The real cost of a mis-hire
A senior engineer mis-hire typically costs €150-200k. The direct costs are substantial: €20-30k in recruiter fees, two to three months of salary and employer costs (~€30k), onboarding time from other engineers, and possibly a second search. But the bigger number is opportunity cost: critical problems unsolved, team capacity absorbed, good candidates who took other offers while you were stuck. The total is defensible. Just don't mistake it for cash out the door.
Clarity before process
Before you write a job description, before you design an interview, before you talk to a single candidate, answer three questions:
Mission: Why does this role exist? What problem does it solve for the business?
Objectives: What measurable outcomes should this person deliver? In what timeframe?
Competencies: What skills, traits, and behaviours are required to achieve those objectives?
Everything downstream flows from these three. The job description translates them for candidates. The interview tests them. The trial period evaluates against them. Without them, each stage drifts into guesswork.
Here's a real example (details changed):
Senior Backend Engineer
Mission: Own the reliability and performance of our payment processing system. We're growing 40% year-over-year, and the current architecture won't scale. This role exists to ensure we don't become the bottleneck to our own growth.
Objectives (first 6 months):
- Reduce payment processing latency p95 from 800ms to under 200ms
- Increase system throughput from 500 to 2000 transactions per second
- Zero unplanned downtime during peak periods
Competencies:
- Deep experience with distributed systems under load
- Pragmatic problem-solving: finds the simplest solution that works, not the most elegant
- Owns outcomes, not just code: takes responsibility for production behaviour
- Communicates clearly with non-technical stakeholders
- Comfortable with ambiguity: can make progress without perfect requirements
Notice what's not here: years of experience, specific technologies, degree requirements. Those are proxies. Mission, Objectives, and Competencies focus on what actually matters: can this person solve the problem we have?
The job description becomes a translation. You're not listing requirements; you're describing a mission someone can opt into. Candidates who read it should either think "that's exactly what I want to do" or "that's not for me." Both outcomes are good.
If you're struggling to define these, I've helped scale-ups get this right in a single session. Sometimes an outside perspective cuts through months of internal confusion.
Character over credentials
We interviewed two backend engineers the same week. The first had ten years of experience, contributions to well-known open-source projects, and a CV that made you wonder why he was even applying. The second had four years, no name-brand employers, and a mass mediocre GitHub presence.
We hired the second one.
The first candidate was technically sharp. But when one of our engineers questioned his proposed approach, he got defensive. When the engineer pushed back with data, the candidate talked over him. At lunch he made a dismissive comment about the "junior people" asking basic questions. By the end of the day, three team members independently said the same thing: "I don't want to work with him."
The second candidate didn't have the pedigree. But when requirements were ambiguous, he asked clarifying questions instead of guessing. When challenged on his approach, he got curious rather than defensive. He treated the junior engineer at lunch like a colleague, not an obstacle.
Technical skills are easy to test and easy to acquire. A smart engineer can learn a new stack in weeks. What they can't learn is how to take feedback without defensiveness, how to treat people well under pressure, how to own outcomes instead of just tasks. Traditional interviews test whether someone can perform. They don't test whether someone can collaborate. You need a different kind of evaluation.
One day beats five rounds
Long interview processes don't just frustrate candidates. They cost you the best ones. By week three of your five-round gauntlet, your top candidate has accepted another offer. You're left choosing among whoever had the patience to wait.
If you know what you're assessing, you can design a short, high-signal process. One focused day gives you more signal than scattered interviews because you're watching someone work, not watching them perform.
Morning: real problem session (2-3 hours). Give the candidate an actual problem your team is facing. Not a toy problem. A real challenge with messy requirements. Pair them with engineers and watch how they think, ask questions, and handle ambiguity. For the payment system role, we gave candidates actual performance profiling data. The best candidate spent 20 minutes asking clarifying questions before touching the data. The weakest jumped straight to solutions.
Lunch: informal conversation with the team. You learn a lot when the formal structure drops.
Afternoon: scope discussion (1-2 hours). Present the Mission, Objectives, and Competencies. Ask what questions they have, what concerns, what they'd need to succeed. The best candidates push back and identify things you haven't considered.
Debrief: Everyone shares observations mapped to the Competencies. Not "I liked them" but "Did you see evidence of pragmatic problem-solving? Did they demonstrate ownership thinking?"
Senior candidates don't object to a focused day. They object to five scattered half-days over three weeks. And they can smell when a company doesn't know what it's looking for. A clear, intense evaluation signals you've done your homework.
The first 30 days
One new hire finished his onboarding exercise in three days and immediately spotted a race condition in our job queue that had been causing intermittent failures for months. He'd built the context to see it, and we'd built a culture where speaking up was safe. That's onboarding done right.
The exercise? Build a todo app using your actual stack, connected to your actual systems, deployed through your actual pipeline. I stole this idea from Stephan Schmidt.
The point isn't the app. Building something end-to-end forces them through every layer: dev environment, deployment, authentication, database, monitoring, code review, staging, production. By the end, they've touched everything. They have context. They've shipped something. And you've seen how they work.
Compare this to three weeks of orientation meetings where someone sits through presentations about company values and finally gets codebase access on day 15. Every week of delayed productivity is money burned and problems unsolved.
Trial period: evaluate with intention
Most companies treat trial periods as "let's see how it goes." Then everyone knows by week three it isn't working, but nobody says anything because they can't articulate why. Six months later, you part ways, having wasted their time and yours.
Design the first 90 days around the Objectives. If the objective is reducing payment latency, the trial work should involve payment latency. Don't assign unrelated projects because "they need to ramp up."
Every week, evaluate: Where are we against each Objective? What evidence of each Competency? What concerns? What support needed? Document it. "I'm concerned about ownership thinking because in incident X, they handed off instead of driving to resolution" is useful. "I just don't think it's working out" is not.
One of the best trial period exits I've seen happened in week three. The new hire was talented, technically capable. But in weekly check-ins, a pattern emerged: every Competency related to communication was weak. He built excellent solutions and couldn't explain them. Because we'd defined "communicates clearly with non-technical stakeholders" as a Competency, we could name the gap specifically. We had a direct conversation. We helped him find a role elsewhere where heads-down work was what they needed. He thanked us for the clarity. No hard feelings, no wasted months.
That conversation is only possible if you've done the work upfront.
Your job as CEO
You don't need to run interviews or design onboarding programmes. You need to ensure whoever does has answered three questions first: What's the mission? What are the objectives? What competencies matter?
If your VP Engineering or hiring manager can't answer these clearly, your process will drift into theatre or chaos regardless of how many interview rounds you add.
The questions to ask:
- Can you show me the Mission, Objectives, and Competencies for this role?
- How does each interview stage test those Competencies?
- What does the first 90 days look like, and how will we know if it's working?
If the answers are vague, that's where your hiring problem lives.
Clarity compounds
Defining Mission, Objectives, and Competencies takes an hour. That hour saves you months of interviews with misaligned candidates, weeks of onboarding without direction, and the slow agony of a mis-hire you saw coming but couldn't name.
The job description becomes obvious. The interview becomes focused. Onboarding has direction. The trial period has criteria. And when it's time to decide whether to confirm or part ways, you have language for the conversation.
Skip the clarity and you get theatre or chaos. Neither works. Both are expensive.
If your engineering hiring is stuck, if you're losing candidates to slow processes or making offers that don't stick, the problem probably isn't your process. It's what you haven't defined yet.
Let's talk. I've fixed broken hiring at scale-ups across Europe. Sometimes the fastest path forward is an outside perspective.