Key Takeaways
- Confirm AI permission separately for every round. Don’t infer permission from an employer’s products or engineering culture.
- In AI-allowed rounds, demonstrate control: clarify requirements, review generated changes, test behavior, and defend your decisions.
- Treat take-home assignments as a separate policy question. Ask about permitted tools, disclosure, and sharing assignment materials with external services.
- Prepare in both modes: unaided implementation and assisted development followed by rigorous code review.
AI has changed some coding interviews by making tool use part of the assessment, while other rounds still require unaided work. Prepare for both: solving problems without an assistant and demonstrating that you can understand, test, and improve assisted code. Published guidance from Canva and Anthropic illustrates this split—not a universal move toward open-tool interviews.
Treat the policy examples below as context, not permission for your interview. Before your interview, get confirmation for your exact role and round rather than relying on another candidate’s experience.
What Has Verifiably Changed in Coding Interviews?
AI-Allowed and AI-Prohibited Rounds Coexist
Canva’s June 11, 2025 announcement described an AI-assisted coding screen replacing its Computer Science Fundamentals screen for backend and frontend roles, with AI use expected. The company described assessing realistic product challenges rather than simply allowing an assistant on unchanged algorithm questions.
By contrast, Anthropic’s candidate guidance, last updated July 10, 2025, says live interviews and take-home assessments are without AI unless the company explicitly permits it.
The useful distinction is the assessment’s rules, not whether an employer is enthusiastic about AI. Use these preparation categories; they aren’t standardized company labels:
| Format | Tool Boundary to Confirm | What to Practice |
|---|---|---|
| Unaided coding | Whether documentation, search, or any editor assistance is permitted | Implementing, testing, and explaining a solution without generated suggestions |
| Documentation-only | Which references are allowed and whether generative search features are excluded | Finding a specific detail without outsourcing the solution |
| AI-assisted coding | Approved assistants, features, accounts, and disclosure requirements | Delegating bounded tasks, reviewing changes, and retaining technical control |
Proctoring Is Separate From AI Permission
For proctored assessments, CodeSignal documents camera, microphone, and screen sharing, government-issued photo identification, and recording reviewed by its verification team. Candidates must follow the rules displayed for their assessment. Those requirements describe CodeSignal’s proctored format, not every interview conducted on the platform.
Don’t treat monitoring as proof of what tools are permitted. Read the instructions and resolve ambiguity before starting. Ask your recruiter:
- Are AI chat, code generation, inline completion, and agent features allowed?
- Can I use documentation, web search, my own editor, or an existing project template?
- Must I use a supplied assistant or account?
- What needs to be visible, recorded, or submitted, including prompts?
- What should I do if the approved tool fails?
What Hasn’t Changed: Fundamentals and Explaining Your Reasoning
Don’t retire your fundamentals practice. Microsoft’s technical-interview guidance still covers problem solving, coding, testing, algorithms, data structures, and complexity analysis.
Canva’s October 20, 2025 interviewer guide identifies engineering problem-solving, technical depth and ownership, and AI collaboration as evaluation areas. My practical inference: explaining your decisions becomes more valuable when the final code doesn’t reveal which choices you made and which came from an assistant.
There’s also newer evidence from one employer: in an October 16, 2026 report analyzing its own hiring scorecards, Anthropic reported that comments on autonomy and judgment had the largest increases among technical-candidate interviews. That’s evidence about Anthropic, not proof of an industry-wide scoring standard.
Make your reasoning observable at decision points. You don’t need to narrate every keystroke. Explain:
- The contract: What inputs, outputs, and failure behavior are you implementing?
- The choice: Why this algorithm or data structure instead of an alternative?
- The invariant: What condition must remain true throughout the operation?
- The evidence: Which tests support correctness, and what remains unverified?
- The trade-off: What would you change for larger inputs or production use?
For a hypothetical scheduling task, explain whether adjacent bookings are allowed before choosing an overlap rule. If an assistant proposes a different interpretation, identify the mismatch rather than accepting a plausible implementation.
When you’re stuck, describe your hypothesis and the next experiment. Prefer “I’ll test the boundary case to distinguish these explanations” over either silence or a confident guess.
Take-Home Assignments: AI Permission Is Not Automatic
Even one employer can have exceptions to its general policy. Anthropic’s January 21, 2026 engineering article explicitly permits AI for the performance-engineering take-home it describes, despite the company’s general no-AI default for take-homes.
Before starting, confirm the time budget, permitted assistance, required disclosures, and follow-up format. If the instructions are silent, ask rather than interpreting silence as permission. Ask separately whether you may send the assignment, starter repository, or supplied data to an external AI service.
If AI is allowed, submit work you can defend—not the largest application you can generate. A useful README should cover:
- How to run the project and its tests.
- Your interpretation of ambiguous requirements.
- The main design decisions and rejected alternatives.
- Known limitations and unfinished work within the agreed time budget.
- AI assistance and validation, in the format the employer requests.
For disclosure, describe what the assistant contributed and what you independently checked. Don’t claim you wrote generated code manually. Keep prompts or transcripts only when required or useful and permitted; don’t assume every company wants an exhaustive log.
Use small, reviewable changes and inspect the final diff before submission. Apply the same discipline described in Git Workflow Best Practices: leave yourself a submission you can review and explain.
Rehearse a follow-up discussion even if one hasn’t been promised. Can you explain the implementation, remove an unnecessary abstraction, or accommodate a changed requirement without regenerating the project?
Reviewing and Debugging Code You Didn’t Write
Make unfamiliar-code review a first-class practice exercise. Use code from a mock interviewer, a starter repository, or an assistant, then work through it without immediately requesting a rewrite.
For a concrete exercise, define booking intervals as start-inclusive and end-exclusive, with adjacent bookings allowed. Under that contract, [10, 11) and [11, 12) must not conflict. Review an implementation that incorrectly treats their shared endpoint as an overlap.
- State the contract. Separate the intended behavior from the implementation’s current behavior.
- Run a baseline. Establish what passes and what fails before editing.
- Trace the smallest failing example. Follow the relevant comparisons and state changes.
- Write a discriminating test. Test touching intervals alongside a genuine overlap and a separated pair.
- Make the smallest justified correction. Avoid combining the fix with unrelated refactoring.
- Verify and explain. Show why the fix addresses the failure and what other cases need coverage.
For this exercise, also decide how to handle empty intervals and invalid start/end ordering. Don’t let the implementation silently decide requirements that the problem statement hasn’t settled.
Practice deriving expected results independently of the implementation. Tests that merely repeat the same mistaken assumption won’t challenge it. Our guide to the benefits of unit testing provides a useful foundation for building this habit.
When reviewing a larger task, prioritize correctness and failure behavior before naming and formatting. Check input validation, error handling, resource ownership, and unnecessary dependencies where they’re relevant. Explain which risks you actually tested rather than declaring the code “production-ready.”
How to Prepare for Either Format
Practice With Assistance Disabled
Use the language you intend to interview in. Disable generated completions and other AI features, then solve a bounded problem using only resources allowed by the practice format.
Work through clarification, a straightforward solution, implementation, tests, and complexity analysis. Review the relevant data structures and algorithms rather than memorizing finished answers; the guide to algorithm fundamentals is a starting point if you need a refresher.
Afterward, inspect where you needed help. Was the gap syntax, problem decomposition, a data-structure choice, or debugging? Target the gap in your next session instead of immediately doing another unrelated problem.
Practice an AI-Assisted Workflow
Choose a small feature with clear acceptance criteria. Write your plan before asking an assistant to implement anything, then delegate one bounded subtask.
- Inspect every proposed change before accepting it.
- Check unfamiliar behavior against authoritative documentation when permitted.
- Run tests and add a case the assistant didn’t propose.
- Reject unnecessary complexity and explain why.
- Make a follow-up change yourself to check your understanding.
If the generated change exceeds what you can review, reduce its scope. Practice recovering from a bad suggestion rather than endlessly refining prompts until something passes.
Finally, rehearse the actual environment: editor, terminal, test runner, screen sharing, and approved assistant. Use a clean workspace without secrets or unrelated employer material. Agree on a fallback for tool outages rather than assuming you can switch services.
Common Mistakes
- Confusing preparation with participation: Don’t carry an AI mock-interview workflow into a prohibited live round.
- Assuming autocomplete is exempt: Ask about generated suggestions explicitly.
- Optimizing for code volume: Prefer a smaller solution you understand over an expansive one you can’t defend.
- Delegating interviewer questions: Give your own assessment before consulting an allowed tool.
- Overstating validation: Distinguish passing tests from behavior you haven’t checked.
FAQ
Can I use AI in a coding interview?
Use AI only when the instructions for that round explicitly permit it. Ask which tools and features are allowed; don’t interpret permission to browse documentation as permission to use a coding assistant.
Can I use AI for a take-home coding assignment?
Get explicit permission before using it, even if the role involves AI-assisted development. If allowed, follow disclosure requirements and prepare to explain, test, and modify the submitted code.
Should I still practice data structures and algorithms?
Yes—practice the fundamentals required for your target role, including data-structure choices and time and space complexity. In assisted practice, justify those choices yourself rather than repeating the assistant’s explanation.
How do I practice an AI-assisted coding interview?
Use an assistant for a small implementation task, then review the changes and test edge cases yourself. Finish by explaining the design and making a change without asking the assistant for the answer.
Further Reading
- Canva’s AI-assisted interview announcement — the screening redesign and its scope.
- Canva’s interviewer guide — ownership, problem-solving, and assisted development.
- Anthropic’s candidate AI guidance — stage-specific permissions and restrictions.
- Anthropic’s technical-evaluation redesign — a documented take-home exception.
- Anthropic’s employment research — company-specific evidence about changing hiring priorities.
- CodeSignal’s proctoring documentation — recording, identification, and assessment rules.
- Microsoft’s technical-interview guidance — fundamentals, coding, and testing expectations.
