Hiring your first startup team starts with defining the work each employee must own. Gather comparable evidence through questions about previous work, a small representative task and independent review. Apply the same criteria to referrals and unfamiliar candidates, and discuss working expectations before an offer.

A graphic summarizing Andrew Chen's advice prompted this article. His original essay, [Building the initial team for seed stage startups](https://andrewchen.com/building-the-initial-team-for-seed-stage-startups/), dates to [September 2009](https://andrewchen.com/2009/09/). It asks founders to look for useful breadth, personal execution and evidence from actual work. These are experienced judgments, not findings from a controlled hiring study.

The useful next step is to decide what would count as evidence for your role. “We need a doer” cannot settle a disagreement about a candidate. A description of what they owned, what they delivered and how they handled a setback gives you something to examine.

## Define the job before you define the ideal person

Describe what the next employee must accomplish and which decisions they will own. Do this before you start collecting impressive profiles.

Suppose customers keep abandoning an integration because setup is confusing. You could advertise for a senior engineer with startup experience. That description leaves your actual need largely unstated.

A more useful brief says: this person will investigate failed setups, identify a recurring problem, ship a repair and explain the change to customers. They need enough engineering depth to work safely in the codebase and enough communication skill to understand an unfamiliar customer's account. You will retain responsibility for pricing and commercial commitments.

Write down:

- **The outcome:** what should be different once the person has had a reasonable chance to learn and contribute?
- **The essential skill:** what must they already know on arrival?
- **The adjacent work:** who will they collaborate with, and what will that require?
- **The support:** what context, training and decisions will you provide?

This also exposes an impossible role. If the brief requires someone to rebuild the product, create a sales motion and manage support alone, split or narrow the work before interviewing.

Choosing the role is a separate decision. Our [first-five-hires guide](/blog/first-five-hires-seed-stage-sequencing) covers that sequencing question. Here, assume you have identified a real need and want to assess a person against it.

## What does T-shaped mean in this role?

Useful breadth means working across relevant boundaries while bringing depth in something the company needs. Define both parts instead of treating “generalist” as a complete requirement.

For the customer-facing engineer, depth might mean diagnosing a failure without exposing customer data. Breadth might mean turning that diagnosis into a clear explanation for support. You can ask for evidence of each without expecting the candidate to be an expert salesperson, designer and infrastructure engineer.

Ask them to describe a time they worked outside their main discipline. What did they learn themselves? Where did they ask for help? What did they hand back to the specialist? Someone who recognizes the limits of their knowledge may be a better collaborator than someone who claims to do everything.

You can also use the task brief to make the boundary concrete: “Explain what you would investigate yourself and when you would involve another person.” Look for a reasoned choice rather than maximum self-sufficiency.

Chen's warning about narrow specialization is a useful question about your operating conditions. It does not establish that specialists are poor early hires. If your central problem requires deep security, scientific or regulatory expertise, that depth may be essential from the start.

The question is whether you have enough important work for this person's strengths, and whether the surrounding team can cover the rest. Write the answer in the role brief so every candidate faces the same expectation.

## Ask doers to reconstruct a piece of work

Ask candidates to explain a particular piece of work from its starting condition to its outcome. Their title tells you where to begin asking questions; it does not tell you what they personally did.

Choose a project relevant to your need and follow the chain:

1. What was happening when you took responsibility?
2. What decisions and actions were yours?
3. Who else contributed, and what did they own?
4. What changed, and how did you know?
5. What failed or remained unfinished?

For the integration role, a candidate might describe reducing setup failures. Ask how they identified the problem, distinguished their contribution from a teammate's and checked whether the repair helped. Accept a careful account of incomplete measurement. Do not reward a neat number that the candidate cannot explain.

Use a common set of core questions. [US Office of Personnel Management guidance on structured interviews](https://www.opm.gov/policy-data-oversight/assessment-and-selection/other-assessment-methods/structured-interviews/) describes predetermined questions, shared rating standards and individual panel assessments before discussion. That gives you a useful design basis, although federal assessment guidance is not an experiment on seed-stage founders.

Follow-up questions can clarify different projects without changing the underlying requirement. Record the example and your reasoning: “Personally investigated support cases and shipped the fix” is inspectable. “Great energy” tells the next interviewer little.

Give candidates from consulting, banking, large companies or unfamiliar industries the same opportunity to demonstrate ownership. A background can suggest questions. It cannot answer them.

## Use candidate flow to test the brief

Broaden your search enough to discover whether your brief describes the person you actually need. Keep the assessment criteria stable while you do it.

Your immediate network gives you context about people you already trust. It can also encourage you to reshape the vacancy around whoever is available. Search beyond it: relevant professional communities, former collaborators and people whose public work addresses your problem can provide different routes to candidates.

More applicants do not automatically produce a better decision. If every conversation leaves you unsure, inspect the brief and questions before expanding the funnel again.

A useful revision names what you learned. Perhaps you assumed the integration role required outbound selling, but customer conversations show that onboarding is the immediate bottleneck. Change the role openly, explain the change to active candidates and revisit earlier assessments against the revised criteria. Do not quietly introduce a new bar halfway through the process.

Chen's candidate-count advice is a personal calibration heuristic, not a validated threshold you must reach. You do not owe yourself a particular number of interviews before making a well-supported offer. You do owe candidates a real vacancy and an honest process, rather than using their time for an undefined search for what you want.

## Observe a small piece of the actual job

Use a bounded task to observe a skill the employee needs on entry. Make its purpose, expected effort and evaluation criteria clear before asking someone to begin.

[OPM's guidance on work samples and simulations](https://www.opm.gov/policy-data-oversight/assessment-and-selection/other-assessment-methods/work-samples-and-simulations/) describes tasks resembling the job and cautions against testing competencies you intend to teach after hiring. A candidate's unfamiliarity with your internal tool should not become a failing grade when learning that tool is part of onboarding.

For the hypothetical customer-facing engineer, provide a small fictional integration failure with enough context to investigate. Ask for a diagnosis, a proposed repair and a short handoff. During the discussion, ask what further evidence would change their conclusion. You are observing technical reasoning and communication, not collecting a free fix for your backlog.

For a first commercial hire, use fictional customer notes and a short product description. Ask the candidate to choose the next step and draft the follow-up email. Then discuss a customer request the product cannot satisfy. Can they explain the limitation, ask a useful question and propose a next step without inventing a promise?

Prepare the same material and core follow-up for everyone. Decide in advance what competent performance looks like. An elegant email should not compensate for promising a feature the brief explicitly says does not exist.

Keep the exercise small enough to finish within the stated effort. Share which tools are allowed, what support is available and how to request an alternative arrangement. An exercise intended to test judgment should not accidentally test access to an uninterrupted weekend. No evidence here establishes an optimum task duration; choose the smallest task that reveals the required skill.

Be especially careful with multi-day trials. In [YC's interview with Ammon Bartram](https://www.ycombinator.com/blog/hiring-engineers-with-ammon-bartram), he raises the practical objection that employed candidates may be unable to leave their jobs for trial work. That is a reason to offer a bounded alternative, not a measured estimate of how many people you would exclude.

Pay and employment obligations also depend on the arrangement. For example, [UK minimum-wage guidance](https://www.gov.uk/guidance/calculating-the-minimum-wage/eligibility-for-the-minimum-wage) considers the trial's purpose, duration, observation and value to the business; work beyond one day is likely to attract entitlement except in unusual circumstances. That is a UK example, not a worldwide rule. Agree scope and pay for substantial trial work, check the applicable arrangements and remember that payment alone does not settle every obligation.

## Test mutual expectations instead of loyalty

Discuss the conditions under which you will work together. Enthusiasm is welcome, but it does not establish competence or agreement about the job.

Ask how the candidate handles unclear priorities, requests help and challenges a decision. Explain how often priorities currently change and who makes the final call. Share the actual expectations around hours, location, pay and customer contact. Give the candidate room to decide whether those conditions suit them.

Avoid treating immediate availability, unpaid effort or willingness to accept uncertainty as proof of commitment. Those answers can reflect someone's finances, caring responsibilities or current employment. Ask about the work directly instead of inferring motivation from sacrifice.

You should also resist turning quick thinking into a complete forecast of performance. A [2026 synthesis by Demeke and colleagues](https://link.springer.com/article/10.1007/s10869-026-10146-8) integrated **212 samples involving 109,396 people** and reported mean operational validity estimates of **.18–.22** for general mental ability and overall job performance. These are correlations, not success percentages. The evidence spans occupations, is not specific to seed startups and does not directly compare cognitive testing with the exercises proposed here.

That finding supports a limited conclusion: cognitive ability is related to performance, but it leaves substantial uncertainty about an individual hire. It does not establish that passion matters equally, that intelligence is irrelevant or that your preferred interview method is superior.

Combine the relevant evidence and keep its limits visible. A thoughtful candidate who asks hard questions about your company may be taking the decision seriously.

## Make the decision from a short evidence packet

Write the evidence down before discussing the candidate as a group. A short record helps you distinguish an observed strength from an impression or an unanswered question.

Use a table like this for the fictional commercial role:

| Requirement | Observation | Remaining uncertainty |
|---|---|---|
| Understand a customer problem | Identified a missing fact and asked a precise question | Has not worked with this buyer before |
| Communicate a useful next step | Wrote a clear message with a specific follow-up | Live negotiation not observed |
| Protect product commitments | Explained an unavailable feature without inventing a delivery date | Would need onboarding on commercial boundaries |
| Own the work | Reconstructed a previous project and separated personal actions from the team's | Reported outcome could not be independently checked |

Ask each interviewer to submit their observations and recommendation before reading colleagues' notes. Then discuss disagreements against the role requirements. If one interviewer sees a concern, identify the evidence behind it and whether another observation would resolve it.

Missing evidence should remain missing. Do not turn an unobserved skill into a low score, or let a numerical average hide an essential requirement that nobody assessed. If the brief changes, document why and reconsider the relevant candidates consistently.

This packet is a proposed operating method. It is not a validated selection instrument, and a tidy table does not make weak evidence strong. Name who owns the decision and record the reason for proceeding, declining or asking one focused follow-up.

## Keep the evidence together in Kit

Keep the role brief, submissions and reviewers' reasoning close enough that your team can inspect how the decision was made. A shared document can do this for a small process; connected hiring stages become useful when evidence is spread across people and steps.

In Kit, you can configure Work Sample, interview and team-review stages in one process. The [process configuration guide](/docs/process-template-configuration) explains task briefs and stage setup. Assign reviewers when you need a review gate: eligible submission stages without reviewers can complete when the candidate submits.

Reviews can include criterion scores, recommendations and written comments. Kit's [review workflow](/docs/reviews-and-feedback) supports recording your assessment before colleagues' reviews become visible. Configured voting rules can advance clear rounds, while some inconclusive rounds require a human decision.

The software organizes the record. Your team still defines a relevant task, supports candidates, handles payment arrangements and takes responsibility for the hiring decision. Start with one clear role and a few observations that matter. You can [adapt a process template](/templates) to hold that evidence as your team grows.