How to Defend an AI-Assisted Take-Home Assignment in the Follow-Up Interview

#career #interview #javascript #testing

A take-home assignment is not over when you hit submit. In the follow-up, a reviewer may ask you to walk through one decision, change one constraint, and explain what you would improve with more time. The best preparation is a short, repeatable review loop: verify, narrate, modify, and reflect.

Why a working submission is not enough

A take-home is an artifact; the follow-up tests ownership. A reviewer is usually trying to learn four things:

Can you find the important path without rereading every file?
Can you explain why you chose this implementation over a plausible alternative?
Can you safely adapt the code when a requirement changes?
Can you identify limits without turning the conversation into an apology tour?

That means the useful prep unit is not “one more feature.” It is a 20-minute walkthrough of your own repository.

This matters even more when AI was permitted or used during the assignment. Treat tool use as a normal engineering input, not as a substitute for judgment. You should be able to say what a suggestion did, why you kept it, what you changed, and how you verified it. If the instructions required disclosure, disclose it. If they were silent, ask rather than inventing a policy.

Start with a repository inventory

Before rehearsing answers, make a compact inventory of the project. The script below is deliberately boring: it checks whether the basic evidence a reviewer expects is present, without installing dependencies or changing your code.

Save it as takehome-review.mjs, then run node takehome-review.mjs path/to/project.

import { existsSync, readdirSync, readFileSync, statSync } from "node:fs";
import { join, relative } from "node:path";

const root = process.argv[2] ?? ".";
const ignored = new Set(["node_modules", ".git", "dist", "build", "coverage"]);

function walk(dir) {
  return readdirSync(dir).flatMap((name) => {
    if (ignored.has(name)) return [];
    const path = join(dir, name);
    return statSync(path).isDirectory() ? walk(path) : [path];
  });
}

const files = walk(root).map((path) => relative(root, path));
const packagePath = join(root, "package.json");
const packageJson = existsSync(packagePath)
  ? JSON.parse(readFileSync(packagePath, "utf8"))
  : {};

const checks = [
  ["README explains how to run the project", existsSync(join(root, "README.md"))],
  ["Package scripts declare a test command", Boolean(packageJson.scripts?.test)],
  ["A lockfile is present", ["package-lock.json", "bun.lock", "pnpm-lock.yaml", "yarn.lock"].some(
    (name) => existsSync(join(root, name)),
  )],
  ["No accidental .env file is tracked in the folder", !files.some((path) => path === ".env")],
  ["No unresolved TODO/FIXME markers", !files.some((path) =>
    /\.(js|mjs|ts|tsx|py|go|java)$/.test(path) &&
    /\b(TODO|FIXME)\b/.test(readFileSync(join(root, path), "utf8")),
  )],
];

console.table(checks.map(([check, pass]) => ({ check, pass })));
if (checks.some(([, pass]) => !pass)) process.exitCode = 1;

This is not a quality score. It is a prompt for a human review. For example, a deliberate TODO is fine if you can name the trade-off and describe the next safe step. The point is to discover it before someone else does.

Rehearse the four-minute map

Open your editor, start a timer, and explain the codebase in this order:

Minute	What to cover	A useful sentence starter
0–1	User goal and the smallest end-to-end path	“The user starts at X; the request becomes Y; success is visible at Z.”
1–2	Two decisions that constrained the implementation	“I chose A over B because the assignment optimized for …”
2–3	Verification	“I tested the behavior with …; the boundary I did not automate is …”
3–4	Limits and next step	“With another day, I would validate … before adding …”

Do not narrate file names in order. A reviewer can read those. Narrate decisions, boundaries, and evidence.

A concise project map also makes an AI-assisted change easier to defend. “I accepted the initial shape, replaced the error handling because it hid a failure, and added this test” is a much stronger answer than “the tool generated that part.”

Pick one requirement to change live

A follow-up often becomes interesting at the first change request. Prepare one small, reversible change from each of these categories:

Validation: reject an empty or malformed input.
Failure mode: show a useful error when a dependency is unavailable.
Product behavior: add a default, filter, or state transition.
Scale: name what would fail first if the input were 100× larger.

For each change, practice this sequence aloud:

Restate the new constraint and its acceptance criterion.
Locate the narrowest code path that owns it.
Say what test you will add or update before editing.
Make the smallest change.
Re-run the relevant check and explain the result.

That sequence is more persuasive than instantly typing. It shows that you can control scope under pressure.

Use Git as evidence, not theater

A clean commit history can help you reconstruct intent, but do not manufacture one after the fact. Run these commands before the interview to remind yourself where decisions happened:

git log --oneline --reverse
git show --stat HEAD
git diff <base-commit>...HEAD
git status --short

The Git documentation for git diff is useful when you want to compare the submitted change with its base rather than scanning an entire repository. If you used a starter project, be ready to separate what you wrote from what came with it.

What to say about AI assistance

Keep this factual and short. A good answer has four parts:

“I used an AI tool to explore an initial approach for the parsing step. I checked the generated code against the assignment constraints, rewrote the error path, and added a test for malformed input. The remaining limitation is that the implementation is in-memory; for production I would decide persistence based on the expected concurrency and recovery requirements.”

This is neither a confession nor a sales pitch. It gives the reviewer the information they need: scope, judgment, verification, and a real limitation.

For the live conversation itself, a tool such as aceround.app — AI interview assistant can help candidates practice staying structured under follow-up questions. It does not replace understanding the submitted code; the walkthrough above is what makes any prompt useful.

A pre-call checklist

Five minutes before the call, you should be able to answer these without opening a search tab:

What is the one-line problem statement?
Which assumption most shaped the design?
Which test would fail if the main behavior regressed?
What is one known limitation?
What requirement could you change safely in ten minutes?
If asked about AI, what did you use, verify, and change?

If any answer is fuzzy, rehearse that branch once more. A take-home follow-up rewards calm, evidence-based reasoning much more than a polished monologue.