Microsoft AI coding interviews: what to prepare and how to work

Start with Microsoft’s actual AI rules

Microsoft’s published candidate code allows responsible AI use during preparation. During assessments and interviews, it expects candidates to demonstrate their own abilities without outside assistance unless permission is explicit. An AI product team, an AI job title, or Microsoft’s use of AI in recruiting does not grant that permission. Check the instructions for your particular round. Microsoft candidate code of conduct.

There are public accounts of permitted AI rounds. One self-reported SDE2 candidate described using Claude during a coding interview, with restrictions on copying the prompt. That account, reviewed October 1, 2026, describes one candidate’s experience and is not independently verified or company policy. It does not establish how frequently the format occurs. Candidate account on Reddit.

The workflow below is our preparation advice for a round in which AI assistance is explicitly allowed. The cache exercise is an original practice scenario, not a reported Microsoft question. If tools are prohibited, use the same reasoning and testing habits while writing the code yourself.

Confirm what “AI interview” means for your round

An interview about building machine learning systems and a coding interview with an AI assistant assess different work. In the first, you may need domain knowledge about training, evaluation, or serving. In the second, you still need to understand ordinary software behavior, but you can delegate some implementation. Your invitation should determine which preparation gets priority.

Ask your recruiter concrete questions before interview day. A statement that AI is allowed leaves important details unresolved: an integrated assistant may be permitted while an external chat or autonomous agent is not. Likewise, permission to generate code need not include permission to upload an entire repository.

• Which rounds permit AI, and which specific tools or accounts should I use?

• Will I work in an existing repository, a browser editor, or my own IDE?

• What problem text and code may I share with the assistant?

• Will prompts and terminal output be visible, and what happens if the tool fails?

Make the environment boring before the interview

Practice the complete loop once on a disposable repository: open the project, locate its test command, make a small edit, run one test, and review a diff. Learn how to cancel generation and reject a change. A familiar model inside an unfamiliar editor can be slower than a modest tool you know well.

Keep a manual fallback. You should be able to explain the next change and write it if the assistant stalls. If a request takes too long, continue reading or testing rather than repeatedly switching models. Tool troubleshooting should not consume the time reserved for demonstrating the solution.

Microsoft’s technical guidance emphasizes breaking down the problem, planning before implementation, executable code, and testing. Those are useful preparation targets regardless of tool choice; they do not establish a separate published AI-round rubric. Microsoft technical interview guidance.

Repair a cache that expires refreshed values too early

Imagine a small TypeScript service with an in-memory TTL cache. Its set(key, value, ttlMs) method stores a value for a duration, and get(key) returns a value or undefined. A bug report says that refreshing a cached item sometimes fails. The repository already has a Map of entries containing value and expiresAt, plus a clock dependency used by tests.

Before asking for code, define observable behavior. Suppose the interviewer agrees that the deadline is exclusive, a replacement gets a fresh deadline, and a nonpositive TTL immediately removes any existing value. Reads do not extend expiration. The cache only promises to expire values when read; periodic memory cleanup is outside this change.

Now make the report concrete. Store A at time 1,000 with a TTL of 500. Replace it with B at time 1,200 with a TTL of 500. At time 1,500, get must return B. At time 1,700, it must return undefined. If the old expiration survives replacement, the first assertion fails. This trace gives you a hypothesis before the assistant offers one.

Give the assistant a small, verifiable job

Inspect the public interface, the set and get implementations, and nearby tests. Check the clock’s unit and how missing values are represented. Run the relevant tests before editing; a pre-existing failure should not become a mysterious regression later.

For the original practice repository, the following prompt gives the assistant enough context to investigate without inviting a rewrite. In a real interview, only share material that the round’s instructions permit.

Read its proposed explanation against the source. If the claim is that replacement updates value but leaves expiresAt unchanged, locate that assignment yourself. The assistant has suggested a cause; the trace and code need to support it. Only then request the smallest implementation and regression test.

Inspect cache.ts and cache.test.ts. Do not edit yet.
Trace what happens when an existing key is replaced with a fresh TTL.
Identify the smallest change that makes the replacement deadline authoritative.
Keep the current public API and injected clock.
List a regression test and any behavior that still needs clarification.

Review the patch against the behavior you agreed on

A plausible repair replaces the entire entry when set runs. Under the agreed contract, handle a nonpositive TTL first by deleting the key and returning; otherwise create a fresh value and deadline together. Avoid mutating only one field. In get, expire an entry when now is greater than or equal to its deadline.

Check generated code for mistakes that are easy to overlook: interpreting milliseconds as seconds, using a truthiness check that rejects 0 or false, or refreshing expiration on every read. Each changes the contract even if a happy-path test passes.

The snippet below illustrates the core update, not a complete cache implementation. A production cache might also need capacity limits or proactive cleanup. Here, explain that expired entries are removed on access, so unread expired entries can remain in memory. Do not add timers just to make the patch look more complete; discuss that separate requirement first.

if (ttlMs <= 0) {
  this.entries.delete(key);
  return;
}

this.entries.set(key, {
  value,
  expiresAt: this.now() + ttlMs,
});

Use tests that can disprove your explanation

Microsoft’s technical preparation page specifically calls attention to testing, boundaries, error conditions, and security implications. Apply that advice to the actual change instead of reciting a generic list of edge cases. Microsoft technical interview guidance.

Use the injected clock to advance time deterministically. Sleeping for real time makes a deadline test slower and can blur whether a boundary failure comes from the implementation or scheduling. Ideally, show the replacement regression failing on the old implementation and passing on the repair.

Ask the assistant for missing cases after you have written your own expectations. It may produce tests that repeat its implementation’s assumptions. For every assertion, explain the requirement it protects. Finish by running the cache suite and the relevant callers’ tests, then inspect the diff for accidental changes.

• A missing key returns undefined; stored values such as 0 and false remain valid.

• A value is readable immediately before its deadline and absent exactly at it.

• Replacing a key preserves the new value beyond the old deadline.

• Replacing with zero TTL removes the old value immediately.

• Reading one key does not extend its deadline or affect another key.

Keep the interviewer inside the reasoning

Narrate decision points rather than every keystroke. Before a tool call: “I think replacement preserves the old deadline. I’ll trace that path and ask the assistant to check my hypothesis.” After a patch: “This replaces both fields together. I’m testing the old deadline because that distinguishes the repair from the original bug.”

If the model adds a cleanup timer, explain your response: “That introduces background behavior beyond the agreed contract. I’m keeping this patch focused and documenting the memory tradeoff.” Rejecting a suggestion with a reason makes your judgment visible.

Leave room for follow-ups. What if the cache must have a maximum size? What if several service instances need consistent data? Which guarantees would change? Answer from the current implementation’s limits, then propose the next design step. A good explanation separates what your code already ensures from what a future version would require.

Avoid the habits that make AI assistance hard to assess

The first trap is outsourcing the requirements. A model can confidently choose sliding expiration, reject zero TTL, or introduce a distributed cache without knowing what the interviewer intended. Clarify those decisions yourself and make the agreed contract part of each implementation request.

The second is hiding uncertainty behind successful output. If the suite passes but you cannot explain an added branch, stop and read it. If a command fails because a dependency is unavailable, report that limitation separately from the code’s correctness. “The test could not run” and “the test passed” are different claims.

The third is spending the whole round generating. Reserve time to compare the final diff with the request, run focused checks, and describe remaining limitations. One understood, verified change gives the interviewer more useful evidence than several unfinished improvements.

A four-session preparation plan

Use short sessions with a concrete output. After each, record one assumption you missed, one model suggestion you rejected, and one test that changed your understanding. These notes reveal what to practice next more clearly than the number of prompts you sent.

Set the final rehearsal’s duration from your actual invitation. Reserve its last quarter for verification and explanation, then work backward to choose a manageable change. If the round includes repository setup, practice that within the same clock. Finish with a short account of what passed, what you could not check, and which requirement you would address next.

• Session 1: Solve a small cache bug without AI. Write the contract and a boundary test before the fix.

• Session 2: Repeat with a permitted assistant. Compare the generated patch with your first solution and explain every difference.

• Session 3: Try an HTTP retry client. Clarify attempt limits, retryable outcomes, cancellation, and how tests avoid real delays.

• Session 4: Run a mock interview with a partner. Ask them to interrupt with a changed requirement and one incorrect model suggestion.