Interview Prep with AI

Use AI for practice, not impersonation

LLMs are genuinely useful interview-prep tools. They can generate drills, critique explanations, play an interviewer who never tires, produce edge cases you would not think of, 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 distinction matters because the failure modes are different in kind. A candidate who practises with AI walks into the room with sharper instincts and broader coverage. A candidate who leans on AI to manufacture answers walks in with a script that collapses on the first follow-up question. Interviewers are trained to probe, and a borrowed answer has no depth behind it. The moment someone asks "why did you choose that approach over the alternative", the gap between practised and impersonated becomes obvious.

The market itself has split on this question, which is why your preparation has to be policy-aware rather than one-size-fits-all. Some companies now allow monitored AI-assisted interviews because that resembles modern engineering work, where nobody writes code without an assistant open in a second pane. Others ban AI during live interviews because they want to measure baseline skill and keep the process fair across candidates who do and do not pay for premium tools. Wired reported on Meta's AI-enabled interview pilot, CodeSignal announced AI-assisted coding assessments, and Built In covered the AI interview cheating debate. Interviewing.io even published a walkthrough of Meta's allowed-AI loop with the real prompts candidates use, which shows just how different an allowed-AI round looks from a banned one and why assuming the wrong policy can cost you an offer.

Ask the policy question early

Before any 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, and it signals that you take both the process and fairness seriously. A company with a clear hiring process should be able to answer it in a sentence. If they cannot, that ambiguity is itself useful information about how the team operates.

There are three common policy buckets, and each one changes how you should spend your prep hours:

If the policy is unclear, assume the strictest reasonable version during the live interview. The asymmetry is brutal: practising as if AI is banned costs you nothing if it turns out to be allowed, but assuming it is allowed when it is banned can end the process on the spot. For take-homes, disclose any tool use in the README if it materially shaped the work. A one-line note such as "I used an assistant to scaffold the test harness and wrote the core logic myself" is the kind of honesty that reads as senior, not as confession.

What good versus weak preparation looks like

Most candidates use AI the same way they use a search engine: they ask for the answer and then read it. That produces weak preparation because reading is not the same as retrieving. The skill an interview measures is your ability to generate a solution under pressure, not to recognise a correct one when shown it.

Strong preparation flips the relationship. You do the work first, then bring the model in as an adversary or a critic.

The single most common mistake is stopping at the first correct-looking output. The second is never closing the loop: people generate a critique, nod at it, and never re-attempt the task to see whether the feedback actually stuck. Treat every AI session as a spaced-repetition cue, not a one-off lesson.

Build better mock interviews

The quality of an AI mock interview is almost entirely a function of the prompt. A lazy prompt produces a quiz; a precise prompt produces a rehearsal that feels uncomfortably close to the real thing.

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.
Stay in character until I say "end interview".

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.
Then tell me which level the answer signals: junior, mid or senior.

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.
If I hand-wave a number, ask me to justify it.

The key move in all three is to stop the model handing you a polished answer too early. By default an LLM wants to be helpful, which in an interview context means it spoils the exercise. The instructions "one question at a time", "ask a follow-up first" and "do not provide the design unless I ask" force it to behave like an interviewer who is testing you rather than a tutor who is teaching you. Adding a closing trigger such as "stay in character until I say end interview" stops it from breaking the simulation halfway through.

A worked example: a behavioural mock loop

Here is what a single round of behavioural practice looks like when the prompt is set up well. The candidate gives a first-draft answer, the model probes, and the answer improves.

Interviewer (AI): Tell me about a time you disagreed with a technical decision.

Candidate: There was a time my team wanted to use a new database and I thought it was risky, so I pushed back and we ended up keeping the old one.

Interviewer (AI): Before I give feedback, two questions. What specifically made it risky, and what did you do beyond "pushing back"? Right now I cannot tell what action you actually took or what the result was.

The candidate now sees the gap. The first answer was a summary, not a story. The second attempt adds the missing structure:

Candidate: We were choosing a datastore for a new events service. The team favoured a document store because it was familiar, but our access pattern was almost entirely range queries on time, which document stores handle poorly. I ran a weekend spike comparing it against a time-series database on a sample of our real traffic, and the time-series option was roughly four times faster on our hottest query. I wrote up the benchmark, shared it before the design review, and proposed the time-series store. We adopted it. Six months on it has held up under a 3x traffic increase without re-architecture.

The difference is not eloquence. It is evidence. The first version asserts a position; the second shows a process, a measurement and an outcome. An AI mock is the cheapest possible place to discover that your story is missing its middle. For more on structuring these answers, see the worked patterns in the role-specific question banks linked at the end.

Use AI to find blind spots

The highest-value use of AI in prep is not generating answers but exposing what you do not know. You can only ask a search engine what you already know to look for; you can ask a model to surface the gaps.

Good uses during preparation:

• Generate edge cases after you solve a coding problem, then check whether your solution handles them.
• Ask for alternative designs after you commit to your own, so you can defend the tradeoff.
• Turn your own project into the interview questions a sceptical reviewer would ask.
• Stress-test a behavioural story for vague claims, unquantified results and missing ownership.
• Convert a job description into the likely interview rounds and the competencies each one targets.
• Practise explaining the same concept at junior, mid and senior depth so you can pitch to the room.

Bad uses:

• Memorising model-generated answers you cannot reconstruct.
• Letting the model choose every tradeoff so you never form your own judgement.
• Practising only with easy, agreeable feedback.
• Skipping official docs in favour of the model's paraphrase, which may be a version behind.
• Submitting generated code you have not run.

That last point deserves a concrete habit. For technical prep, never let generated code reach an interviewer until it has executed. Suppose a model offers this:

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

It looks right. Do not trust "looks right". Write the test and run 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);
  });

  it("treats the empty string as a palindrome", () => {
    expect(isPalindrome("")).toBe(true);
  });
});

The habit matters more than the function. Generated code is not done until it runs, and the muscle of writing a quick test before trusting an output is exactly what distinguishes an engineer using a tool from a candidate hiding behind one. In a monitored AI-assisted interview, that verification step is often the thing being assessed.

Practise explaining how you use AI

For AI-native and senior roles, interviewers increasingly want to see how you work with models, not whether you can avoid them. They are probing for judgement: do you know when the model is wrong, and what do you do about it?

A good explanation includes:

• The goal you were trying to reach.
• The prompt or task framing you used.
• How you evaluated the output rather than accepting it.
• What you changed after seeing the result.
• What failure mode you noticed and how you caught it.

Example of an answer that signals real fluency:

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 it had missed. The useful part was breadth, it produced inputs I would not have thought of. The risky part was that it assumed clean, well-formed input throughout, so I checked the generated cases against a sample of production logs and found three input shapes the model never considered. Those three found a real bug.

That sounds like an engineer using a tool with eyes open. It does not sound like a candidate outsourcing their thinking. The detail that sells it is the failure mode: naming the specific way the tool was wrong and how you caught it is the clearest possible evidence of judgement.

For non-AI roles, keep it simpler and let your respect for the process carry it:

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

Weight your AI prep to what your loop can least fake

The same toolkit serves different goals depending on what your target role's interview actually measures, so calibrate where you spend the hours rather than running generic drills. The useful question is not "what level am I" but "where in this loop would a borrowed answer collapse fastest". That spot is exactly where your independent practice has to be strongest and where a model is least able to stand in for you, so it is where AI prep should run hardest as a critic rather than as a source of answers.

Two forces cut across that table. The more senior the work, the more the loop rewards judgement under ambiguity over recall, and judgement is the one thing a memorised answer cannot supply once the follow-ups start. And the more AI-native the role, the more likely the interviewer wants to watch you use a model well rather than steer around it. If you are targeting AI-focused work, the AI engineer interview questions bank is the closest mirror of what those loops actually ask. Whatever the role, convert its real job description into your drill list rather than practising generic problems in a vacuum.

Do one no-AI rehearsal

Even if you fully expect an AI-assisted interview, do at least one complete rehearsal with no AI at all:

• Solve a coding problem with only the official docs allowed.
• Explain a past project from memory, out loud, with no notes.
• Sketch a system design on paper without model suggestions.
• Answer behavioural questions without any generated phrasing.

This protects your baseline, which is the thing that actually transfers into the room. It also makes your AI-assisted work stronger, because you can only tell when the model is wrong if you have an independent sense of the right answer. The candidates who struggle most in monitored AI interviews are the ones who never built that independent sense and therefore accept confident-but-wrong suggestions without flinching.

A practical cadence that balances both modes:

1. Solve cold, no AI, and time yourself.
2. Bring the model in to critique and to generate edge cases.
3. Re-solve the same problem the next day from memory.
4. Once a week, run a full mock with no tooling to keep the baseline sharp.

Interviewing.io offers structured mock-interview products, LeetCode remains useful for raw algorithm repetition, and role-specific question banks give you breadth across topics. An LLM gives you something none of those do as cheaply: unlimited, on-demand, adversarial repetition, provided you design the practice well. The standing risk is false confidence. The model will be too polite by default and will praise mediocre answers unless you explicitly demand strict, level-calibrated feedback. Ask for the harshest honest assessment, every time.

Failure patterns that survive diligent prep

These are the habits that quietly sabotage otherwise careful candidates, precisely because each one feels like work:

• Stopping at the first plausible output instead of verifying it.
• Memorising phrasing you cannot reconstruct under follow-up questions.
• Never re-attempting a task after receiving feedback.
• Treating the model's paraphrase as authoritative over official documentation.
• Assuming a permissive AI policy and getting caught out by a strict one.
• Practising only behavioural or only technical material and neglecting the other.
• Letting the model talk you out of a correct instinct because it sounded confident.

FAQ

Is using AI to prepare for interviews considered cheating? No. Preparing with AI is no more cheating than preparing with a textbook or a study partner. Cheating is using undisclosed AI during a live interview that prohibits it, or submitting work you did not do and cannot explain. Preparation and live conduct are two separate questions; keep them separate.

Should I tell the interviewer I practised with AI? There is no need to volunteer it, just as you would not announce which books you read. What matters is honesty about live tool use and about authorship of any take-home submission.

Can interviewers tell if I memorised an AI answer? Usually, yes. Memorised answers are fluent on the surface and hollow underneath. The first genuine follow-up, "why this and not that", exposes the absence of real reasoning. Practise the reasoning, not the recital.

What if the company expects me to use AI and I am out of practice? Treat the AI workflow itself as a skill to rehearse: prompt design, fast verification, knowing when to discard a suggestion. Run several timed sessions where you solve real problems with an assistant open, so the tooling is second nature rather than a distraction on the day.

How much of my prep time should be AI-assisted? A rough split is most of your repetition with AI for breadth and feedback, but a recurring, deliberate slice with no tooling at all to protect the baseline that actually shows up in a banned-AI interview.

Where to take this next

Use AI to practise, then point that practice at the rounds it prepares you for:

• Mock interview practice plan, to turn these prompts into a repeatable weekly loop.
• AI engineer interview prep, if you are targeting roles that probe model judgement directly.
• Take-home coding in the LLM era, for handling disclosure and authorship on unsupervised work.
• Debugging with an AI workflow, to build the verify-before-you-trust habit this guide depends on.

Sources

• Wired. Meta's AI-enabled coding interview pilot.
• CodeSignal. AI-assisted coding assessments and interviews.
• Built In. The AI job interview cheating debate.
• Interviewing.io. How to use AI in Meta's AI-assisted coding interview, with real prompts and examples.