Directing AI — the new interview signal
📖 Walk me through it — plain English
This lesson is not about an algorithm. It is about a newer interview skill: directing an AI coding tool well. By "AI tool" we mean assistants like Claude, ChatGPT, GitHub Copilot, or Cursor that can write code for you from a plain-English request (a "prompt"). The lesson's core claim is that many companies now watch how you use AI rather than whether you use it. What they are grading is your judgment — can you ask clearly, read the output skeptically, and catch it when it is confidently wrong?
"Confidently wrong" is the key piece of jargon here. AI tools produce answers that look polished and sound sure of themselves, but may quietly contain mistakes: a made-up function that does not actually exist (a "hallucinated API"), an "off-by-one" loop (running one step too many or too few), an error that gets silently ignored, or a half-finished placeholder marked "TODO". The danger is that it reads well, so you trust it without checking.
An everyday analogy: think of the AI as a very fast, eager junior teammate who has read every manual but has never met your specific problem. If you say "go build the thing," they will sprint off and invent details you never asked for. If you hand them a precise spec — "write this one function, with these exact inputs and outputs, that passes this test" — they do excellent work. And like any junior, sometimes they hand you something that looks finished but is subtly broken, so a senior teammate always reviews it before shipping. The interview is really testing whether you behave like that reviewing senior, not like someone who rubber-stamps whatever they are handed.
How to actually use this in a room or on a take-home:
1. Narrate intent, not just the task. Say why and the exact rules ("dedupe by id, keep the latest timestamp, preserve original order"), so the model fills in fewer decisions and you stay in control.
2. Keep the ask small. One function with an exact signature beats "write the whole file." Bigger requests invent more APIs and create more cleanup.
3. Read the diff, then run it. A "diff" is the set of changed lines. Skim for hallucinated calls, off-by-ones, swallowed errors, and TODO stubs — then run a test or trace one concrete example by hand. "It looks right" is how subtle bugs ship.
4. Debug it like a junior. When it is wrong, do not just hit regenerate — ask "what assumption are you making about X?" That usually reveals how it misread your prompt.
5. Override when your version is better, and never paste secrets (API keys, customer data, internal hostnames) into a tool that has not been approved.
Two practical notes the lesson stresses. First, policies differ wildly: some companies expect AI use (Meta, Shopify, Canva), some forbid it and will disqualify you on detection (Amazon, most high-frequency-trading firms), and many are mixed — so if the recruiter does not say, ask. Second, when asked "how do you use AI?", the winning answer is concrete: specific tools for specific jobs, where you deliberately do not use it, and one real story where it was wrong and you caught it. "I use it for everything" and "I don't trust it at all" both lose — one shows no taste, the other reads as out of touch.
Why this is the signal companies care about: the value you add over the AI is judgment. Anyone can generate code now; the scarce skill is knowing what to ask for, spotting the confident mistake, and deciding when your own version is better. Showing the verification — "here's what it got wrong and how I caught it" — proves that judgment far more than "the model wrote it and it worked."
More companies now watch how you use AI, not whether. Take-homes are observed; some onsites include an "AI pair" round. The signal they grade is judgment: prompting clearly, reviewing skeptically, debugging confidently-wrong output.
Bad: "write a function to dedupe." Good: "dedupe this list of {id, ts} keeping the latest ts per id — preserve original order." The model fills in less; you stay in control of decisions.
Ask for one function, not a whole file. Provide exact types, exact signature, the test that should pass. Bigger asks = more invented APIs, more cleanup.
Confidently-wrong is the failure mode. Skim for: hallucinated APIs, off-by-one in loops, silently swallowed errors, "TODO" stubs, made-up imports.
Tests > vibes. If you can't run it, at least trace one example by hand. "It looks right" is how subtle bugs ship.
When it's wrong, don't just regenerate — ask "what assumption are you making about X?" Often surfaces the misread of your prompt.
If you'd write it differently, write it differently. Don't accept worse code because the model produced it. Taste is still your job.
API keys, internal hostnames, customer data. Default to redacting before pasting into any tool not explicitly approved.
If the interviewer asks how you'd build X with AI help, say so plainly: "I'd prompt for the skeleton, then verify by tracing one example and writing a test." That's the answer they want.
The industry has split three ways: companies that require or expect AI tools in the round, companies where it's mixed / per-stage, and companies where using AI is a disqualification. Which company sits in which bucket changes quarterly — the current table lives in the dated Market snapshot. Always confirm per role/stage before the screen.
Practical rule: if the recruiter doesn't mention AI tools, ask. "Should I assume the AI panel is available, or should I treat this as a no-AI screen?"
This is no longer confined to AI-product teams. Even a plain backend loop now increasingly expects baseline AI fluency: you may be asked to whiteboard RAG basics (retrieve relevant chunks, then generate — see RAG end-to-end), name a vector database, or talk through prompt-validation and debugging as a graded skill — alongside the normal algorithms and design. Some big-company loops have added a dedicated GenAI-fluency round; others fold AI fluency (prompt engineering, output validation, debugging) into a "human-led, AI-assisted" format and score it broadly. The depth lives in the AI-product-eng phase; here, just know it can surface anywhere now, so being able to name the basics is table stakes. Which companies do what moves quarterly — the current list is in the Market snapshot.
Almost every modern loop asks this, especially AI-native companies. There's a strong right answer and several losing answers.
- Specific tools for specific jobs — "Claude for prose, planning, code review, debugging unfamiliar libraries. Cursor / Copilot for in-editor completion. ChatGPT-image for quick mockups."
- Where you DON'T use it — "Architecture decisions on my own projects — multi-constraint weighing is mine, not the model's. Production deploys without verifying the diff myself."
- Failure modes you've hit — "Hallucinated API once on a take-home; caught it by running the test. Now I always run the code before trusting it."
- A specific recent example — "Last week I used Claude to debug a hydration mismatch on my Next.js site. It surfaced the password-manager DOM-injection cause faster than I would have alone — but I verified by reading the actual SSR/client diff."
- Collaborator framing — "Treat them as a fast colleague with known failure modes, not as an oracle. Verify the load-bearing parts; trust the boilerplate."
- "I use ChatGPT for everything." No discrimination = no taste.
- "I don't trust AI / I don't use it." Reads as either dogmatic or out-of-touch in 2026. At AI-native companies it's an instant fail.
- "It writes all my code." Now they wonder if you can write any.
- Generic capabilities — "It's helpful for productivity" with no specifics. Signals you haven't actually integrated it.
- No examples of catching its mistakes — suggests you don't actually verify, which is the real signal they're probing for.
The pattern: specific tools, specific jobs, named limits, one verified-and-caught failure. That answer is 60 seconds and signals operator-level fluency. Generic enthusiasm or generic skepticism both lose.