Hiring full-stack engineers
who work with AI.

Reflect on who you need to hire.

Before writing the exercise, be honest about what you value in this role. Think about the work waiting for this person, how they will fit into the team and what you need them to take responsibility for.

Agree the level of the role before choosing the task. What relevant experience should this person already have? Which decisions should they handle independently, and where will the team guide them? Years of experience are useful context, but you still need to understand the work they have done and the language and framework knowledge they can apply.

Write down the changes you would notice. Perhaps customer integrations would stop depending on the founder, a recurring support problem would be fixed, or another engineer could hand over part of a product. Name the work and the outcome.

Include maintenance, customer questions and other less glamorous responsibilities. If these will occupy much of the week, candidates need to know that before joining. An idealised job description can leave you expecting one thing and the new hire expecting another.

Then choose the decisions your assessment should reveal. Will they need to challenge a vague request, extend an existing system safely, or decide what a small team can maintain? Write down your stack, team constraints and how you use AI, and build around those conditions.

For a small team, I’d look for evidence that someone can learn difficult things, own work from beginning to end and delegate without losing track of the result. That profile deserves a closer look than the names on their CV.

Give them a useful brief.

Provide a small working codebase and enough context to make sensible decisions. State where AI is allowed, which tools are available, what candidates should submit and what you want to learn.

Create several judgment points. Give them competing requests, a proposed design they can challenge and a user need that helps them choose. There should be enough work that completing everything within the limit is unrealistic, and you should tell them that upfront. A short assessment-planning exercise can help turn the role’s responsibilities into those choices.

Keep one assessment per role.

Use the same brief, starting codebase and assessment criteria for everyone applying for that role within a hiring round. This gives you a consistent basis for comparing candidates and saves you from building a custom assessment for each person.

If you make meaningful changes to the scope, difficulty or time limit, comparisons with earlier submissions become harder. Record what changed and which version each candidate completed, and take those differences into account when reviewing their work. Where possible, save substantial revisions for the next hiring round.

Compare access to tools and context across candidates. Offer a way to ask questions, and make reasonable adjustments to the format where needed.

Give them four to six hours.

For this kind of senior-role take-home, four to six hours is a starting point. Choose one fixed limit for the hiring round and make it clear before candidates begin. Let them decide how to use that time.

The unfinished work gives you something useful to discuss. Did they protect time for checking the core behaviour? Did they spot a low-value feature and defer it? When they learned more, did they reconsider their plan?

There’s nothing wrong with asking for a take-home when it helps both sides make an informed decision. A hire is a substantial commitment, and correcting a poor fit can cost months of salary and team time. Explain why you are asking for the work, stick to the limit and give it a thoughtful review.

Pilot the brief with someone who understands the role. Check that they can make useful progress and encounter meaningful choices within the time available. Reward a well-chosen, checked piece of work; don’t quietly reward people for spending the weekend completing the backlog.

Look for decisions.

Define the evidence you want before reviewing submissions. Record what happened, where it appears in the work and what remains uncertain.

Check a candidate’s explanation against a specific decision or change in their submission. A strong opinion is useful when they can connect it to the work and explain the trade-off. They don’t have to choose the exact solution you would have chosen.

Be clear about how your team checks AI-generated work. If you rely on automated guardrails and focused code review, give candidates those checks and explore where they still needed to use their judgment.

Explore the evidence together.

Use the submission to guide a conversation. Choose a few consequential decisions and understand the reasoning behind them. Keep the structure consistent while adapting the follow-up to each candidate’s work.

• Reconstruct a decision: explore the constraints they noticed, the options they considered and what made them choose.
• Revisit their priorities: ask what they left for later, when their plan changed and what they would prioritise differently if they started again.
• Change one assumption: introduce a realistic requirement and see how they adapt their approach.
• Inspect a claim: walk through the evidence for a behaviour they say works, including a failure case.

When someone says “we”, ask about their own contribution. Ask for a particular occasion when a general answer leaves too much open. Questions about a decision they reversed or an AI suggestion they rejected can help you follow the reasoning.

For deeper technical probes, draw on the assessment question library. Use a consistent interview structure, and leave time for their questions about your team. If you feel out of practice, rehearse the follow-ups with an AI candidate beforehand.

Keep the assessment useful.

Try the exercise with current AI tools before inviting candidates. Can a model produce a convincing submission from the brief alone? Which parts still reveal candidate decisions?

Record the assessment version, validation date and tool setup. Revisit it when models or your team’s work change materially, while preserving a comparable process within a hiring round.

Anthropic describes three iterations of its own performance-engineering take-home as newer models caught up with candidates. Maintaining a useful assessment is ongoing work. Read their account

Good candidates may be in several interview processes at once. An engaging exercise can help yours stand out: a problem they enjoy investigating, room to show their skills and something they learn along the way. Give them a taste of work they would want to do with your team.

Ask candidates what they found useful, frustrating or unclear. Their feedback can improve the next version just as much as running it through another model.