The skill being tested changed, and plenty of candidates haven’t caught up. When a Meta or Canva interviewer tells you to open Cursor and use it however you want, they aren’t doing you a favor. They’re watching how you handle a tool that writes fluent, confident, occasionally wrong code, and your score depends far more on your reactions than on whatever lands in the editor.
Meta rolled this format across engineering loops in late 2025. Candidates have since described the same setup at Shopify, Rippling, LinkedIn, and Canva, and Google runs an AI-assisted variant. The common shape: the problem is bigger than a stock algorithm prompt, you screen-share the entire session, and the interviewer takes notes on the back-and-forth between you and the model rather than the final function alone. Canva’s CTO Brendan Humphreys put it plainly, saying they want to see the interactions with the AI as much as the output of the tool.
The job is judging code, not typing it
Old loops rewarded speed and recall. You memorized the sliding-window trick, wrote it clean, and moved on. With autocomplete switched on, that signal is gone, because the model has the sliding-window trick memorized better than you do. So interviewers moved the bar to the one thing the model can’t do for you, which is decide whether its output is any good.
Meta grades four things in these rounds: problem solving, code quality, verification, and communication. Notice what’s absent. There are no points for writing the function fast. Three of the four are about what you do around the generated code, and the fourth, communication, is mostly about narrating that work out loud so the interviewer can follow your reasoning while you do it.
This trips up strong engineers who are used to earning credit by producing a correct answer quietly. In an AI round, a correct answer you can’t explain reads as a warning sign, because the interviewer can’t tell whether you understood it or the model got lucky. A slightly wrong answer that you catch, question, and fix in front of them reads as a hire.
Verification is the axis people fail
Meta calls it critical verification, and it’s the part candidates skip under time pressure. The tools in these interviews are often seeded to produce subtle errors on purpose: an off-by-one in a boundary check, a lookup that ignores collisions, a function that looks right and quietly mishandles empty input. The interviewer wants to see whether you notice.
The behavior they’re grading for is simple. Do you read the generated code before you run it? A candidate who accepts a 30-line block, runs it, sees green, and moves on has just told the interviewer they’d do the same thing in production. A candidate who pauses, reads line by line, and says “wait, this treats a null the same as a zero, let me check the spec” has shown the exact judgment the whole format exists to measure.
So narrate your checks. Say what you expect the function to return for an empty list before you run it. Point at the branch that handles duplicates and ask whether the problem even allows duplicates. When the model hands you a regex, read it back in plain English. None of this is slow once you’ve practiced it, and all of it is invisible to the interviewer unless you say it out loud.
Prompt so the interviewer can see the plan
There’s a difference between prompting as a shortcut and prompting as a design step, and interviewers can hear it. “Write a function to dedupe this list” is a shortcut. “I’ll keep the outer traversal myself and ask the model for just the merge step, because the merge is where the edge cases live” is a design step, and it happens to be what the strongest candidates do. They point the model at well-scoped subtasks and hold the overall structure themselves.
A reliable pattern is to state the shape of the solution first, in your own words, then delegate the mechanical parts. Decide the data structure. Decide the boundary conditions. Then let the model fill in the string parsing or the API glue while you keep ownership of the parts that carry the actual risk. If you hand the whole problem to the model and start editing whatever it returns, you’ve inverted that, and it shows.
Reading a codebase you didn’t write
Because these problems usually sit in a real or realistic repo instead of a blank file, a chunk of the interview is comprehension. You’ll be asked to add a feature to code you’ve never seen, and the model will happily suggest changes to files it also doesn’t fully understand. Your job is to trace the actual call path before you accept anything.
The candidates who do well here treat the AI as a fast intern who’s confident and sometimes wrong. They ask it to explain a function, then check that explanation against the code instead of trusting it. They grep for callers before changing a signature. When the model proposes editing three files, they ask why, and sometimes the answer reveals it missed a simpler one-file change.
What reads as signal in the room
| Evaluation axis | Weak signal the interviewer notes | Strong signal the interviewer notes |
|---|---|---|
| Problem solving | Pastes the whole prompt into the model and edits whatever comes back | States the approach and edge cases first, then scopes the model to specific subtasks |
| Code quality | Keeps generated code as-is even when it’s convoluted or off-style | Reworks AI output to match the codebase and deletes what isn’t needed |
| Verification | Runs the code, sees one case pass, moves on | Reads before running, names expected outputs, tests empty and boundary inputs |
| Communication | Works silently and can’t explain why the generated code works | Narrates decisions and can defend or discard any line the model wrote |
When to turn the AI off
Knowing when not to reach for the tool is its own signal. If the interviewer asks a pointed design question, say “why a heap here,” that’s a moment to ignore the autocomplete and answer as yourself. Prompting the model to explain your own choice reads as not having one. The same goes for small, well-understood code: writing a five-line helper by hand is often faster than prompting, reading, and correcting, and it shows you can still write code without a copilot in the loop.
Some candidates ask whether they should decline the AI entirely to look strong. In these specific loops that usually backfires, because the round is built to test AI collaboration, and refusing to engage looks like you can’t. The better move is fluent, selective use: fast where the model is reliable, hands-on where it isn’t.
Practice the interaction, not the algorithm
If you’re prepping, change what you rehearse. Grinding more algorithm problems solo trains the wrong muscle for these rounds. Do timed sessions with Cursor or Copilot on and force yourself to narrate every accept and reject out loud, as if someone’s watching, because someone will be. Let the model write something wrong on purpose and practice catching it fast.
The tasks that show up in these rounds tend to look like real work rather than puzzles:
- “Add rate limiting to this existing endpoint, using whatever tools you like.”
- “Here’s a function the last engineer wrote. Find the bug and fix it.” (the bug is usually subtle and the model won’t flag it)
- “Extend this parser to handle a new input format, and tell me what could break.”
- “Rework this module for testability, then write the tests.”
Each of those rewards the same thing: you steering, the model doing scoped labor, and you catching what it gets wrong. Get comfortable being the senior engineer in a pairing session where your partner types incredibly fast and lies with a straight face. That’s the person the interviewer is trying to hire.
Practice the behavioral round:
