Courses › AI-Assisted Coding › The New Round

Prompting Under Pressure

Giving an assistant the context, constraints and examples it needs.

In an interview, every round-trip with the assistant costs time. Good prompts get usable output on the first or second try; vague prompts produce plausible-looking code that does the wrong thing. The difference comes down to context, constraints and a definition of done.

The anatomy of a good prompt

  • Goal — what you want, in one sentence
  • Context — the relevant files, existing patterns and data structures
  • Constraints — conventions, libraries allowed or forbidden, performance limits
  • Interface — the function signature, inputs and outputs
  • Definition of done — examples, edge cases or tests it must pass

Weak

add filtering to the list command

Strong

In cli.py, extend the `list` command to accept `--status {open,done}` and
`--due-before YYYY-MM-DD`. Follow the existing argparse pattern used by `add`.
Filtering logic should live in a pure function `filter_tasks(tasks, status, due_before)`
in tasks.py (no I/O) so it's unit-testable. Invalid dates should raise ValueError
with a clear message, which the CLI prints and exits with code 2.
Also add pytest tests for: no filters, each filter alone, both together,
and an invalid date.

The strong prompt takes 30 seconds longer to write and saves several rounds of correction.

Techniques that work well

  • Point to an example in the codebase: "follow the structure of create_order in handlers/orders.py."
  • Ask for tests first for logic-heavy pieces, review them, then ask for the implementation.
  • Ask for a plan before code on larger steps: "Outline the changes you'd make, file by file. Don't write code yet." Review the plan, then proceed.
  • Constrain the scope: "Only modify tasks.py. Don't change the public interface."
  • Share the actual error output when debugging, with your hypothesis: "I think the date comparison fails because due dates are strings — here's the traceback."

Things to avoid

  • Pasting the entire problem and asking for a full solution — you lose control of the design, and the interviewer sees no engineering
  • Accepting large diffs you haven't read
  • Repeated "fix it" loops without diagnosing the cause yourself
  • Letting the assistant pick the architecture silently — make design decisions explicit and yours

[!INTERVIEW] Narrate your prompts Read your prompt aloud or summarize it as you write it: "I'm asking it to write the parser, following the pattern in add, and to include tests for invalid dates." It shows the interviewer exactly how you decompose and specify work — the core skill being evaluated.