Technical cofounder hiring plan: what to ask first

Why stories about networks are not enough

A technical cofounder who says, "I know a lot of great engineers," may sound reassuring. It is still a weak answer. A few contacts can fill one seat, but they do not prove that this person can build a team.

Startups rarely stop at one hire. After the first engineer joins, you still need to define the next role, screen candidates, run interviews, make decisions fast, and bring people into the work without weeks of drift.

That is why recruiting skill shows up in planning, not in name-dropping. A strong founder can say who the company needs in the next 3, 6, or 12 months, what each person will own, and why that order makes sense.

The difference is easy to miss in conversation. One person tells stories about former coworkers at famous companies. Another person explains how they would hire a backend engineer now, a product-minded frontend engineer after launch, and a part-time DevOps hire only when traffic justifies it. The second answer is much more useful.

A real technical cofounder hiring plan also survives bad luck. If one candidate says no, the process should still work. If a hire leaves after six months, the founder should know how to reopen the role, what signals to look for, and how to keep standards consistent.

This matters even more in a small company, where every early hire changes the culture and the speed of delivery. Founders who rely too much on their network often hire people who feel familiar, not people who fit the actual stage of the business.

You do not need a perfect recruiter. You need someone who can repeat the work without guessing every time. If they can explain the roles they need, the interview steps they will run, and how a new engineer becomes productive in the first few weeks, you are hearing process. If all you hear are stories about who they know, keep asking questions.

Ask for a one-page hiring plan

A founder who can recruit should turn hiring into a simple plan on paper. If they need 20 minutes of storytelling about who they know, that is a weak sign. Early hiring needs clear choices, not vague confidence.

Ask them to name the next three roles they would hire for your company. The order matters. A strong answer sounds specific: "First, a product engineer. Second, a designer with strong frontend sense. Third, a part-time DevOps lead once traffic grows." A weak answer stays broad and jumps between roles without a reason.

A good one-page plan usually includes four things:

• which roles come first, and why
• when each hire should happen
• what budget and salary range fit each role
• who owns sourcing, interviews, and closing

The details tell you if this person can run a real startup hiring process. Ask where candidates will come from. Good answers mention a few channels and realistic goals, such as direct outreach, referrals, a niche job board, or past applicants. Then ask what response rate they expect. They do not need perfect numbers, but they should know whether a role needs 30 messages or 300.

Ownership matters just as much. Someone should say who writes the scorecard, who does the first screen, who runs the technical interview, and who sells the candidate at the end. If every step belongs to "the team," no one owns it.

Then test the plan with one change. Say the first hire takes six extra weeks. What shifts? A founder who can recruit will trade off scope, timing, and budget without panic. Maybe they delay the third role. Maybe they use a contractor for two months. Maybe they rewrite the job to widen the candidate pool.

That is what a useful technical cofounder hiring plan looks like. It is short, plain, and adaptable.

If you want a simple benchmark, look for the same kind of thinking strong operators use when they build lean teams: clear role order, honest budget limits, and fast adjustment when reality changes. Oleg Sotnikov often works this way in Fractional CTO roles, where hiring decisions need to match product goals and cash limits at the same time.

Look for proof from past hires

Anyone can say they know great engineers. A recruiter can say that too. What separates a technical cofounder is whether they can point to actual hires, explain the choices they made, and say what happened after those people joined.

Ask about the last two engineers they hired. Keep it concrete. What role did they need, why did they choose that person, and how did the hire work out after the first few months? If one of those hires failed, that is not a deal breaker. A clean, honest explanation often tells you more than a success story.

Numbers help because they strip away sales talk. You are not looking for a perfect dashboard, just a few basic facts they remember:

• how long the role stayed open
• how many candidates reached final interviews
• how many offers they made before one was accepted
• whether the person stayed past the first 6 to 12 months

A good answer sounds plain. "We hired a backend engineer in five weeks. We made two offers. The first person declined because the role was too broad. The second joined and stayed." That is much better than "I have a strong network and always find top people."

Listen closely when they describe a bad hire. Strong operators usually talk about their own process before they talk about the candidate. They might say they rushed the interview, ignored weak communication, or sold the role badly. Weak ones blame the candidate for everything and learn nothing.

You also want proof that they changed something after a miss. Maybe they added a paid trial, rewrote the scorecard, or involved another interviewer earlier. If the same mistake happened twice and the process never changed, that is a warning sign.

This is where a technical cofounder hiring plan becomes real. Past hires show whether they can recruit with judgment, not just confidence. If they can name the people, the numbers, and the lesson from a bad call, they probably know how to build a team.

Review the interview loop step by step

A founder who can hire engineers should describe the candidate path from first contact to offer in plain steps. If they jump straight to stories about their network, pause there. You need to hear who runs the first screen, what each round checks, and how they decide at the end.

Start with the first screen. Ask who owns it. Some teams use a recruiter for logistics, but a technical cofounder should still know what happens in that call. A clear answer sounds like this: "I run a 20-minute screen to check communication, past projects, and whether the role fits what they want." A weak answer sounds fuzzy and changes every time you ask.

Then walk through the full engineering interview loop one round at a time. Each round should have one job. If one interview tries to test coding, system design, culture fit, product sense, and leadership all at once, the process is sloppy.

What a solid loop sounds like

• A short first screen with a named owner and a clear pass or fail bar.
• A technical round that matches the real work.
• A practical exercise that takes under two hours, or a live task like debugging, code review, or improving a small feature.
• A final conversation for team fit, priorities, and role scope.
• Fast feedback after each step, usually within a day or two.

Pay close attention to the exercise they use. Short practical tasks are usually better than puzzle questions. If the company builds APIs, ask candidates to review an API design. If the team ships product fast, ask them to reason through a tradeoff. Whiteboard brainteasers often tell you more about test-taking than real work.

Ask how they compare notes. Good interviewers write feedback separately before they talk as a group. That lowers the chance that the loudest person controls the decision. Then ask who makes the final call. There should be one owner, not five people sharing a vague feeling.

If a technical cofounder has a real technical cofounder hiring plan, they can explain this without drama. The details do not need to be fancy. They just need to be clear, repeatable, and fair.

Check the onboarding approach

A founder who can hire well should also know how a new engineer starts work. If they can describe sourcing and interviews but go vague on the first month, expect a slow ramp-up and a frustrated new hire.

Ask them to walk through day 1, week 1, and the first 30 days. Good answers sound scheduled, not improvised. Day 1 should cover account access, repos, cloud permissions, chat, issue tracking, local setup, and a short product intro. Week 1 should include reading the right docs, meeting the people they will work with, and shipping one small task. By day 30, the new hire should own a clear area or handle a repeatable type of work without constant rescue.

You are listening for practical details:

• Who sets up accounts and permissions before the start date
• What docs the new hire reads first
• Which tools they install and who helps if setup breaks
• What starter task they get, and why it is small but real
• Who reviews early work and answers daily questions

That starter task matters more than many founders think. It should touch the real codebase, but stay low risk. A typo fix in docs is too small. Rebuilding the billing system is absurd. A better first task might be a small bug fix, one internal admin screen, or a test for an existing feature.

Also ask who owns the human side of onboarding. In a small startup, new engineers often get stuck because nobody knows who should answer questions. A strong technical cofounder names a person, not a vague group. They should also explain how code reviews work in the first few weeks, and how quickly they expect feedback.

Last, ask how they decide whether the new hire has settled in. Good signs are simple: they can run the app, make a small change, follow the release process, and ask useful questions without waiting half a day for help. If the answer is "we will know by feel," the startup hiring process probably depends too much on luck.

A simple startup example

A seed startup needs its first backend engineer in six weeks. The product works, a few users pay, and the founders need someone who can clean up APIs, fix reliability issues, and help ship faster. This is where a technical cofounder hiring plan should sound practical, not impressive.

The founder starts by writing the role before talking to candidates. They set the pay range, list the stack the engineer will touch, and define success in plain terms. In the first 90 days, this person should take ownership of one service, reduce avoidable bugs, and ship changes without constant hand-holding.

That prep changes the whole search. The founder can now reject vague applicants early because the target is clear. They also avoid a common mess: talking to ten people, then changing the job every week because nobody agreed on what they needed.

The interview loop stays short. First comes a 20-minute screen to check communication, past work, and interest in the role. Next comes one practical review, such as reading a small code sample, spotting a bug, or talking through how to improve a slow endpoint. Then the team has one conversation about how the engineer works with product, handles tradeoffs, and asks for help.

Notice what is missing. No six-round process. No puzzle session that has nothing to do with the job. No claim that "I know great people" will solve everything.

The onboarding plan is just as concrete. In week 1, the new hire fixes a small bug and ships it to production with support from the founder. That gives them a safe way to learn the codebase, deploy flow, and review style. By the end of month 1, they ship one simple feature on their own, with clear acceptance rules and a short post-release check.

If a technical cofounder can describe a hiring process like this, they probably know how to recruit. If they jump straight to network stories, big names, or gut feel, you still do not know whether they can hire someone who joins, ramps up, and delivers.

Common mistakes when you assess recruiting ability

A founder can sound convincing and still have no usable recruiting method. The usual failure is simple: they sell confidence, stories, and names, but they cannot explain how they would fill two open roles in the next 60 days.

One weak sign is obsession with personal networks. Someone says they know "great engineers" or "people from top companies," but dodges basic questions about role scope, sourcing, pay range, interview owners, and timing. Good recruiters talk about open roles and tradeoffs. They do not hide behind famous contacts.

Another mistake is assuming more interviews mean better hires. Long loops often push strong candidates away. If they want six or seven rounds for an early startup, expect delays and drop-off. Strong engineers usually have other options, and they notice when a team cannot decide.

The same problem shows up in debriefs. If they skip written scorecards, people argue from memory and gut feel. One interviewer remembers a good conversation. Another remembers one weak answer. Nobody can compare candidates fairly because nobody captured the evidence.

Onboarding claims also need pressure. Some founders promise that a new engineer will ship code in three days, then admit they have no setup guide, no access checklist, no starter issue, and no clear owner for the first week. That is hope, not process.

A real technical cofounder hiring plan is visible in plain documents. You should be able to ask for a few concrete items and get clear answers fast:

• the next role they would hire for and why
• the interview stages, with who runs each one
• the scorecard or rubric they use to judge answers
• the first-week onboarding checklist
• one safe starter task for a new hire

A small example makes this obvious. If a startup needs its first backend engineer, a strong technical cofounder can explain where they will look, how many interviews they need, what each interview tests, and what the new hire will do on day one. A weak one keeps talking about people they "could call someday."

That difference matters. Stories can sound impressive in a meeting. Process is what gets someone hired, productive, and still on the team six months later.

Quick checks before you say yes

Ask questions that force concrete answers. A strong founder or fractional CTO does not need a long speech to explain how hiring will work. They should give clear details in a few minutes.

A good technical cofounder hiring plan usually shows up in four places:

• They can name the next one or two hires and explain why each role matters now, not six months from now.
• They can describe the full interview loop in about a minute, including who runs each round and what a pass looks like.
• They own a short onboarding plan with dates, names, and first tasks.
• They can say what good work looks like after 30 days in plain language.

Listen for cause and effect. "We need a senior engineer" is weak. "We need a backend engineer first because customer setup breaks too often, and that person will own billing and deployment work in month one" is much better.

The interview loop should also sound simple. If they need ten minutes to explain it, they probably have not thought it through. A useful answer sounds more like this: intro call, practical technical round, team fit check, final founder review. Short, clear, easy to repeat.

Onboarding is where vague recruiters usually fall apart. Ask who prepares access, who picks the first ticket, who reviews code, and when the new hire should ship something small. If nobody owns those steps, the first month will drift.

The 30 day mark matters because it shows whether they know how to turn a new hire into useful output. Good answers mention real work, such as fixing a bug in production, shipping a small feature, or taking over one part of the stack with normal support.

You do not need a perfect spreadsheet. You need proof that they think in roles, process, and outcomes instead of stories about who they know.

What to do next

Before you talk about equity, ask for the hiring plan in writing. A verbal pitch is easy to polish. A written plan shows how the person thinks when they have to make choices, set tradeoffs, and commit to a process.

Then compare that plan with your startup as it is today, not the company you hope to have in a year. A team of two needs a different startup hiring process than a team of fifteen. Your budget matters. Your timeline matters. The kind of role you need next matters too.

A simple way to move from talk to proof is to run one mock hiring exercise for a real role you expect to fill soon.

• Ask them to write a short hiring brief for the role.
• Ask them to sketch the engineering interview loop, including who joins each step and what each step should test.
• Ask them to explain how they would sell the role to a good candidate without overselling it.
• Ask them to draft the first two weeks of the developer onboarding approach.

This exercise does not need to take long. Forty five minutes is often enough. You are not testing whether they know every answer on the spot. You are checking whether they can build a clear technical cofounder hiring plan that fits your stage, your budget, and your team.

Pay attention to what happens when you push back. If they can adjust the plan without getting vague, that is a good sign. If they fall back on stories about who they know, or promise they will "find great people somehow," take that seriously.

If you want a second opinion, an experienced Fractional CTO advisor like Oleg can review the plan, the interview loop, and the onboarding draft. That kind of review is useful when you are hiring early and one bad process can cost months.

You do not need a perfect plan. You need a realistic one that another person can read and use. If they will not put it on paper, stop there.