跪拜 Guibai
← Back to the summary

Interviewers Now Hand You a Bug and an AI Tool — and Interrupt You for Three Specific Reasons

Looking through recent interview experiences, you'll notice a clear shift: more and more companies no longer ask you to write algorithms from memory. Instead, they directly throw you a broken frontend project and say — "You can open your AI tool and fix this bug."

This isn't a rumor. Platforms like ShowMeBug have already posted official AI Coding Interview Guidelines in their help center, teaching interviewers how to design assessment points around "candidates using AI." On Niuke, posts like "7 High-Frequency AI Coding Interview Questions", covering Cursor, Claude Code, and Skills, are also going viral. The signal behind this is clear: The interview no longer tests whether you can write code, but whether you can steer AI to write code.

But many people stumble because they think "being allowed to use AI" equals "letting AI write whatever it wants." What truly separates candidates are the following three moments — the exact moments an interviewer interrupts you, because you've exposed a weakness in these three areas.

Interruption Moment 1: You immediately ask AI to rewrite the entire file

The scenario is this: on a list page within a project, data occasionally shows the previous result after switching filter conditions. You open AI, and your first sentence is "This page has a bug, help me rewrite this component."

The interviewer will probably interrupt you at this point: "Don't rush to let AI change it. Can you first locate which line is causing the problem yourself?"

The reason for the interruption isn't that you're slow, but that this action exposes your lack of the engineering habit of "locate first, then fix."

The essence of this bug is actually a race condition: two requests are concurrent, the later one arrives first, and the old response overwrites the new one. An experienced candidate would do three things first —

  1. Reproduce: Manually switch filters quickly to confirm stable reproduction.
  2. Narrow the scope: Open the Network panel, compare the initiation order and response arrival order of the two requests — if the order doesn't match, immediately lock it down as a race condition, not an API issue.
  3. Minimal suspicious code: Locate the useEffect block that initiates the request.

Only at this step do you hand over "which small section to change" to AI, rather than tossing the entire file over.

// Code with a race condition risk: when a later request arrives first, the old response overwrites the new one
useEffect(() => {
  fetch(`/api/list?filter=${filter}`)
    .then(res => res.json())
    .then(data => setList(data));
}, [filter]);

The correct fix is to have AI help you add request cancellation:

useEffect(() => {
  const controller = new AbortController();
  fetch(`/api/list?filter=${filter}`, { signal: controller.signal })
    .then(res => res.json())
    .then(data => setList(data))
    .catch(err => {
      if (err.name !== 'AbortError') console.error(err);
    });
  return () => controller.abort();
}, [filter]);

A side note: if you say "Just add a debounce" at this moment, you'll likely be questioned further. Debounce only reduces the trigger frequency; it doesn't eliminate the race condition — as long as the API is slow enough, the later-arriving-first problem still happens. Being able to proactively state "Debounce isn't enough, we need to cancel the request" means you've already won against most people in that instant.

The capability point assessed in this moment: Problem localization ability. What the interviewer wants to see is that you've already converged the problem into a clear scope before using AI. The prerequisite for letting AI make changes is that you yourself know what should be changed.

Interruption Moment 2: AI provides a fix, and you directly click accept

The second scenario for being interrupted: AI generates a fix in three seconds, you glance at it thinking "seems fine," directly accept it, and prepare to move to the next step.

The interviewer interrupts you: "Don't accept it yet. Can you explain why it's changed this way? Are there any scenarios it hasn't considered?"

This single question tests your critical verification ability regarding AI output.

Many people don't realize that the most common problem with AI bug fixes isn't "not fixing it," but "fixing the surface while burying a new pit." Taking the race condition above as an example, AI might give you a "runnable" but more subtle solution, like a self-incrementing requestId comparison:

// Looks fixed, but actually hides the race condition deeper
let requestId = 0;
useEffect(() => {
  const id = ++requestId;
  fetch(`/api/list?filter=${filter}`)
    .then(res => res.json())
    .then(data => {
      if (id === requestId) setList(data);
    });
}, [filter]);

This code does run in the current component. But it only "discards expired responses"; the request itself still runs to completion — bandwidth is still consumed, server pressure remains; moreover, requestId placed in module scope means two instances of the component on the same page will interfere with each other. In contrast, AbortController truly cancels the request. The difference between the two solutions is the difference between "treating the symptom" and "treating the root cause" — and this is exactly what the interviewer wants to hear you articulate.

So a mature candidate, before accepting, will at least ask themselves three questions:

  1. What is the principle of the fix? (Which request does AbortController interrupt, and why should the old request be discarded)
  2. Are edge cases covered? (Will a request still be in progress when the component unmounts? What happens if you switch rapidly 5 times in a row?)
  3. Are any side effects introduced? (Will canceling the request affect shared logic elsewhere? Does the error handling filter out AbortError?)

If time permits, the best action is to supplement a minimal verification on the spot: write a test case that triggers the race condition, run it, and prove the behavioral difference before and after the fix.

The capability point assessed in this moment: Verification and critical thinking ability. The interviewer doesn't want you to recite textbook answers, but to confirm you won't blindly accept AI output as a black box. Whether you can review AI's code is the watershed between "using AI" and "being used by AI."

Interruption Moment 3: You describe requirements to AI vaguely

The third moment is the easiest to overlook, yet often decisive. Your prompt to AI is: "This is wrong, help me fix it." AI asks you several rounds of questions, you still can't clearly articulate what you want, and the final output is completely off the mark.

The interviewer interrupts you: "What did you just want AI to do? Can you state it clearly in one sentence?"

This moment tests not technology at all, but your ability to deconstruct problems and express them clearly — which is precisely the core of using AI well.

AI's capability ceiling largely depends on the quality of the context you feed it. For fixing the same race condition bug, the gap between two prompts is enormous:

Bad prompt:

This list has a bug, help me fix it.

Good prompt:

The list page initiates a request when filter changes, and there's a race condition: when switching quickly, the old request's response overwrites the new one. Please use AbortController in the useEffect cleanup function to cancel the previous request, handle AbortError, and don't introduce extra dependencies.

The former leaves AI guessing blindly; the latter lets AI produce a near-correct solution in one go. A truly effective on-the-spot prompt template consists of five slots:

Phenomenon: After switching filters on the list page, old data occasionally appears. Reproduction: Switching filters twice rapidly in succession guarantees reproduction. Expectation: Always render only the result of the latest request. Constraint: Use AbortController, introduce no new dependencies. Edge Case: When the component unmounts, unfinished requests must also be canceled.

Fill in these five items, and even if the wording isn't elegant, AI can give an answer that's 80-90% correct in one shot. People who can clearly articulate requirements, phenomena, constraints, and edge cases are several times more efficient with AI than vague expressers.

This is why more and more interviewers are pulling this segment out for separate assessment — it's essentially testing your engineering communication ability, just with the target shifted from "colleague" to "AI."

The capability point assessed in this moment: Deconstruction and expression ability. Whether a prompt is well-written is the external manifestation of whether your engineering thinking is clear.

Why interviewers have started testing this way

Some might ask: Why abandon the good old textbook questions and bother with this?

The reason is actually quite direct. Now, with tools like Claude Code and Codex, one prompt can generate an entire component or feature. The cost of "writing the code" has been driven down. What companies lack is no longer "people who can write," but "people who know what to write and whether what's written is correct." Interviews are simply catching up to this reality: since you'll be collaborating with AI daily after joining, the interview might as well test how you collaborate on the spot.

Moreover, the differentiation of these questions is much higher than textbook questions. Textbook questions can be memorized in advance, but how you use AI on the spot cannot be rehearsed — your habits in locating problems, your attitude towards verifying output, and your clarity in expressing requirements will be exposed clearly within ten-plus minutes.

So, the three interruption moments ultimately test the same thing: When code is no longer scarce, is your judgment scarce?

Interruption Moment Your Exposure Point What the Interviewer is Really Testing
Immediately asking AI to rewrite the whole file Acting without locating Problem localization ability
Directly accepting AI's fix Accepting without verification Critical thinking and verification ability
Vaguely describing requirements Unable to articulate what you want Deconstruction and expression ability

On-the-Spot Bug Fixing Quick Reference Sheet (Recommended to Bookmark)

If asked to fix a bug with AI during an interview, following this sequence will generally keep you out of trouble:

Step Action One-Liner Key Point
1. Reproduce Manually reproduce stably If you can't reproduce it, don't touch AI yet
2. Locate Network/breakpoints to narrow scope Lock down the minimal suspicious code
3. Deconstruct Phenomenon + Reproduction + Expectation + Constraint + Edge Case Prompt quality = Your expression
4. Generate Let AI change a part, not the whole file The smaller the scope, the more accurate the AI
5. Verify Explain the principle + supplement edge case tests Self-review before accepting
6. Regress Confirm no side effects introduced Run related logic after the change

Final Words

AI hasn't made frontend interviews easier; instead, it has raised the bar from "memory" to "judgment." Before, memorizing textbook answers could get you through. Now, one sentence from the interviewer — "Open your AI and fix this" — instantly reveals whether you truly understand or just know how to copy and paste.

If you're also preparing for this type of interview, try practicing the 6 steps above with a real bug from your own project — what you're practicing isn't the code, but your judgment in front of AI. When practicing, it's best to talk through your process aloud as if in an interview. Often, it's not that you don't know how, but that you can't articulate it.

Have you encountered an "AI allowed" segment in your interviews? How did you handle it? Let's chat in the comments.