Turing - Take-home Task Generator
Paste a job description and get a take-home task built from the real work of the role, with the brief for the candidate, the marking rubric, the AI rules, and the follow-up questions that show whether they understood what they handed in.
Named after Alan Turing, whose imitation game asks whether you can tell a person's work from a machine's. The follow-up interview asks the same.
A take-home assignment is a piece of real work a candidate does in their own time, usually two to four hours, and then talks you through. This generator builds one from your job description: a task drawn from the actual work of the role, the brief to send the candidate, the rules including how they may use AI, a marking rubric, and a follow-up interview with at least twelve questions that show whether they understood what they handed in. It works for engineers, engineering managers, CTOs and product managers.
When a free tool is not enough
A take-home only works if someone technical reads it properly.
The task is half of it. The other half is a person who can read the submission, ask the follow-up questions and hear the difference between understanding and recital. That is what our developers and CTOs do on every technical hire we run, from the first screen to the final interview.
How to use Turing, the Take-home Task Generator
Describe the role
Give the job title, the kind of role (engineer, engineering manager, CTO, product manager and more) and the seniority. That decides whether the task is code, a written plan or a strategy memo.
Paste the job description
The full advert or internal spec is best. A short summary works if you list the skills that matter underneath.
Add the real work
Optional, and worth it: one or two real problems the hire will face in their first months. It is what turns a textbook exercise into your kind of work.
Set the time and the AI rules
Pick one to four hours, and whether AI tools are allowed and disclosed, limited, or not allowed. Allowed and disclosed is the default we recommend.
Send it, mark it, then run the follow-up
Prepare the listed materials, send the candidate brief and the briefing, mark against the rubric, and run the follow-up interview with the question bank and the live change.
Why most take-home tests tell you nothing
Most take-home tests fail in one of three ways. They are generic, so a to-do app or an algorithm puzzle tells you whether someone has practised to-do apps. They are too long, so the candidates with other offers quietly drop out and you are left marking the ones who had a free weekend. Or they are marked on polish, which an AI tool now produces in minutes.
None of that is an argument against take-homes. A task built from the real job, sized honestly and followed by a proper conversation is still the best evidence you will get before someone starts. The conversation is the part most teams skip, and it is the part that matters most now.
What a good take-home assignment looks like
We have set and marked a lot of these, for engineers and for the people who lead them. The good ones share a shape, and Turing builds every task to it.
- Built from the job description: its domain, its stack, its first-months problems. Recognisably the work, not an exercise.
- Sized for the time you give, with an explicit out-of-scope list, so a strong candidate does not lose a weekend proving diligence.
- One requirement left open on purpose, marked "decide and document", because how someone handles ambiguity is most of the job.
- A short written decisions section: what they chose, what they traded off, what they would do next with more time.
- A rubric written before the first submission arrives, with weights, so two interviewers mark the same thing the same way.
- Materials you prepare in under an hour: a small starter repository, a dataset, a team snapshot, a design to review.
The technical interview after the take-home assignment
The follow-up is where you find out whether the candidate knew what they were doing. Ask them to walk you through it, then go underneath: why this data structure, what happens when the third-party API times out, what the query plan looks like at ten times the data, what they would change first. Then ask for one small change, live, in their own code.
Someone who wrote it, or directed an AI tool properly and checked its work, answers these easily and often enjoys them. Someone who pasted in a generated answer runs out of road by the third question. Turing writes the questions for the task it designed, with what a strong answer and a weak one sound like, so any interviewer on your team can run it.
AI in a take-home: allow it, then check the understanding
Banning AI tools does not work. You cannot enforce it, and the candidates who use them well every day are often the ones you want. So Turing allows AI by default, asks the candidate to keep a short AI log, and makes the follow-up interview the test of authorship.
Good AI use is a skill to assess in its own right. The questions to ask are about how they worked: what context and specification they gave the tool, how they verified what came back, where it was wrong and how they caught it, and what they kept away from it, such as secrets, personal data and security-sensitive code. "I used Claude" is only the first sentence of a good answer.
As for how to tell if code was written by AI: from the code alone, you mostly cannot, and detectors are not reliable enough to act on. What you can observe is the gap between the submission and the person. Every kit includes the concrete signs of a submission produced without understanding, and the questions that close the gap.
Take-home assignments for engineering managers, CTOs and product managers
Leadership roles need a different kind of task. For an engineering manager Turing writes a case study from a realistic team situation: a slipping roadmap, an incident, a struggling engineer, and a request for a plan. For a head of engineering or CTO it is a strategy memo, a build-versus-buy decision or an architecture review, with a budget attached. For a product manager it is a prioritised problem, a short spec and a success metric.
The follow-up works the same way. Ask them to defend the plan, cut it in half, and explain it to a sceptical founder. That is the job.
Keeping it fair to candidates
A take-home asks for a candidate's time before you have asked for anything else, so the brief says plainly how long to spend, what happens next and when they will hear back. Under the Equality Act 2010, recruitment is covered, so every briefing tells the candidate they can ask for reasonable adjustments, such as more time. At four hours, which is the ceiling here, we suggest paying for the time.
Frequently asked questions
A take-home assignment, also called a take-home test or tech test, is a task a candidate completes in their own time and then discusses with you. For an engineer it is usually working code with tests and a short write-up. For a manager or a CTO it is a written plan, a case study or a strategy memo. It is the closest thing to watching someone do the job before they start.
Two to three hours suits most roles, and four is the most we would ask for. Past that, candidates with other options drop out and you end up assessing free time rather than skill. Whatever the length, say it in the brief and design the task so a good candidate finishes comfortably inside it. At four hours, consider paying for the time.
In most cases yes, because they will use it on the job. Ask them to keep a short AI log of what they used it for and what they changed, and make the follow-up interview go deep enough that nobody can get through it without understanding their own submission. Turing supports three policies: allowed and disclosed, allowed for research and boilerplate only, and not allowed.
Not reliably from the code or the document alone, and detectors are not good enough to reject someone on. What works is the follow-up: ask them to explain a decision against an alternative, describe what happens underneath a library call, and make a small change live. Each kit also lists the concrete signs in that kind of submission that it was produced without understanding.
Start with a walkthrough in their own words, then ask about decisions, trade-offs, what happens under the hood, failure and scale, and how they tested it, and finish with a live change. Every kit includes at least twelve questions written for the task it designed, each with what a strong and a weak answer sound like, plus five to seven questions about how they used AI.
Yes. For an engineering manager it writes a case study from a realistic team situation with a small technical element. For a head of engineering or CTO it writes a strategy or architecture task with commercial constraints. For a product manager it writes a prioritisation and spec task. The rubric and the follow-up change to match.
Yes. You get three runs. Before the first result we ask for your name, work email and company, and that is the whole price. There is no paid tier.
What you put in on your first run travels with your details to our CRM, inbox and team chat, so a person can read it and reply. After that, input goes to the model. We keep each result, which can quote what you put in: it is emailed to you as a PDF and saved in our CRM. Leave out salaries, candidate names and anything confidential.
Related from Metamindz
- Technical recruitment by engineersOur developers and CTOs source, screen and interview candidates, with technical interviews included.
- Plato - Cofounder Job Description GeneratorFor a founding hire: the job description and the interview plan, before you need a take-home.
- Technical assessment in 2026: 7 myths that cost you good engineersWhat we test, what we stopped testing, and why.
- Can any platform actually stop AI interview cheating?Karat, HackerRank and CodeSignal compared on the question everyone is asking.
- All free tools
Also known as: Take-home Assignment Template, Take-home Tech Test, Coding Challenge Generator, Interview Case Study Template, Interview Rubric Template.
Published