CTO-Led Technical & Leadership Interviews
I've hired as a developer, team lead, EM, head of engineering, and CTO. Now I bring that experience directly to your team's most important hires.
Over +500 interviews as a developer, a team lead, an engineering manager, a head of engineering, and now as a CTO.
Each of those roles taught me something the last one didn't cover. Most interview processes are built by someone who's only sat in one of those seats.
I've spent 15+ years building and scaling engineering teams at startups and scale-ups, and led the technical side of four products that went on to generate over €25M in annual revenue. In that time I've made good hires and bad ones, and I know exactly where standard interview processes fall apart.
Built for the hires that are hardest to get wrong
This isn't a replacement for your whole hiring pipeline and it isn't built for volume. It's a final layer, reserved for the roles where a wrong call is expensive: senior engineers, engineering managers, and technical leadership hires. Especially at startups and scale-ups, where I've spent my whole career and where one bad senior hire can cost you a year.
If your pipeline is high-volume and early-stage, this probably isn't the right fit. If you're down to your final few candidates for a role that really matters, it is.
Why the process is breaking
I've watched three things happen across almost every company I've hired for in the last couple of years.
- Candidates are using AI to breeze through automated coding tests, so the tests stop measuring what they were built to measure.
- Rigid, academic screening filters out engineers who'd genuinely thrive on the job, because being good at LeetCode and being good at shipping software aren't the same skill.
- Companies keep ending up with "paper tigers", people who ace the theory but can't collaborate or ship real code once they're in the seat.
There's a second problem underneath all of this: AI-copilot reliance. Anyone can generate code now. What's harder to tell is whether a candidate actually understands what the AI gave them, whether they can debug it, question it, or scale it, or whether they're just another prompter copying and pasting in a loop. Most interview formats weren't built to catch that difference.
Your team ends up paying for it twice. Hours go into grading take-home assignments, and your strongest candidates drop out of the pipeline because they don't want to do them.
One session, built around how the job actually works
Your team doesn't have to download code, review pull requests, or run screenings. They talk to the people who've already cleared the highest bar you have.
I replace screening tests and take-home assignments with one live, three-hour session, tailored to the role.
| Focus | What I'm evaluating | |
|---|---|---|
| Hours 1-2 (Senior Engineers) | Real-world pair programming | AI is allowed. I'm not testing whether they can prompt, I'm testing whether they understand what comes back: can they debug it, is it scalable, is it performant. |
| Hours 1-2 (Engineering Managers) | Organizational and architectural scenarios | Team structure, scaling pain, conflict resolution, technical trade-offs. The situations a take-home never shows you. |
| Hour 3 (All candidates) | System design, leadership, alignment | Can they connect technical decisions to business outcomes? Do they actually fit how your team works? |
At the end you get one document: a CTO Evaluation Memo with a clear recommendation. Not a scorecard or a checklist. My judgment, in writing.