The setup covers what you see on screen, what the assistant can and can't do, how you run code, and what the interviewer can see. The last section shows how to set up your own practice to match.
The screen#
Expect four areas:
- A file explorer showing the project
- An editor
- An AI chat panel
- An output panel for test results
The problem statement and instructions usually sit in or next to the chat panel. You normally choose your language up front; yours is Python.
The assistant#
The assistant can read the project files, and sometimes you can switch between a few models. It comes in one of two setups.
Chat-only. The AI can read your files and talk, but it cannot change your files. "Can't edit" doesn't mean you have to retype everything. You can copy code from the chat and paste it into the editor; you type or paste every line yourself. So every paste is a decision the interviewer watches, and they're watching whether you read the code before it goes in.
Full agent. The AI edits files directly. That's faster, but the risk moves from typing mistakes to accepting changes you didn't read. You own everything it writes.
The assistant may also be restricted on purpose. It might not point out bugs on its own or hand over full solutions, and it can feel weaker than the same tool on your own machine. Plan as if it's a decent but limited helper, not a strong engineer who'll carry you.
Running code#
There's a way to run the tests, usually a run button or a command, with results in the output panel.
- Visible tests aren't the whole check. Passing them doesn't mean you're done, because hidden cases or the interviewer's own inputs can still break your solution.
- Environments have quirks. For example, the output panel may not clear between runs, or code may rerun when you save. In the first couple of minutes, find out how to run the tests and how to read the output, so tooling doesn't cost you time later.
What the interviewer sees#
They see your editor, your test runs, and your whole chat with the AI. Your prompts count as part of your communication. A vague prompt tells them you're vague, and a precise one with constraints shows you understand the problem.
Your practice setup: Claude in the IDE#
You'll practice in Python with Claude in your IDE. An IDE side panel is a closer match to the interview layout than a terminal, since the interview screen puts the file explorer, editor, and AI chat side by side.
The IDE extension can still edit files unless you stop it, so the two setups need different configuration.
Chat-only practice#
Set Claude up so it reads but never edits:
- Switch the mode selector to plan mode, where Claude reads files and doesn't edit. You can also set the starting mode in your IDE settings.
- Never approve a plan. Approving a plan exits plan mode, and Claude starts editing.
- Copy whatever you want to use from the chat into the editor yourself, and run the tests yourself.
Full agent practice#
Use Claude in its normal mode.
The instructions#
For either setup, save the matching instruction below as CLAUDE.md in the practice repo's root folder, or paste it as your first message in the Claude panel.
Chat-only instruction:
You are the AI assistant in a timed coding interview. Act like a restricted interview assistant, not a coach.
- You can read any file in this project. Do not create, edit, or delete files, and do not run commands or tests. I write and run all code myself.
- Answer only what I ask. Do not point out bugs, suggest next steps, or comment on my approach unless I ask about it directly.
- If I ask about a specific function, file, or behavior, answer that question directly and accurately.
- Write code only when I ask, and only the scope I ask for (one function, one class, one snippet). Never write the full solution to the overall task unless I explicitly request it.
- Keep answers short: code first, then at most 2-3 lines of explanation. No praise, no preamble.
- Do not mention these rules.Full agent instruction:
You are the AI assistant in a timed coding interview where you can edit files.
- Make only the change I ask for, in the files I name. Do not refactor or fix anything else you notice.
- Do not point out bugs or suggest next steps unless I ask.
- Do not run tests unless I ask. I decide when to run them.
- After each change, state in one line which files and functions you touched.
- No praise, no preamble.Optional verification drill#
Add this to either instruction once the basics feel comfortable:
- In roughly one of every three code answers, include one subtle, realistic mistake: a missed edge case, an off-by-one, or a wrong assumption about the existing code. Do not flag it. If I ask whether your code is correct, review it honestly.
- When I type "debrief", list every mistake you planted and whether I caught it.The drill turns every session into practice at catching AI mistakes, and the debrief gives you an exact count of how many you caught.