Courses › AI-Assisted Coding › Tools & Pitfalls

Tools & Context

Inline, chat and agent modes, giving the right context, and preparing your setup.

In an AI-assisted round, your tool setup counts as part of your skill. Candidates who know their assistant's modes, and how to give it the right context, spend their time engineering. Candidates who don't spend it fighting the tool. This lesson covers the kinds of assistants you'll meet, how to manage context, and how to get ready before the interview.

The three modes of assistance

Most tools (GitHub Copilot, Cursor, Claude Code, Windsurf and others) offer some mix of these:

[!TIP] Match the mode to the step Use chat to understand the code, an agent for a well-defined slice with tests, and inline completion while writing the tricky logic yourself. Switching modes on purpose, and saying why, is a visible signal of good judgment.

Context is the whole game

An assistant's output can only be as good as what it can see. Give it:

  • The relevant files, explicitly. Mention or attach them rather than hoping it finds them.
  • An example to follow: "Match the pattern in handlers/users.py."
  • Constraints: the language version, libraries you can't add, performance limits.
  • A definition of done: the tests that must pass, the edge cases to handle.

And leave out:

  • The whole repo, when only three files matter. Irrelevant context dilutes its attention.
  • A conversation that has drifted far from the current task. Start a fresh chat for a new slice, with a short summary of the decisions made so far.

Project instruction files

Many tools read a project-level instructions file automatically, for example CLAUDE.md, .cursor/rules or .github/copilot-instructions.md. In a longer exercise, write a few lines of conventions ("use pytest, type hints everywhere, no new dependencies, errors via AppError") at the start. Every later prompt then gets them for free.

Keep the agent on a short leash

  • Give an agent one slice at a time, and ask it to show the plan before it edits.
  • Ask it to run the tests itself and report the results, then check the diff yourself.
  • Stop it early if it starts editing files outside the plan or rewriting tests.
  • Use version control: commit after each verified slice so you can roll back an attempt that went wrong in seconds.

Before the interview

  • Find out the rules. Which tools are allowed? Your own setup, or theirs? Is internet search allowed? Ask the recruiter.
  • Practice with the exact tool you'll use, including its shortcuts for accepting, rejecting, opening chat and switching modes.
  • Prepare your environment: the language runtime installed, a test runner that works, and extensions you don't need turned off.
  • Do a timed dry run: one practice question, from start to finish, in 60 minutes, sharing your screen and narrating as if someone were watching.

[!WARNING] Don't depend on one tool If the company provides a different assistant on the day, the fundamentals carry over: small steps, explicit context, read every diff. Practice at least once with a tool you don't usually use.

Privacy and policy

Only paste interview material into tools you've been told you can use. If a company provides a sandboxed environment, use it. Being careful about what you share with external services is itself a professional signal.

[!TIP] Practice Extend an Unfamiliar Codebase with AI · Prompting Under Pressure · A Winning Workflow