Technical cofounder interview questions from your backlog

Why interviews miss judgment

Most interviews measure what a candidate can explain after the fact, not how they make a hard call when the answer is messy. A resume tells you where someone worked and what shipped under their watch. It does not tell you what they would cut on a Friday night when the team is late, the budget is tight, and two problems matter at once.

That gap gets bigger when you are hiring a technical cofounder. Founders do not just write code or review architecture. They decide what the team should ignore, what can wait, and what is too risky to touch before launch.

Coding tests miss this for a simple reason: they reward output. A candidate gets points for finishing the task, using the right pattern, or writing clean code in a quiet setting. Startup work is rarely that tidy. Real work means half-clear requirements, old code nobody likes, and a backlog full of items that all sound urgent.

A real backlog puts pressure in the right place. It forces tradeoffs between speed, risk, and scope. When you ask someone to look at actual tickets and explain what they would delay, rewrite, or drop, you see their priorities clearly. You also see whether they protect the product, protect the team, or chase the most interesting technical problem.

What they choose not to do often tells you more than what they choose to do. Strong candidates can say, in plain language, "I would not build this now because support will pay for it later," or "I would leave this ugly code alone for two weeks because the customer problem is elsewhere." Weak candidates often try to solve everything. That sounds ambitious, but in a startup it usually means they do not feel cost, time, or risk.

That is why a backlog review often works better than standard technical cofounder interview questions. It shows judgment in motion. This is also the kind of tradeoff heavy thinking Oleg Sotnikov brings to Fractional CTO work: real technical leadership is not about perfect answers. It is about making sensible calls when every option has a cost.

Choose the right backlog slice

A good backlog exercise starts with real work. Do not invent a neat little case study with one obvious answer. Pull 8 to 15 items from your actual backlog so the candidate faces the same mess your team faces.

The best slice feels close enough to shipping that the choices matter. Use work from the next few weeks, not vague ideas for next quarter. When items are current, candidates show how they think about pressure, sequence, and risk instead of giving polished theory.

Mix the items on purpose. If every ticket is a product feature, you only learn how someone talks about roadmap work. A better set includes a few feature requests, one or two bugs, some tech debt, and at least one support issue that annoys users or the team every week.

That mix creates tension. A candidate may need to choose between fixing a flaky onboarding flow, shipping a sales promise, cleaning up a brittle deploy script, or stopping a support problem that costs the team an hour a day. That is where judgment shows up.

Clean the backlog before you share it. Remove customer names, contract details, revenue numbers, and anything else you would not want repeated outside the room. You do not need to strip out all context. You only need to make it safe.

For each item, add a short note on business impact. One sentence is enough:

• "Sales needs this for a live deal."
• "This bug hits about 12% of new users."
• "Support handles this manually every day."
• "This code breaks often and slows releases."

Those notes keep the conversation grounded. Without them, candidates fill gaps with guesses and sound smarter than they are.

A strong backlog exercise is messy, current, and concrete. If the slice feels a little uncomfortable to discuss, you probably picked the right one.

Set up the interview

A backlog exercise works best when the candidate starts with enough context to make decisions, but not a full data dump. Send a short product summary before the call: what the product does, who uses it, what stage the company is in, and one or two current problems. Keep it to a page or less. If you overload them with docs, you stop testing judgment and start testing patience.

Give the same packet to every serious candidate. That matters more than people think. When one person gets extra hints and another does not, your comparison gets muddy fast.

A simple prep packet is enough:

• 5 to 8 backlog items with one line each
• brief product context and the current goal
• hard limits such as budget, team size, or launch date
• a note that they can cut, delay, or rewrite any item
• a request to explain their thinking out loud during the call

That last point changes the interview. You are not grading whether they guess the same answer you would pick. You want to hear how they sort risk, user pain, tech debt, and speed. A strong candidate will explain why they would move a feature back, why they would rewrite a fragile area now instead of later, and what they need to know before committing.

Use a firm time box. Thirty to forty minutes is usually enough for a small slice of backlog. The clock forces tradeoffs. Without it, many candidates try to rescue every item and sound smarter than they would under real startup pressure.

Keep the format plain during the call. Show the backlog, restate the rules once, and let them work. If they go quiet, prompt them with "Talk me through your choice." Do not coach. Do not defend the backlog. If an item looks bad to them, that is useful signal.

Many cofounder interviews fall short because they stay abstract. A real backlog, a clear time box, and the same setup for every candidate give you something much harder to fake: judgment under constraints.

Run the backlog review step by step

Start with a short product brief. Give the candidate enough context to make tradeoffs, but not a full history lesson. They need to know who the users are, what the product does, where the team feels pain, and what can hurt revenue or trust if it breaks.

Then put a real backlog in front of them. Eight to twelve items is usually enough. Mix bugs, small product requests, tech debt, and one larger rewrite topic so the conversation feels like normal startup work, not a test designed for an interview.

Ask them to sort the work by urgency and impact. Some people will try to jump straight into architecture. Pull them back to priorities first. If they cannot decide what ships now, what waits, and what gets dropped, you are not learning much.

A simple flow works well:

• Ask which two items they would do first and why.
• Ask which items they would delay for a sprint or two.
• Ask which item they would cut unless new facts appear.
• Ask what extra detail they need before they commit.

When they cut or delay something, stop there. That moment usually tells you more than any polished answer. Good candidates talk about user pain, team capacity, risk, and timing. Weaker ones hide behind vague claims like "this feels more strategic" or "we should build for scale" without saying who needs it now.

If they say an item needs a rewrite, narrow the scope. Pick one rewrite decision and ask for the smallest first move they would take. A strong answer sounds like, "I would keep the current service running, isolate the failure point, and replace one path first," not "I would rebuild the whole thing in a better stack."

End with one final test: ask how they would explain the plan to the team on Monday morning. The best candidates can speak plainly. They can tell engineers what to build first, tell product what must wait, and explain the tradeoff without drama.

Startups do not need perfect plans. They need someone who can make a clear call and get other people behind it.

Questions that expose tradeoffs

Good answers show up when a candidate has to give something up. The best questions force a choice between growth, uptime, support load, and cleanup work.

Ask one question at a time. Then push for an order, not a long speech. If the candidate says "it depends," ask what it depends on and which signal would change the call.

"If sales slips next month, what do you cut first?" A strong candidate usually protects work tied to revenue, onboarding, and retention. They cut nice to have features, internal polish, or a rewrite that has no clear pain behind it.

"If uptime gets shaky or support tickets jump, what do you delay?" Good candidates move feature work down the list fast when reliability starts to hurt users. They know a week of outages can cost more than a month of slower shipping.

"What would you rewrite only after you see a clear failure pattern?" This question catches people who want to rewrite code just because they dislike it. Better answers mention repeated incidents, slow queries, bug clusters, painful deploys, or a hard limit in the current design.

"Which item needs a product decision, not an engineering fix?" Strong candidates often spot work that looks technical but is really about pricing, permissions, onboarding, or a confusing user flow. That tells you they can separate code problems from decision problems.

"What extra data would change your choice?" Listen for concrete data, not vague requests. Good candidates ask for churn by segment, support volume, error rate, usage frequency, or lost deals. They still make a call with the data they have, then say what would make them revisit it.

You do not want someone who acts certain with weak evidence, and you do not want someone who freezes until every dashboard is perfect.

What good judgment sounds like

A strong candidate rarely starts with code. They start with pressure. They ask who uses the feature, what brings revenue, what creates support tickets, what deadline is real, and what happens if the team waits two more weeks.

That matters because startups do not fail from a lack of ideas. They get stuck when someone treats every backlog item as equal. Good judgment starts with sorting work by user pain, business impact, and operational risk.

Listen for respect for boring work. Mature candidates do not dismiss test fixes, billing edge cases, cleanup tasks, or monitoring gaps as admin work. They know a small stability issue can waste hours every week and quietly hurt trust.

A simple answer often sounds better than an impressive one. If a candidate says, "I would keep the retry fix for failed payments ahead of the dashboard redesign because failed payments hit revenue and support right away," that is usually a stronger signal than a long speech about architecture.

Rewrites are another tell. Weak candidates jump to "we should rebuild this." Strong candidates slow down and break the problem apart. They say, "I would patch the worst part first, measure the failure rate, then replace one component if the pain stays high." That is how teams avoid spending two months on a rewrite that solves the wrong problem.

Honesty about missing context is a good sign too. The best people say, "I cannot rank this yet without usage data," or "I need to know how often support sees this issue." They do not guess just to sound confident.

Then watch what happens when you add one new fact. Maybe the "minor" bug causes a quarter of all support requests. Maybe a delayed feature unlocks a signed customer. Good candidates change their view fast, explain why, and move on. They do not cling to their first answer.

That is what you want from this interview: someone who protects stability, cuts work for a clear reason, and updates decisions when reality changes.

A simple startup example

Picture a small SaaS product with three problems at once. About 3% of invoice retries fail, search takes 8 seconds on larger accounts, and sales promised a new dashboard to a prospect who may sign this month.

Give that backlog slice to the candidate and ask them to think out loud. You want to hear how they sort cash, customer pain, and effort when all three pull in different directions.

A strong candidate often lands on something like this:

• Fix the invoice failures first because billing problems hurt revenue right away and create support work.
• Patch the worst search path next with a narrow fix, such as one missing index or a cache for common queries.
• Delay the dashboard until billing is stable, then decide if it still helps close the deal.
• Drop two extra requests from that same prospect if nobody else asked for them.

That answer is better than it first sounds. The candidate protects money first, reduces pain for many users, and avoids custom work that can trap a small team for weeks.

The search decision matters too. Good candidates do not jump straight to a rewrite because search is slow. They ask a few plain questions first. How many users hit the slow path? Is the slowdown recent? Can one small fix buy six months? That is the kind of judgment you want to hear.

Weak candidates often chase the dashboard because it feels urgent and visible. Others want to rebuild search from scratch before they know what is actually broken. Both choices can burn time while the real problem keeps hurting the business.

Score the reasoning, not whether they copy your own plan. One candidate may say, "I want one day to measure the billing failure before I touch anything." Another may ship a very small dashboard stub if the prospect is large and the invoice bug affects only a small group. Either answer can be good if the tradeoff is clear, the order makes sense, and the candidate knows what they would cut.

Mistakes that hide weak judgment

Weak judgment often looks fine in an interview because the setup is too clean. A smart candidate can talk well about a toy problem and still make bad calls when money, time, and customer pain are real.

The first mistake is using fake work. If you show a neat coding puzzle instead of a real backlog slice, you learn how someone performs in school mode. You do not learn what they protect, what they cut, or how they think when every choice has a cost.

Another common miss is rewarding confidence over evidence. Some candidates sound decisive, but they cannot attach numbers to anything. If they say, "rewrite this service" or "delay that feature," ask what they expect to gain. More signups? Fewer support tickets? Less cloud spend? If they cannot estimate the upside, they may just be performing certainty.

Too much material also hides weak judgment. When founders dump 30 tickets on one screen, the interview turns into a memory test. Good people start skimming. Weaker candidates hide in broad talk. Five to eight backlog items is usually enough to force tradeoffs without causing chaos.

Interviewers can make this worse by explaining too much context before the candidate thinks out loud, nodding hard when the answer matches a favorite view, chasing deep technical detail before the work is ranked, or treating jargon as proof of judgment.

That last mistake is common. A candidate might speak in detail about event buses, database indexes, or service boundaries and still miss the obvious call: fix onboarding first because 40% of users drop on day one. Sound prioritization beats fancy architecture talk almost every time in an early startup.

One simple example makes this easy to test. A founder shows six tickets, including a billing bug, a dashboard redesign, and a planned rewrite. A weak candidate jumps to the rewrite because it sounds ambitious. A stronger one asks how many customers hit the billing bug, how much support time it burns, and whether the redesign affects revenue. That is the exercise doing its job.

If you want to spot judgment in hiring, make the candidate choose under real constraints, then stay quiet long enough to hear how they think.

Quick checks before you decide

The last filter is simple: would you trust this person to make a hard call on a busy Tuesday when you are not in the room? Smart answers matter less than calm judgment. In a small company, one bad rewrite can burn a month of runway.

A few checks help:

• They explain tradeoffs in plain language that a founder or sales lead can follow.
• They protect cash, uptime, and promised dates before they protect neat code.
• They ask what a rewrite fixes, what it costs, and what breaks during the change.
• They cut scope without sounding sloppy or dismissive.
• They make you feel that they will decide, communicate, and move on.

Listen to how they talk, not just what they pick. A strong candidate says, "If we delay this report for one sprint, users will not notice, but if checkout fails for one hour, we lose money." That is the level of clarity you want. Weak candidates often hide behind jargon or drift into abstract debates about architecture.

A small example makes this easy to test. Say your backlog has three items: a payment bug, a dashboard redesign, and a plan to rewrite authentication. The better candidate usually fixes the payment bug first, pushes the redesign if it does not affect renewals, and challenges the rewrite unless the current auth flow has real security or support problems. They do not treat old code as a moral failure. They ask whether the rewrite solves the actual bottleneck.

That is why a backlog exercise works better than generic interview questions. You are not asking for theory. You are checking whether the person can protect the business while still improving the product.

One more signal matters. When they trim scope, do they preserve the user outcome? "Cut email templates from nine to three for launch" sounds careful. "Just ship less" sounds careless.

If their answers keep the company safe, keep the team shipping, and still leave room for cleanup later, you probably found someone you can trust with the next call.

What to do next

Right after each call, write down the candidate's three choices: what they would cut, delay, and rewrite. Do it while the details are fresh. If you wait until the end of the week, memory will smooth over the rough edges, and those rough edges often tell you the most.

Use the same scorecard for every person. Keep it simple: what they cut first and why, what they delayed and what risk they accepted, what they wanted to rewrite and whether it was worth the cost, what follow up questions they asked before answering, and whether their reasoning stayed clear when you pushed back.

Then compare candidates on the same backlog exercise, not on general impressions. One person may sound confident. Another may speak more slowly but make better calls. If they did not review the same backlog slice, the comparison gets fuzzy fast.

When two candidates look close, run one more round with a new backlog slice. Keep it short. You are not looking for a perfect answer. You want to see whether their judgment holds up in a different situation, especially when the tradeoffs change.

If your team does not have enough senior technical depth to judge the answers, get outside help before you decide. That is much cheaper than hiring the wrong technical cofounder or startup CTO. An experienced reviewer can spot when a candidate talks in abstractions, avoids cost, or reaches for rewrites too quickly.

If you need that outside view, Oleg Sotnikov at oleg.is can review your interview setup, test the backlog slice you plan to use, and assess each candidate's reasoning from a Fractional CTO perspective. That kind of second opinion helps when the team likes different candidates but cannot clearly explain who made the better decisions.

Pick the person whose tradeoffs you would trust on a tired Tuesday, with limited time and real customer pressure. That is the job.