Technical Interviews Start From Scratch. Real Jobs Don't
Technical interviews test you on a blank file. Your job hands you a codebase someone else wrote. Here is what Anthropic, Canva and the data say, and how to prepare for the real thing.
8 min read · Last updated: October 24, 2026
Technical interviews test whether you can write fresh code on a blank screen. The real job asks you to read code someone else wrote, change it without breaking it, and judge output you did not write, including AI output. Banning or allowing AI does not close that gap. Testing work on existing code does.
Came here from Instagram, LinkedIn, X or YouTube? Here is the full source list you came for. Everything below is built from these, nothing else.
The essay that started this
What companies actually say
- Anthropic, Guidance on candidates' AI usage, last updated July 10, 2025
- Canva Engineering, "Yes, you can use AI in our interviews. In fact, we insist", June 11, 2025
The receipts
Key takeaways
- In an interviewing.io experiment, candidates told to use ChatGPT passed 73% of verbatim LeetCode interviews. On custom questions, they passed 25%.
- In that experiment, no interviewer raised a concern about cheating.
- 81% of Big Tech interviewers surveyed by interviewing.io suspected AI cheating, and 31% had caught someone, per The Pragmatic Engineer (September 2025).
- Companies split down the middle: Anthropic says live interviews are "all you", while Canva now expects candidates to use Copilot, Cursor or Claude.
- According to Stack Overflow's 2025 survey, 66% of developers name "AI solutions that are almost right, but not quite" as their top frustration. Fixing almost-right code is the job.
- The skill that survives every policy: reading unfamiliar code, changing it safely, and explaining your decisions.
Why do technical interviews start from scratch?
Technical interviews start from scratch because a blank file is easy to standardise. Every candidate gets the same prompt, the same 45 minutes, and the same rubric. The cost is that a blank file tests a small slice of the job: writing new code alone, with no history, no teammates and no legacy decisions to respect.
That was the point David Rodenas made in his Medium essay on October 24, 2026. His title says it in eight words: technical interviews start from scratch, real jobs never do.
Think about your last real ticket. You did not open an empty editor. You opened a repo with years of commits, a test suite that half works, naming you would not have chosen, and a bug report written by someone in a hurry. Most of your time went into reading, not typing.
Now think about your last interview. Empty editor. Clean problem statement. Inputs and outputs defined. A timer.
Those are two different jobs. The interview is grading the one you rarely do.
Does banning AI in technical interviews fix anything?
No. Banning AI keeps the blank-file format and adds a policing problem. In interviewing.io's experiment, candidates secretly using ChatGPT passed 73% of verbatim LeetCode interviews, above the 53% control group, and not one interviewer raised a concern about cheating. A ban you cannot detect does not measure much.
Here is how that experiment worked. interviewing.io ran 37 mock interviews and kept 32 after removing five where candidates did not follow instructions. Every candidate was told to use ChatGPT. Interviewers were not told the study was about cheating.
| Question type | Interviews | Pass rate with ChatGPT |
|---|---|---|
| Control (normal mock interviews) | outside study | 53% |
| Verbatim LeetCode | 11 | 73% |
| Modified LeetCode | 9 | 67% |
| Custom questions | 12 | 25% |
Two details matter more than the headline. First, 81% of the candidates said they were not worried about getting caught. Second, rewording a LeetCode problem barely helped. The authors say a question only becomes custom when the inputs and outputs actually change.
The interviewer side looks just as shaky. According to The Pragmatic Engineer's September 18, 2025 issue, an interviewing.io survey of 63 interviewers found 81% of Big Tech and New Big Tech interviewers had suspected AI cheating, and 31% had caught a candidate definitely using it. Meta was the only Big Tech company the newsletter found making company-wide changes: interviewers now note suspected cheating in nearly all interview types, and most candidates must share their full screen with background blur turned off.
That is a lot of effort spent guarding a test that still measures the wrong thing.
Does allowing AI in technical interviews fix it?
Partly. Allowing AI makes the interview honest about how people work, but if the problem is still a blank file, you are now grading how well someone prompts a fresh solution. The real job adds what AI is worst at: existing context, unwritten constraints and output that is almost right.
Canva is the clearest example of the "allow it" camp. In a June 11, 2025 post, Simon Newton wrote that Canva now expects backend, machine learning and frontend candidates to use tools like Copilot, Cursor and Claude. The new round, called AI-Assisted Coding, replaces its Computer Science Fundamentals screen. Canva said almost half of its frontend and backend engineers are daily active users of an AI coding tool.
Canva also changed the problems, not just the rules. Its questions are ambiguous, cannot be solved with one prompt, and are judged on whether you can break down vague requirements and find and fix problems in AI-generated code. The example it gives is a control system for aircraft takeoffs and landings at a busy airport.
That is a big step. It is still greenfield. Nobody hands you a five-year-old codebase.
What do companies actually say about AI in interviews?
Companies disagree, sometimes sharply. Anthropic allows Claude for refining applications and interview prep but bans it in live interviews and take-homes unless told otherwise. Canva requires AI in its coding round. Meta tightened cheating detection. There is no industry standard, so you must read each company's rules before you start.
| Company | Live coding interview | Source |
|---|---|---|
| Anthropic | No AI: "This is all you", unless they say otherwise | Candidate AI guidance, July 10, 2025 |
| Anthropic | Take-homes: "Complete these without Claude unless we indicate otherwise" | Same page |
| Canva | AI tools expected (Copilot, Cursor, Claude) | Canva Engineering, June 11, 2025 |
| Meta | Full-screen sharing, suspected cheating logged in nearly all rounds | The Pragmatic Engineer, September 18, 2025 |
Anthropic's page is worth reading in full because it is stage by stage. For your resume, "create your first draft yourself, then use Claude to refine it." For prep, use Claude "to research Anthropic, practice your answers, and prepare questions for us."
The lesson for you: the rule changes per company and per stage. The skill underneath does not.
What does testing the real job look like?
Testing the real job means giving a candidate an existing codebase, not a blank file, and asking them to change it. Rodenas argues there is a way to do this without handing over your company's code. The practical version is a small, purpose-built repo with history, tests, and a few real-looking problems.
His full method is behind Medium's wall, so I will not put words in his mouth. Here is how I would build it, based on what the data above says works:
- Custom, not famous. interviewing.io's 25% pass rate for ChatGPT on custom questions is the strongest number in this whole debate.
- Existing code. A few hundred lines with real commit history, odd naming and one outdated pattern.
- A vague ticket. "Users say export is slow sometimes." No inputs, no outputs.
- AI allowed or not, stated up front. Either way, the candidate must explain each change.
- A review step. Hand them a pull request with a subtle bug in it. Canva already grades fixing AI code.
This is closer to the job, and AI does not make it trivial, because the answer depends on reading context the model has not seen.
How do you prepare for brownfield technical interviews?
Prepare by practising the job, not the puzzle. Pick a real open-source repo you have never seen, fix something small in it under a time limit, and say your reasoning out loud. Do this weekly. It trains reading speed, safe changes and explanation, which every interview format now rewards.
Here is the plan, step by step.
- Read each company's AI policy before you apply. Anthropic and Canva publish theirs. If a company does not, ask your recruiter in writing. Breaking a rule you did not know about still ends the interview.
- Keep your fundamentals for the companies that still use them. LeetCode-style rounds have not vanished. Give them maybe a third of your prep time, not all of it.
- Practise on code you did not write. Clone a mid-sized open-source project and find your way around fast.
git clone https://github.com/<org>/<repo>.git && cd <repo>
git log --oneline -20 # what changed recently, and why
git log --stat -5 -- src/ # which files move together
grep -rn "TODO\|FIXME" src/ | head -20 # where the known pain is
- Set a 45-minute timer and fix one "good first issue". Write down what you read first, what you assumed, and what you would test. That note is your interview script.
- Practise reviewing, not just writing. Ask an AI tool to implement a small change, then find what is wrong with it before you run it. Our guide to reviewing AI-generated code has a checklist.
- Narrate trade-offs out loud. "I am not renaming this because three other modules import it" is the sentence interviewers remember.
- Ask the context questions on the day. Who calls this function? Is there a test? What breaks if this is slow? Asking is the job, and it scores well on any rubric built around vague requirements.
If you also face design rounds, the same habit helps there. See why most developers fail system design interviews.
What should hiring teams change first?
Hiring teams should replace at least one blank-file round with a change-this-code round on a synthetic repo, and publish their AI rule for every stage. That costs one engineer a few days to build, protects your real codebase, and fixes the measurement problem instead of the cheating symptom.
| Old round | Replace with | What it measures |
|---|---|---|
| Verbatim LeetCode | Custom problem with new inputs and outputs | Thinking, not recall |
| Blank-file build | Change a small synthetic repo | Reading and safe changes |
| Live whiteboard only | Review a pull request with a planted bug | Judgment on code you did not write |
| Unwritten AI rule | Published rule per stage, like Anthropic's | Fairness, fewer accidental "cheaters" |
Mistakes to avoid
Grinding only puzzles. In the interviewing.io data, the format most exposed to AI is the one most people practise hardest. Custom problems are where preparation shows.
Assuming AI is allowed because it was allowed last time. Anthropic bans it in live rounds. Canva requires it. Check every time.
Using AI you cannot explain. Canva grades whether you can spot and fix problems in AI output. Pasting code you do not understand fails that in minutes.
Rewriting instead of changing. In a brownfield round, rebuilding a module from scratch reads as "did not read the code". Small, tested changes win.
Staying silent while reading. Reading is invisible. If you do not narrate it, the interviewer sees five minutes of nothing.
The bigger picture is the same one I wrote about in code was never the hard part: typing is cheap now, understanding is not.
FAQ
Can I use AI in a technical interview?
It depends on the company and the stage. Anthropic says live interviews are "all you" unless they say otherwise, while Canva expects you to use tools like Copilot, Cursor or Claude. Always read the published policy or ask your recruiter in writing before the interview.
Are LeetCode interviews going away?
Not yet, but they are under pressure. In interviewing.io's experiment, candidates using ChatGPT passed 73% of verbatim LeetCode interviews and no interviewer flagged cheating. Companies are responding with custom questions, stricter screen sharing like Meta's, or AI-allowed rounds like Canva's.
What is a brownfield coding interview?
It is an interview where you work inside existing code instead of a blank file. You might fix a bug, add a feature to an old module, or review a pull request. It tests reading, safe changes and judgment, which are most of a real engineering job.
How can companies test real work without sharing their codebase?
Build a small synthetic repo that looks like real work: commit history, imperfect tests, an outdated pattern and a vague ticket. Nothing confidential leaves the company, and the task still needs the context-reading skills a famous puzzle cannot measure.
This week, clone one open-source repo you have never opened and fix one small issue in 45 minutes, out loud. Then grab the free tools on Art of Code for the boring parts, and when you are ready, browse open roles on the Art of Code jobs board.
Written by Adithya Guttha, Founder of Art of Code.
Sign in to like and save posts.
Keep reading
Discussion
Comments (0)
Want to join the conversation?
Sign in to commentNo comments yet. Be the first to comment!