Interview Prep with AI

Use AI for practice, not impersonation

LLMs are useful interview-prep tools. They can generate drills, critique explanations, play an interviewer, produce edge cases and help you turn vague experience into clearer stories. They are also risky if you let them replace thinking. The line is simple: use AI to practise and inspect your work, not to impersonate ability you do not have.

The market has split. Some companies allow monitored AI-assisted interviews because that resembles modern engineering work. Others ban AI during live interviews because they want baseline skill and a fair process. Wired reported on Meta's AI-enabled interview pilot, CodeSignal announced AI-assisted coding assessments, and Built In covered the AI interview cheating debate. Candidate discussions on ExperiencedDevs show why policies vary.

Ask the policy question early

Before an assessment, ask:

Could you confirm the policy on AI tools for this stage? I want to make sure I prepare and complete the exercise in the format the team expects.

That question is not suspicious. It is professional. A company with a clear process should be able to answer.

There are three common policy buckets:

If the policy is unclear, assume the strictest reasonable version during the live interview. For take-homes, disclose allowed tool use in the README if it materially shaped the work.

Build better mock interviews

Bad AI mock prompt:

Ask me JavaScript interview questions.

Better prompt:

Act as a senior frontend interviewer for a 45-minute React interview.
Ask one question at a time.
Focus on state management, accessibility, async data fetching and debugging.
After each answer, ask one follow-up before giving feedback.
Score my answer against clarity, correctness, tradeoffs and level signal.

For behavioural practice:

Act as an engineering manager interviewing a mid-level backend engineer.
Ask behavioural questions about incidents, conflict, ownership and ambiguity.
When I answer, identify missing Situation, Action and Result details.
Do not rewrite my answer until after you have asked two clarifying questions.

For system design:

Act as a system design interviewer.
Give me one requirement at a time for a notifications system.
Challenge my assumptions about scale, failure modes, storage and observability.
Do not provide the design unless I ask for feedback at the end.

The key is to stop the model giving you a polished answer too early. Make it behave like an interviewer.

Use AI to find blind spots

Good uses during preparation:

• Generate edge cases after you solve a coding problem.
• Ask for alternative designs after you make your own.
• Turn your project into likely interview questions.
• Stress-test a behavioural story for vague claims.
• Convert a job description into likely interview rounds.
• Practise explaining the same concept at junior, mid and senior depth.

Bad uses:

• Memorising model-generated answers.
• Letting the model choose every tradeoff.
• Practising only with easy feedback.
• Skipping official docs.
• Submitting unverified generated code.

For technical prep, force verification:

export function isPalindrome(input: string): boolean {
  const normalised = input.toLowerCase().replace(/[^a-z0-9]/g, "");
  return normalised === [...normalised].reverse().join("");
}

If an LLM suggests this function, test it:

import { describe, expect, it } from "vitest";
import { isPalindrome } from "./is-palindrome";

describe("isPalindrome", () => {
  it("ignores punctuation and case", () => {
    expect(isPalindrome("A man, a plan, a canal: Panama")).toBe(true);
  });

  it("rejects non-palindromes", () => {
    expect(isPalindrome("careerprep")).toBe(false);
  });
});

The habit matters more than the function. Generated code is not done until it runs.

Practise explaining AI use

For AI-native roles, interviewers may want to see how you work with models. A good explanation includes:

• The goal.
• The prompt or task framing.
• How you evaluated the output.
• What you changed.
• What failure mode you noticed.

Example:

I used the model to generate candidate test cases for the parser, then I selected the cases that matched our real inputs and added two malformed examples the model missed. The useful part was breadth. The risky part was that it assumed clean input, so I checked the cases against production logs.

That sounds like an engineer using a tool. It does not sound like a candidate hiding behind one.

For non-AI roles, keep it simpler:

I use AI during preparation to generate practice prompts and critique explanations. During interviews I follow the company's policy. If tools are not allowed, I do the work without them.

Do one no-AI rehearsal

Even if you expect AI-assisted interviews, do at least one full rehearsal without AI:

• Solve a coding problem with only docs allowed.
• Explain a project from memory.
• Draw a system design without model suggestions.
• Answer behavioural questions without generated phrasing.

This protects your baseline. It also makes AI-assisted work stronger because you can tell when the model is wrong.

Interviewing.io offers mock-interview products, LeetCode remains useful for algorithm drills, and role-specific question banks can help with breadth. But an LLM gives you cheap repetition if you design the practice well. The downside is false confidence. The model may be too polite unless you explicitly ask for strict feedback.

Continue your prep

Use AI to practise, then test yourself against real role material:

• AI engineer interview questions
• ML engineer salary guide
• ML engineer resume template