How to Structure Technical Interviews When You Have No Technical Co-Founder

Non-technical founders can run rigorous engineering interviews by evaluating judgment, communication, and process while assigning code and architecture assessment to a qualified technical proxy. The three-round process gives the founder, the technical reviewer, and the team their own rounds to assess the candidate. The goal is not to make the founder a substitute engineer, but to give every consequential hiring decision an evaluator who can judge the evidence.

Why the standard technical interview fails when there is no one to grade the answers

The first three to five engineering hires are among a founder’s most consequential decisions, yet the interview formats borrowed from large technology companies assume a panel that can grade the answers. An algorithm puzzle, system-design whiteboard, or trivia round depends on someone distinguishing a sound answer from a plausible one. Without that evaluator, the exercise produces output but little usable evidence.

That mismatch becomes expensive because early hires establish more than the first working product. They shape the technical culture, set patterns for the architecture, and affect how the engineers who join afterward work. Their decisions compound. A bad first hire is therefore not a mistake that can necessarily be corrected at low cost, even when the founder recognizes the problem quickly.

AI-generated take-home submissions pose another problem for these borrowed formats. A polished file does not establish who produced it or whether the candidate understands its choices. Even technical reviewers need to probe the reasoning behind the submission. For a founder who cannot do that, reading more engineering books does not repair the process’s central flaw.

What non-technical founders can actually evaluate, and what they cannot

The founder’s evaluation domain includes leadership judgment, communication under pushback, business-goal orientation, and cultural alignment. These are substantive hiring criteria that require a separate technical assessment alongside them. The distinction is a division of labor. A founder can assess whether an engineer understands what the business needs to achieve while a technical reviewer establishes whether the proposed solution can withstand scrutiny.

A candidate who asks what a feature is for before discussing implementation demonstrates attention to the business goal. That signal becomes more useful when the founder challenges a proposed choice and observes the response. Calmly defending a sound decision differs from capitulating immediately or digging in out of ego. Neither submission nor stubbornness is good judgment. The founder can also assess whether the candidate explains tradeoffs through cost, speed, and risk rather than leaving a 30-minute conversation more confusing than it began.

The founder can also judge how well the candidate follows a process by asking how they check AI-generated code before shipping it. The founder can evaluate whether the candidate takes responsibility for verification, while a technical reviewer assesses whether those checks are sufficient. Accountability and technical adequacy are different judgments. Code quality, architecture soundness, stack fitness, current technical practice, and migration validation gates require someone qualified to examine the substance.

Steve Johnson is one option for founders seeking a hands-on fractional CTO to perform that technical assessment while they retain ownership of leadership and communication evaluation. The same division can work with a qualified advisor or senior engineer who has shipped production systems at scale. Credentials alone are insufficient, however. A résumé, fluent jargon, or polished take-home can help a weak candidate sound sure of themselves because the founder cannot judge the technical claims on their own.

What does a good three-round engineering hiring process look like for an early-stage startup

Three rounds are enough for most senior engineering roles at an early-stage startup. Each round needs someone in charge and a clear task of its own, rather than a new set of people having the same conversation. More interviews do not repair an unassigned evaluation task. The useful sequence is a founder-led business and judgment discussion, a proxy-led technical assessment, and a team and culture loop.

Round 1 belongs to the founder and establishes how the candidate approaches the company’s work. The discussion examines whether the candidate seeks the business goal, explains tradeoffs clearly, and responds constructively when challenged. For a first engineering hire, it also tests whether the candidate is ready to shape technical culture as well as build what they are assigned. The founder owns this judgment. Its output is evidence about how the candidate will work with the business.

Round 2 belongs to the technical proxy and examines code quality, architecture fitness, and the reasoning behind consequential choices. The reviewer needs to have worked on production migrations, handled incident response, and dealt with the limits on scaling at an early-stage company. An embedded fractional CTO, such as Steve Johnson, is one option for this role. A qualified advisor or technical co-founder can also perform it. The founder observes and learns without assuming responsibility for technical scoring. The reviewer’s conclusion should be expressed in business terms, with a hire or no-hire recommendation and the one or two concrete reasons behind it.

Round 3 is the team and culture loop, focused on how the candidate will communicate and work with the people already involved. It gives team alignment its own place without turning every participant into a technical examiner. This is not another technical round. By the end, the founder has evidence about business judgment and collaboration, while the proxy has supplied a defensible assessment of engineering capability.

How to probe for judgment on the decisions that are expensive to reverse

Cloud platform, database, and monolith versus microservices choices need a close look because later engineers have to work with them. The interview should examine how candidates reach these decisions. Knowledge alone does not establish sound judgment. Four probes can expose how a candidate handles constraints, transition points, operational risk, and AI-native product design.

The first probe asks candidates to defend a stack against concrete constraints, including speed to a working system, managed services over self-hosted infrastructure, narrow integration scope, and a measurable validation signal before further investment. They should explain how the choice fits the team and the hiring pool, grounding even currently exciting choices in that fit. Cost assumptions also need scrutiny. Choosing a service for its free tier without modeling costs at significantly higher scale exposes the free-start trap, while recommending distributed systems without the headcount to manage them exposes premature microservices.

The second probe examines when the initial architecture should change and what would trigger that conversation. A modular monolith is the starting recommendation, with decomposition justified when traffic or team size genuinely demands it. Immediately recommending microservices for a five-person startup is a red flag. A strong candidate describes a desirable target state and names a specific threshold and signal for change. The proxy judges the threshold’s technical credibility while the founder assesses whether the transition has a clear business rationale.

For data-adjacent or infrastructure-heavy roles, the third probe asks the candidate to walk through a migration from one system to another. Strong answers address dependency mapping, business-critical pipeline validation first, parallel operation during transition, consistency testing, and observability during cutover. The validation strategy is the decisive element. A candidate who moves directly to the target architecture without explaining side-by-side validation provides a destination description that still requires evidence that the migration can be trusted.

For AI-native product roles, the fourth probe asks how the candidate would design a tool schema for a specific domain action. This moves the discussion beyond whether an API looks elegant. Tool granularity affects latency and reliability. The technical proxy must assess the design, but the founder can still observe whether the candidate connects those choices to product behavior and explains the tradeoff clearly.

Why a non-technical founder cannot close the technical evaluation gap alone, and what to do about it

These probes do not become self-grading because the founder knows what to ask. A candidate can name validation, observability, or scale without proposing a sound approach to any of them. The reviewer must test the substance. That is why outside technical judgment is a structural requirement when no one inside the company can perform the assessment.

A fractional CTO can provide that judgment as part of an ongoing engagement. The hiring remit can include job descriptions, résumé screening, technical interviews, leveling, offer calibration, and hire or no-hire decisions. Continuity has a practical advantage. The reviewer can use what they know about the company’s strategy and architecture each time it hires, rather than treat each open role as a separate technical task. This differs from an interim CTO engagement intended to fill a leadership gap after a departure.

The broader fractional remit includes technical strategy and roadmap ownership, architecture and tech-debt review, vendor and tooling decisions, a security and compliance baseline, and technical due diligence support for fundraising. The remit requires explicit boundaries specifying whether it includes writing production features, running daily standups, or always-on call. The engagement provides technical leadership and judgment, with clear limits on which unfilled engineering duties it takes on.

Relevant production work helps distinguish useful pattern recognition from general advice. In Johnson’s work at The Letter Company, responsibility for a multi-tenant content platform includes a tool API reachable over MCP, REST, and an internal CLI, as well as row-level-security hardening and a migration-ordering CI gate. Those are concrete areas of responsibility a founder can discuss when assessing fit. For any fractional CTO, the question is whether current production experience translates into sound hiring judgment for the founder’s stage and domain.

A fractional engagement is not the only way to fill the gap. A trusted senior engineer can review Round 2 output and deliver a verdict, an advisor with relevant domain experience can join a technical interview, or a paid architecture audit can test a candidate’s proposed approach. The scope can be narrow. A bad engineering hire can consume many months of productivity, so the comparison is not simply the cost of outside review against conducting the interview alone.

How to interview the fractional CTO or technical advisor you are bringing in to run the process

The founder needs the same care when hiring the proxy. Technical fluency is still not independently verifiable, but judgment, communication, capacity, and process remain open to examination. The founder owns this evaluation. The strongest evidence connects a real decision to business context, cost, speed, risk, and team capability.

A useful opening question asks the candidate to describe a time they told a founder not to build something, including their reasoning and what happened. Agreement alone is not technical leadership. A second question asks for a specific technical decision that saved a company money, with the choice, alternative, and outcome made explicit. Vague claims about optimizing infrastructure do not supply that evidence.

The founder also needs to check how much time an ongoing advisor has, since they may work for several clients. The founder should ask how many clients the candidate has and what happens when two face a crisis in the same week. More than five concurrent clients is a red flag. Relevant stage experience is another filter, since decades of Fortune 500 work do not necessarily prepare someone for a pre-seed startup. Experience leading under similar constraints counts for more than time spent at an enterprise alone.

Other warning signs are a candidate who calls for a full codebase rewrite before learning how the business works, has never been a full-time CTO or senior engineering leader, asks for equity-only pricing, or refuses a paid trial before the founder commits to a retainer. These signals test the engagement as much as the person. A two-day architecture audit or a one-week sprint provides a paid trial in which communication and judgment can be assessed through real work. That is a stronger gate than relying on a polished sales conversation.

The founder should therefore choose a proxy who makes hard choices clear, works within the company’s constraints, and follows a process the founder can trust. The founder has already used those criteria to evaluate engineers while reserving technical scoring for someone qualified. Now the same criteria apply to the person who will run that assessment. The skill transfers without requiring the founder to become the code reviewer.