The short answer

Take-home assignments remain a common format in technical hiring, though their use has shifted substantially as AI tool capability has expanded. Some employers still use take-homes for specific calibrated purposes; others have moved away from take-homes in favour of controlled-environment formats. For candidates preparing for take-home assignments, the contemporary challenge isn't just demonstrating technical capability - it's navigating the AI tool dynamics that have become central to how take-homes work.

The honest guidance: take-home assignment preparation requires understanding the specific employer's policy on AI tool use, calibrating your approach to demonstrate the capability the assignment is designed to measure, and producing work that reflects your actual engineering capability rather than capability that depends on AI assistance the employer didn't authorise. The complexity is real because employer policies vary substantially - some explicitly allow AI use, some explicitly prohibit it, some leave the policy ambiguous, and the calibration varies across these contexts.

This guide walks through how to approach take-home assignments in the current landscape, how to think about AI tool use given different employer contexts, and what preparation discipline produces strong outcomes. The perspective is from the assessment infrastructure side - Skolarli's work with hiring teams provides visibility into how employers are calibrating take-home assignments, and the patterns that distinguish strong candidate approaches from weaker ones are clearer than most candidates realise.

Why take-home assignments remain in use despite the AI era complications

Worth being honest about why take-home assignments continue to appear in technical hiring despite the AI tool dynamics that have made them complicated. Three reasons employers continue to use take-homes, each calibrating the format somewhat differently.

Realistic engineering work evaluation. Take-home assignments can evaluate dimensions that live coding can't - sustained engagement with a realistic problem, design decisions made over hours rather than minutes, code quality across a larger codebase, documentation discipline, testing approach. Employers using take-homes for these dimensions accept the AI tool dynamics because the alternatives don't surface the same evaluation signal.

Self-directed work pattern evaluation. Some take-homes evaluate how candidates approach self-directed engineering work - how they structure problems, what tradeoffs they prioritise when given autonomy, how they handle ambiguity without an interviewer present. These dimensions are difficult to evaluate through controlled-environment formats.

Pre-screening before deeper engagement. Some take-homes function as pre-screening - a relatively low-stakes assignment that reduces candidate funnel before the more expensive live interview stages. These take-homes are typically calibrated as lighter-weight evaluations where the integrity concerns are less acute because the stakes per candidate are lower.

The implication: take-home assignments you encounter will be calibrated for specific purposes. Understanding what the employer is trying to evaluate informs how to approach the assignment effectively.

Understanding the employer's AI tool policy

Before doing any work on a take-home assignment, understand the employer's explicit policy on AI tool use. This is the single most important preparation step.

Look for explicit policy in the assignment instructions. Many employers now state their AI tool policy explicitly in the take-home assignment materials. The policy might be:

  1. "AI assistance is permitted. We want to see how you work with available tools."
  2. "Do not use AI coding assistants for this assignment. We want to evaluate your independent capability."
  3. "You may use AI for research and learning but not for code generation."
  4. "Disclose any AI assistance you use in your submission."

Each of these policies produces different appropriate behaviour. Read the policy carefully and follow it as stated.

If the policy is ambiguous, ask for clarification. When the assignment doesn't explicitly state AI policy, ask the recruiter or hiring manager before starting. "I want to make sure I approach this appropriately - what's your policy on AI tool use during the assignment?" The clarification produces appropriate calibration and signals professional behaviour to the employer.

When clarification isn't possible, default to conservative approach. If you can't get explicit clarification and the policy is genuinely ambiguous, default to producing work that reflects your independent capability. This protects against the risk that AI use would violate unstated policy. You can note in your submission that you produced the work independently, which provides clarity for the employer.

Recognise that policy varies meaningfully across employers. Some employers have moved toward explicit AI permission because they want to evaluate AI-augmented engineering capability. Some maintain prohibition because they want to evaluate independent capability. Some are still developing their policy. The variation is real and reflects different evaluation philosophies; respecting the specific employer's policy is the appropriate professional behaviour regardless of which philosophy you personally prefer.

What to do when AI use is explicitly permitted

When employers explicitly permit AI tool use during take-home assignments, the assignment is typically calibrated to evaluate how you work with AI tools rather than your pure independent capability. Several disciplines produce strong outcomes in this context.

Focus on the engineering judgment, not just the code production. Strong AI-assisted engineering involves substantial human judgment - what to ask the AI to produce, how to evaluate what it produces, where to extend or modify AI-generated code, when to reject AI suggestions and write code yourself. Demonstrate this judgment in your work. Don't just submit AI-generated code; submit work that shows your engineering thinking in directing and evaluating the AI assistance.

Document your AI usage transparently. Many employers permitting AI use also expect transparency about how it was used. Document the approach - what you asked AI tools to help with, what you reviewed and modified, where you made independent decisions. The transparency demonstrates professional discipline and helps the employer evaluate your actual capability beneath the AI-assisted output.

Verify and understand AI-generated code. AI tools produce code that's often functional but sometimes wrong in subtle ways. Strong candidates verify AI-generated code through their own understanding, testing, and code review. Submitting AI-generated code you don't actually understand produces weaker outcomes because the verification dimension is what employers permitting AI use specifically want to evaluate.

Show your work on architectural decisions. AI tools handle code generation effectively but often produce architectural decisions that don't reflect deeper engineering judgment. Show your reasoning on architectural choices - what alternatives you considered, why you chose specific approaches, how the design fits the requirements. The architectural reasoning is where senior engineering capability gets demonstrated.

Treat the assignment as collaborative engineering work. When AI use is permitted, treat the assignment as you'd treat real engineering work that increasingly involves AI assistance. The capability being evaluated is your professional engineering practice in the contemporary tool landscape, not your ability to memorise specific implementation patterns.

What to do when AI use is explicitly prohibited

When employers explicitly prohibit AI tool use during take-home assignments, the assignment is calibrated to evaluate your independent capability. Several disciplines produce strong outcomes in this context.

Respect the policy fully, not just technically. Some candidates interpret AI prohibition narrowly - "they said no AI for code generation, so I can still use AI for documentation" or similar boundary-testing. The interpretation that produces professional respect is no AI assistance during the assignment, regardless of which specific component. If the employer explicitly permits some AI use (like research), they'll say so.

Use reference materials and documentation freely. AI prohibition doesn't usually extend to standard reference materials - documentation, books, Stack Overflow (with appropriate attribution), official technology references. Using these resources is standard professional practice that produces work reflective of actual engineering capability rather than memorisation.

Take the time the assignment allows. Take-home assignments are typically calibrated for substantial time investment - often 4-8 hours of focused work. Use the time. Candidates who try to compress the work into less time often produce weaker outputs than candidates who engage substantively with the problem over the intended duration.

Document your reasoning explicitly. When AI assistance isn't available, your reasoning becomes the dimension that distinguishes strong from weak submissions. Document your thinking in code comments, in README files, in submission notes. Show what you considered, why you chose specific approaches, what tradeoffs you accepted.

Test your work substantively. Take-home assignments typically benefit from substantive testing - not just verifying happy path but considering edge cases, failure modes, performance considerations. The testing discipline often distinguishes strong submissions from competent ones.

Submit work that reflects your actual capability. If you find yourself tempted to use AI assistance the employer prohibited, the right response is to submit weaker work that reflects your actual capability rather than stronger work obtained through prohibited assistance. Employers can typically distinguish between AI-generated and human-generated code through various signals, and the integrity violation produces worse outcomes than the weaker submission would.

What to do when policy is ambiguous or unclear

Some take-home assignments don't explicitly state AI policy. When this happens, you need to navigate the ambiguity professionally.

Ask for clarification first. As mentioned earlier, the first step is asking the recruiter or hiring manager for clarification. Most employers will provide explicit policy when asked; the ambiguity often reflects assignment materials that weren't updated rather than genuinely undefined policy.

Default to conservative interpretation when clarification isn't possible. When you can't get explicit clarification, default to producing independent work. The conservative approach protects against unstated policy violation and produces work that reflects your independent capability.

Document your approach in submission. When ambiguity persists, document your interpretation in the submission. "Without explicit AI policy in the assignment, I produced this work independently. If AI-assisted work was permitted, I'd be happy to discuss how I'd approach this with AI tools as part of the follow-up conversation." The documentation produces transparency and demonstrates professional judgment.

Recognise that ambiguity itself produces signal. Ambiguous AI policy is sometimes intentional - employers want to see whether candidates think about the ethics of AI use rather than just assuming permission or default to prohibition. Your handling of the ambiguity reveals professional judgment that the employer may specifically be evaluating.

General preparation discipline for take-home assignments

Beyond the AI tool policy navigation, several preparation disciplines produce strong outcomes regardless of the specific employer context.

Read the assignment requirements carefully and completely. Take-home assignments often have explicit requirements that candidates miss when they skim. Read the requirements multiple times. Identify what's required, what's optional, what's evaluated. The requirements understanding informs how to allocate effort across the assignment.

Clarify any ambiguities before starting substantial work. Beyond AI policy, other ambiguities in the assignment requirements deserve clarification - scope expectations, language or framework requirements, submission format, evaluation criteria. Asking clarifying questions before starting produces better calibrated work than guessing at intent.

Plan the work before starting implementation. Take-home assignments benefit from explicit planning - what's the architecture, what components do I need, what's the testing approach, how should the work be documented. The planning produces stronger implementation than diving directly into code.

Allocate time across the dimensions evaluated. Take-home assignments typically evaluate multiple dimensions - functionality, code quality, design decisions, documentation, testing. Allocate time across these dimensions rather than spending all available time on functionality at the expense of the others. Submissions that demonstrate balanced engineering practice often outperform submissions that excel only in functionality.

Build incrementally with frequent verification. Strong submissions are typically built incrementally - implement the core functionality first, verify it works, add additional features, verify each addition, refine for quality. Building everything at once and verifying at the end produces submissions with subtle bugs that incremental verification would catch.

Document your work substantively. README files, code comments, design documentation, decision rationale - these matter substantially in take-home evaluation. Strong documentation often distinguishes strong from competent submissions because it reveals engineering thinking beyond just the code itself.

Test substantively. Beyond happy path testing, consider edge cases, failure modes, performance considerations. Testing depth often correlates with engineering maturity in submissions.

Reflect honestly in any reflection sections. Many take-home assignments include reflection components - "what would you do differently with more time?", "what are the limitations of your approach?", "what additional considerations would matter for production?". Honest reflection produces stronger evaluation than performative reflection that doesn't engage substantively with the limitations.

What strong take-home submissions look like

Some specific patterns that distinguish strong submissions:

Working code that reflects the engineering you'd actually do. Strong submissions produce code that's clean, well-organised, properly structured - not code that's been rushed for a take-home but code that resembles what the candidate would write in actual professional work.

Substantive testing that goes beyond requirements. Test coverage that includes edge cases, error conditions, integration scenarios where relevant. The testing discipline often correlates with engineering maturity.

Documentation that supports the reviewer's evaluation. README files explaining how to run the code, design decision documentation, comments where they clarify non-obvious choices. The documentation makes the reviewer's work easier and reveals engineering thinking.

Honest acknowledgement of limitations. Strong submissions identify what the implementation doesn't handle well, what would need additional work for production readiness, what tradeoffs were accepted. The honesty signals engineering maturity better than overclaiming completeness.

Design decisions explained with reasoning. When the implementation involves significant design choices, the reasoning is explicit. Why this architecture, why this database choice, why this approach to a specific subproblem. The reasoning matters substantially.

Code that compiles and runs correctly. This sounds obvious but is frequently missing. Verify that fresh-checkout, fresh-installation runs of your code produce the expected behaviour. Submissions that don't run produce immediate negative signal regardless of code quality.

Time management that fits the assignment scope. Submissions that are appropriately sized for the assignment time - not so light they suggest you didn't engage substantively, not so heavy they suggest you spent dramatically more time than the assignment was calibrated for. Calibrated effort signals professional judgment.

Where Skolarli's infrastructure fits take-home assignment preparation

For candidates who want to verify their engineering capability before take-home assignments, Skolarli's verified candidate assessments provide controlled-environment evaluation that produces verified credentials supporting your candidacy. The verified credentials can complement take-home submissions by demonstrating your independent capability beyond what individual take-home assignments evaluate.

For deeper context on how hiring teams are calibrating take-home assignments in the AI era, the Engineering Hiring at Scale post on rethinking take-home assignments covers the evaluator-side perspective on the shift in take-home calibration and what employers are designing around. Understanding the employer-side context helps candidates anticipate what specific take-home assignments are designed to evaluate.

For practice with realistic engineering scenarios in controlled environments, kodr.run provides practice environments with native code execution that mirror professional engineering tool patterns. Practice in environments resembling actual engineering work produces preparation that transfers well to take-home assignments.

For broader preparation across the dimensions take-home assignments evaluate, the Candidate's Compass post on technical interview preparation in the AI era covers the structural shifts and durable foundations that inform preparation across multiple format types.

Frequently Asked Questions

How do I know if my work will be evaluated by humans or by automated systems?
Most take-home assignments involve substantial human evaluation, though automated systems may handle initial filtering on basic criteria (does the code compile, does it pass basic tests). The human evaluation is where most of the substantive evaluation happens. Optimise your work for substantive human review - clean code, clear documentation, demonstrated reasoning - rather than for automated checks.
How much time should I spend on a take-home assignment?
Generally aim for the time the assignment specifies, plus or minus 20%. Assignments specifying 4-6 hours typically expect work that reflects that effort. Spending dramatically more time may signal that you're overinvesting in any specific evaluation step; spending dramatically less may signal that you didn't engage substantively. Some candidates ask whether time tracking matters - typically employers care about quality of submission more than precise time tracking, but consistent dramatic over-investment is sometimes noticed.
What if the assignment is much harder than the suggested time?
Some assignments are deliberately over-scoped to see what candidates prioritise when they can't complete everything. The discipline: identify what's most important to demonstrate, do that well, and document what you didn't get to and why. Honest acknowledgement of what you'd prioritise produces stronger evaluation than rushed superficial coverage of everything.
Should I disclose AI use if I used it for parts where the policy was unclear?
Yes. Transparency about AI use produces better outcomes than hidden AI use that gets detected later. If you used AI for parts where policy was unclear, disclose specifically - "I used AI tools for X aspect of the work, treating the ambiguous policy as permitting limited AI assistance for that purpose. I produced the rest of the work independently." The transparency signals professional judgment.
What if my submission needs more time than I have?
Submit what you have with honest documentation of what's incomplete and what you'd do with more time. Reaching the submission deadline with substantive but incomplete work typically produces better outcomes than missing the deadline trying to complete everything.
How do I handle assignments that ask for AI use disclosure?
Disclose specifically and accurately. What you used AI tools for, how you used them, what you verified or modified. The specificity matters - vague disclosure ("I used AI for some assistance") produces less useful information for the employer than specific disclosure ("I used AI to generate the boilerplate for the database access layer, which I then reviewed and modified for the specific schema. The business logic and tests are independently written.").
Are take-home assignments going to disappear entirely?
Probably not, but they continue to evolve. Some employers have moved away from take-homes toward controlled-environment formats; others have adapted take-homes for the AI era through explicit policies and assignment calibration. The format remains common in technical hiring but with substantial variation in how it's used.
What if I suspect my submission was unfairly evaluated?
Engage professionally with any feedback you receive. If feedback identifies specific weaknesses, treat that as useful signal for future preparation. If you don't receive specific feedback and outcomes seem inconsistent with submission quality, sometimes the right response is asking for specific feedback rather than disputing the evaluation. Most employers value candidates who engage constructively with evaluation outcomes regardless of decision.

About this piece

This post is part of the Skolarli Candidate's Compass, an analytical series from Skolarli Akademy Research providing candidate-side preparation guidance written from the assessment platform perspective. The series complements the Buyer's Compass, Operator's Compass, and Engineering Hiring at Scale series.

Skolarli Akademy Research is the editorial arm of Skolarli Edulabs Pvt. Ltd., publishing analysis on learning, hiring, and assessment infrastructure for both practitioners and candidates. Findings are reviewed by Skolarli's founders and product leaders before publication.

Reviewed by Vinay Kannan, Co-founder & CEO, Skolarli.