跪拜 Guibai
← Back to the summary

AI Coding Interviews Now Test Judgment, Not Syntax

The head of Starboard, James Lowman, likes to ask during interviews: "Tell me about the three Claude Code skills you've written recently." An intern answered with just two words — None. The reason was they couldn't afford the paid tool.

Last week, LeadDev published an article with a title that translates to: Your interview questions assume candidates can afford Claude Code Max.

I was stunned when I came across this. Not because I felt sorry for the intern, but because I suddenly realized — over the past two years, in all the AI-related interview questions I've faced, observed, or heard about, very few people truly understood what the interviewer was actually asking.

The Interview Scene: They Really Ask You to Open Your AI Tool and Code

This is not a joke. A highly upvoted interview experience on Zhihu said, verbatim:

"AI coding is standard with Cursor / Claude Code (using AI tools to solve problems is allowed during the interview, and they observe how you use it)."

Another frontend developer who interviewed at five companies focusing on AI business wrote:

"Interviewers nowadays have zero interest in drilling you on the old 'Eight-Legged Essay' rote memorization... Many interviewers skip the fundamentals right from the start and jump straight into scenario-based questions on AI business implementation, streaming interactions, model frontend integration, and engineering quality control."

The key point isn't "have you used AI," but how you use it.

An author on cnblogs put it bluntly — "In an AI coding interview, I only look at whether you are the driver." He said he observed a phenomenon: many people talk about AI like they're reading the evening news. DeepSeek, Agent, context window, reasoning model, multimodal, MCP — they rattle off the terms fluently, but it's all "knowing," not a single instance of "doing."

These are the people interviewers want to filter out.

You Think They're Testing Coding, But They're Really Testing Whether You Can Find Fault with AI

Let me first lay out the most common misconception. Many people think an AI interview goes like this: the interviewer asks if you use AI, you say yes, and then you talk about using Cursor to write a component. That score isn't enough anymore.

What interviewers are really watching for, I've summarized, has nothing to do with "can you use AI to write runnable code."

Let's pick a real question. A recurring problem from the interview experiences mentioned earlier: Can you solve SSE streaming rendering lag?

AI will likely generate streaming dialogue code that looks like this:

// AI's first draft — runs, but lags as users increase
function ChatPanel() {
  const [text, setText] = useState('');
  
  useEffect(() => {
    const es = new EventSource('/api/chat');
    es.onmessage = (e) => {
      setText(prev => prev + e.data);  // ← Concatenates and re-renders the whole string on every chunk
    };
    return () => es.close();
  }, []);
  
  return <div className="whitespace-pre-wrap">{text}</div>;
}

"It runs." But if you're the interviewer, watching a candidate copy this verbatim without a single question, you basically know — this person has never used AI to write a real, production streaming feature.

Because in a real production environment, this code has several fatal flaws:

What the interviewer wants to see is whether you can spot these pitfalls yourself and then fix them:

// Improved version — proactively pointing out these issues on the spot is a bonus
function ChatPanel() {
  const [chunks, setChunks] = useState<string[]>([]);
  const [done, setDone] = useState(false);
  
  useEffect(() => {
    const controller = new AbortController();
    
    fetch('/api/chat', { signal: controller.signal })
      .then(res => readStream(res.body!, controller))  // Uses ReadableStream to bypass EventSource pitfalls
      .finally(() => setDone(true));
    
    return () => controller.abort();  // Cancels on unmount, preventing leaks
  }, []);
  
  const deferredChunks = useDeferredValue(chunks);
  const content = useMemo(() => deferredChunks.join(''), [deferredChunks]);
  
  return (
    <div className="whitespace-pre-wrap">
      {content}
      {!done && <span className="animate-pulse">▍</span>}
    </div>
  );
}

None of this is advanced. AbortController, useDeferredValue, useMemo — these are all basic React APIs. AI won't proactively add these for you by default — it assumes you just want "runnable code."

What the interviewer is watching is whether you can see that the AI's output is rough work and identify what's missing and what needs to be added. This is what "driver" means — the AI is the car, you are the one holding the steering wheel. The car doesn't change lanes on its own; you make it change.

A More Subtle Trap — The Type Pitfalls AI Buries

The high-frequency real questions listed in that Zhihu interview experience are almost all "find the trap" types:

Not a single one asks "how to write it." They all ask "how to constrain the uncertainty of AI's output."

The logic is simple — AI writing code is no longer rare. What's rare is knowing where AI's output will go wrong and how to catch it when it does.

Here's a common example. The tool-call types AI generates look like this nine times out of ten:

// AI default — flattens all possibilities into one big type
type AgentResponse = {
  thought?: string;
  action?: string;
  result?: string;
  status?: 'thinking' | 'executing' | 'observing' | 'done';
  error?: string;
  // ...a pile of optional fields
};

It runs. But the types are basically useless — when you get an AgentResponse, you have no idea which fields definitely exist and which definitely don't in that state. What the interviewer wants to see is you breaking it down into a discriminated union that binds "state-data" together:

// Discriminated union — each state only carries its relevant fields, the compiler checks for errors
type AgentState =
  | { status: 'thinking'; thought: string }
  | { status: 'executing'; action: string; tool: string }
  | { status: 'observing'; action: string; result: string }
  | { status: 'done'; result: string }
  | { status: 'error'; action: string; error: string };

function handle(state: AgentState) {
  if (state.status === 'done') {
    console.log(state.result);       // ✅ Has result
    // console.log(state.thought);    // ❌ Compile error — 'done' state shouldn't have 'thought'
  }
}

Again, not a high-level technique. But AI won't write it this way by default — it defaults to giving you the "fastest runnable version." What the interviewer is filtering for is whether you have the awareness to take "AI's rough work" and refine it to an engineering grade.

Back to That Intern — The Most Heartbreaking Part

"None, can't afford it."

This really can't be dismissed with just "he didn't work hard enough."

LeadDev cited a paper proposing an "Agentic Inequality" framework with three dimensions:

Dimension Meaning
availability Whether a specific agentic system is available to you
quality How strong it is
quantity How many agents you can run simultaneously

The author made a poignant point: agents are different from previous technologies — they are not tools, they are "labor that can act on your behalf." Inequality with tools has a linear gap; inequality with "labor" has a gap amplified by compounding interest.

Four barriers act as gatekeepers: money, compute, expertise, time. Sharp's original point is that when you ask about skills/workflows, you're testing not just ability, but also "who can afford to practice like this." It turns temporary resource gaps into permanent filtering mechanisms.

The costs are on the table: Claude Code Pro is about $20/month, Max 5x is $100, Max 20x is $200. Some developers tracked their usage for 8 months, burning about 10 billion tokens, which at API prices far exceeds the subscription cost. For a junior-year intern, $200/month is a real financial barrier.

So the cruelty of James Lowman's question isn't "do you know how to write skills," it's "do you have the financial margin to practice a paid tool to proficiency."

You Don't Need Max to Prove You're the Driver

This is what I really want to hammer home. Most people can't afford Max, and there's no need to buy it just for an interview.

The subtext of that LeadDev article is clear: building interview questions on the assumption that "candidates can afford a specific paid tool" is unfair. But for individuals, complaining about unfairness is useless; you need a way to prove yourself.

The key is to break down "knowing how to use AI" into verifiable capabilities, rather than fixating on "which subscription plan I have." Here are a few angles that cost nothing to practice and can be discussed in an interview:

One: Use the free DeepSeek API + open-source DSH to build your own coding agent

A couple of days ago, DeepSeek open-sourced Harness under the MIT license. One command, npx @deepseek-ai/dsh web, starts a local Web UI. Paired with DeepSeek's API, the cost is a fraction of Claude's. You can run through the full loop of "model + tools + Agent Loop" in this environment — this is far more informative than "I subscribed to Claude Code Max."

In an interview, you can say: "I used DSH with DeepSeek V4 to run complete frontend projects. I understand clearly how context management, tool calls, and fault-tolerant retries work together in Harness." — This is stronger than "I've used Cursor."

Two: Practice "vetoing AI code" — this is a new interview dimension

A Node.js interview guide on CSDN pointed out a new trend: interviewers directly ask, "Have you written Node with AI? When did you veto the AI's code?"

If you can't answer this, you're basically the type who "lets AI write and doesn't review it yourself." Start saving them — AI's proposed solutions, which ones you didn't use, why you didn't use them, what you changed them to. Accumulate a few real cases, and you can talk for twenty minutes in an interview.

Three: Build a real frontend project that integrates AI

Not "use AI to write a project," but "write a project that integrates AI." A chat interface, a streaming render, an error fallback for AI output. This kind of project can be deeply probed in an interview because it has real boundary problems, not just a wrapper calling an API.

Green Flags and Red Flags When Using AI On-Site

Combining those interview experiences and the LeadDev discussion, when a candidate uses AI to solve a problem on-site, the problem-solving process itself becomes the observed test:

Behavior Signal
Directly pastes AI output without reading or reviewing 🔴 Red Flag — Not even a "quality inspector," just a porter
After AI outputs, proactively points out what's unsafe or where pitfalls lie 🟢 Green Flag — Driver awareness
Will ask AI back, "What about this edge case?" instead of accepting everything 🟢 Green Flag
Only knows one tool, can't answer about alternatives 🟡 Neutral — Narrow perspective
Can clearly explain the principles behind "why the AI wrote the code this way" 🟢 Green Flag — Hardest to fake
Just rattles off buzzwords (MCP/Agent/Context Window) with zero hands-on evidence 🔴 Red Flag — The evening news type

The last line is the interviewer's most sensitive red line. You can rattle off a string of terms, but if you have nothing real you've actually done, tuned, or tripped over to back it up, you'll be exposed the moment they dig deeper.

What It Ultimately Tests

After AI can write code, "being able to write code" is no longer a scarce ability; "judging whether this code should be written this way" is.

When James Lowman asks, "Have you written any skills?" he's asking, "Have you used a tool to the point where you can modify it?" — this is the difference between a driver and a passenger. That intern answered "None." The mistake wasn't not buying Max; the mistake was not taking any free tool to that depth.

Tool inequality is real, and LeadDev deserves respect for poking a hole in that paper window. But for individuals, the path to proving yourself isn't locked shut — DSH is open-sourced, the DeepSeek API is dirt cheap, Cursor has a free tier. The barrier was never "can you afford Max," but "have you spent the time to use a tool to the point where you can articulate the details."

That barrier of time, at least, doesn't discriminate.

What's the trickiest AI question you've ever been asked? Have you ever encountered an on-site interview where they let you use AI tools to solve problems? Drop a comment, and I'll compile a collection of interview experiences.

If you found this useful, hit like 👍 so more people currently interviewing can see it.