AI-assisted coding interviews

More companies now test how you work inside an existing codebase, with an AI assistant, instead of (or as well as) a blank-editor algorithm question. This page covers the formats candidates have reported as of October 2026, what graders say they reward, and a routine that works in all of them. Formats change often, so check what your recruiter sends you.

The formats

Structured: bug, then feature, then speed (Meta-style)

Reported for Meta's AI-enabled coding round, and similar at LinkedIn: about 60 minutes in CoderPad with three panels (files, editor, AI chat). The assistant can read the project but not edit it. The round usually runs in phases:

1. Fix a bug in the existing code.
2. Build a feature, often a hundred-plus lines.
3. Make it fast once bigger tests show the straightforward version is too slow. Reported examples: greedy → trie, DFS → BFS with a bitmask.

You'll be graded on problem solving, code quality, verification (testing your code and checking the AI's), and communication.

Practise it with Courier maze, which follows the same arc with a maze, gates and keys.

Bug squash (Stripe-style)

Reported for Stripe: 45–60 minutes in a real codebase with failing behaviour to track down. The grading is on method (reproduce, narrow down, smallest fix, prove it), not speed. A related "integration" round has you work against an existing API.

Practise it with Order pages: a support ticket, one root cause and a hidden suite that catches symptom-only patches.

Bring your own environment (Shopify-style)

Reported for Shopify: you work in your own IDE with whatever AI you use at work, sharing your screen. The repo is often nearly empty, and the problem grows in steps (build small, then extend). Reported problems include a per-merchant sliding-window rate limiter, an LRU cache and grid robots. Graders look at whether you direct the AI, at design, testing and readability, and at how you handle imperfect AI code.

Practise it with Rate limiter. Download the zip, work in your own editor, then upload the files you changed to grade them.

Repository tasks on an assessment platform (HackerRank, used by Atlassian and others)

Platforms now ship repository tasks: a production-style made-up app, a support-ticket bug or a PRD feature, and an agent with plan and agent modes. Atlassian's reported 60-minute repo session grades repo comprehension, directing the agent, verification through tests, communication, and protecting existing behaviour. Their guidance puts it well: the strongest candidate isn't necessarily the one who writes the most code.

All three rounds here follow this ticket → tests → hidden-suite shape.

Code comprehension (Google pilot)

Reported as a 2026 pilot for some junior and mid-level roles: read, debug and optimise an existing codebase with Gemini. It's graded partly on AI fluency: how you prompt, whether you validate the output, and how you debug.

Still no AI

Many companies still ban AI in interviews, and some are moving back to onsite rounds. Algorithms and data structures still matter in AI rounds too: phase 3 of a round is usually a classic technique (a heap, a monotonic queue, BFS over states) hiding in a real codebase.

What graders reward

Across the published rubrics, the same few things come up:

• Understand before you prompt. Read the ticket and the README, run the tests, and find the code path yourself first.
• Keep the hard decisions. Use the AI for well-defined pieces: explaining a function, tracing an input, writing tests, boilerplate.
• Verify everything. Review AI output as if a colleague wrote it, run it, and add the edge cases it forgot. Be able to explain every line you submit.
• Protect existing behaviour. Make the smallest change that fixes the root cause, and rerun the old tests.
• Narrate. Say what you're checking and why.

The weak pattern is the reverse: pasting the whole task into the AI, accepting what comes back, and not being able to say why it works.

A routine that works

1. Orient (3–5 min). README, file tree, then the entry point the ticket names. Run the visible tests.
2. Reproduce. Get a failing test or a concrete input that shows the problem.
3. Trace. Follow the call path with that input. This is a good job to give the AI ("walk through paginate with 25 items, page 1, and list each variable").
4. Fix the root cause, not the symptom. Ask what else the same bug would break.
5. Prove it. Rerun everything, then add the edge cases: empty input, exact boundaries, the other direction.
6. For the speed phase, work out the complexity before you change anything. "What does this cost per call with n = 200,000?" usually points straight at the fix.

Each round's debrief shows this routine on that repo, plus prompts that work well there.