What questions do they ask on a take-home follow-up call?

Almost always the same twelve: walk me through it, why this data structure, why this library, where does it break at 100x, what would you test next, which part are you least happy with, how long did it really take, what happens on a concurrent write, what does a caller see when it fails, where would a new field go, did you use AI, and what is not production ready.

How do I answer which part of your code are you least happy with?

Name exactly one part, give the reason it ended up that way, and bound the fix. For example: the list endpoint loads the whole filtered set into memory because pagination was not in the brief, and the fix is keyset pagination on created_at plus an index, about an hour. One flaw with a plan beats a general apology.

How long should the code walkthrough be?

Around three minutes, then stop and let them steer. Budget roughly twenty five seconds on the entry point, seventy five following one request end to end, forty five on a deliberate trade-off, and thirty on known gaps. Reading folders alphabetically or narrating every file burns the reviewer's attention before you reach anything you want scored.

What if I cannot remember why I wrote something?

Say what the code does now, say what you would choose today, and say what would make you revisit it. That reads as an engineer reasoning in real time. Never say you have no idea why it is there, and never disown the line, because a reviewer cannot separate forgetting from not having written it.

Should I admit I used AI on the take-home?

Follow the brief. If it asks for disclosure, disclose specifically: which tool, which parts, and what you checked afterwards. If it forbids AI, that includes the follow-up call. The practical risk is separate from policy, since anything you cannot explain line by line collapses under the second or third why question.

How do I answer where does this break at 100x the data?

Name the first thing that breaks, roughly at what size, and the fix, then name the second thing. Strong answers sound like: the list endpoint loads every filtered row before slicing, so memory and p99 go first around a few hundred thousand rows, and behind that is an N+1 on the customer lookup.

Take-Home Follow-Up Interview Questions: The 12 They Ask

The follow-up call is not a demo, it is a defence. A reviewer has already read your code, picked four or five decisions out of it, and booked 45 minutes to ask why. The questions are repetitive across companies, so below are the twelve that keep coming back, with a strong and a weak answer for each, plus a three minute walkthrough script you can rehearse tonight against a clock.

What is actually being scored

Three things, in this order. Did you write it. Can you defend a decision without either collapsing or digging in. Do you know where your own code is weak before they tell you. Notice what is missing: whether the code is good. Submissions that reach this stage are already good enough, which is why you got the call. It decides whether the person who wrote them can be trusted with a production change.

Most calls run demo, then why questions, then either your questions or a live extension of your own code. The why segment is where offers are won and lost, and it is the segment nobody rehearses.

The twelve questions, with a strong and a weak answer

Assume the common brief shape: a small service over a database, a list endpoint with filtering, one write that changes state, a README. The answers below use that shape so you can see the level of detail that lands. Swap in your own nouns.

1. Walk me through it

Weak: opening the repo and reading the folder tree aloud in alphabetical order.
Strong: entry point, one request followed end to end, one trade-off, known gaps, then stop. The full script is in the next section.

2. Why this data structure?

Weak: "It felt like the natural fit." That is taste, not reasoning, and it invites a harder follow-up.
Strong: access pattern, cost, rejected alternative. "Every request looks an order up by id and the working set is small, so a map keyed by id gives constant time reads. A list would have preserved insertion order, which I do need for pagination, so the endpoint sorts by created_at and id before slicing."

3. Why this library?

Weak: "It is the standard one" or "it has the most stars."
Strong: what it saved, what it costs, and how you would remove it. "It handles query building and migrations, which was about two hours I would rather spend on the status update logic. The cost is that raw SQL now goes through an escape hatch. If I had to drop it, data access sits behind one repository module, so the blast radius is that file."

4. Where does this break at 100x?

Weak: "It should scale fine" or the reflex answer, "I would add caching."
Strong: first failure, rough size, fix, then the second failure. "The list endpoint breaks before the database does. I load the whole filtered set into memory and slice in the application, so memory and p99 go first, somewhere in the hundreds of thousands of rows. The fix is keyset pagination on created_at and id with a matching index. Behind that is an N+1 on the customer lookup, which is a join or a batched load."

5. What would you test next?

Weak: "More coverage" or "integration tests." Both mean you have not thought about which branch is actually dangerous.
Strong: the untested branch, the assertion, the reason it is missing. "Two status updates racing on the same order, asserting the loser gets a conflict rather than silently overwriting. I skipped it because it needs a second connection and a transaction fixture, which was roughly 40 minutes I did not have inside the budget."

6. Which part are you least happy with?

Weak: "Honestly, all of it, I would rewrite the whole thing." Also weak: "Nothing really."
Strong: exactly one part, why it ended up that way, and a bounded fix. "The controller does validation, mapping and persistence in one function. It grew that way because the write was the last thing I built. Splitting validation into a schema and pushing persistence into the repository is under an hour, and I would do it before adding the second write."

7. How long did it actually take, and what did you cut?

Weak: a number that contradicts your commit timestamps, in either direction.
Strong: the real number and the cut list. "Close to six hours against a stated four. The extra two went on the concurrent update. I cut auth, the second filter and the Docker setup, and they are named in the trade-offs section of the README."

8. What happens if two people do this at the same time?

Weak: "The database handles it."
Strong: name the window, the mechanism, and what the client sees. "There is a read-modify-write window between loading the order and saving the new status. I close it with a version column and a conditional update, so the second writer affects zero rows and the API returns 409 with the current version. The alternative was a row lock, which I avoided because the transaction spans an outbound call."

9. What does a caller see when this fails?

Weak: "It throws an error."
Strong: status code, body shape, and what you deliberately left out. "Validation failures return 422 with the field and the rule. Anything unexpected returns 500 with a correlation id that is also in the log line, so the caller has something to quote back. I skipped retries because there is one outbound dependency and no evidence yet about how it fails."

10. If I asked you to add a field, where would it go?

Weak: "Somewhere in the service layer, I would have to look."
Strong: the files in order, out loud, without opening them. "Migration, then the model, then the serializer, then the filter whitelist in the query builder, then the two endpoint tests that assert the response shape." This is the authorship question wearing a costume. Slow navigation of your own repository here does more damage than a wrong technical opinion anywhere else in the call.

11. Did you use AI, and what did you verify?

Weak: a denial that the next three questions puncture, or a shrug that implies you shipped code you never read.
Strong: whatever the brief asked for, stated specifically. If it asked for disclosure: which tool, which parts, and what you checked afterwards. If it forbade AI during the exercise, it forbade it for the call as well.

12. What is not production ready here?

Weak: "I think it is production ready." That is the most expensive sentence in the call.
Strong: three items ranked by what would page someone first. "No authentication on any endpoint. No timeout on the outbound call, so a slow dependency ties up workers. And the migration has no rollback path. Everything else I would let ride for a week and watch."

The three minute walkthrough script

"Walk me through your solution" is an open question with a closed correct length. Three minutes, four movements, then hand control back. Rehearse it out loud until it fits without rushing.

0:00 to 0:25, the entry point

What the thing is, how it starts, where a reader should open first. "It is a small orders service. One command migrates, seeds and starts it. If you are reading it cold, start at routes, then the order service, then the repository. Everything else is wiring."

0:25 to 1:40, one request end to end

Pick the write, not the read, because the write is where the judgement is. Follow a single status update from route to validation to the version check to the response, naming each file as you pass through it. One path, no detours. If they want the list endpoint they will ask for it.

1:40 to 2:25, one deliberate trade-off

Choose it in advance, and choose one you can argue from both sides. "I used optimistic concurrency rather than a lock. It costs the client a retry on conflict and it keeps the transaction short, which matters because of the outbound call. Under heavy contention on a single row a lock would be simpler, and this data does not have that shape."

2:25 to 3:00, known gaps, then stop

Two or three gaps, each with a reason. No auth, in-memory pagination, one untested race. Then say you are happy to go deeper anywhere, and be quiet. Naming your gaps first also sets the agenda, because reviewers tend to probe what you raised rather than hunt for something you did not.

The night before: thirty minutes of rehearsal

Do this	Time	What it prevents
Clone your own submission into a clean directory and run it from the README you wrote	10 min	The demo failing on your own machine, which sets the tone for everything after it
Read your diff as if reviewing a stranger, and write down the three decisions you would attack	10 min	Hearing your weakest choice named by someone else first
Say the three minute script out loud against a timer	5 min	A nine minute ramble that ends before the interesting part
Pre-open the four files a likely extension would touch	5 min	Fumbling through your own repository while someone watches

The trap: disowning your own code to look humble

This is the most common way a good submission loses a call. The reviewer points at a function, the candidate says "yeah, that one is messy, I would redo it." The reviewer points at another, same answer. By the fifth question the candidate has volunteered a defect list, defended nothing, and left the reviewer holding an unanswerable question: if you already knew all of that, why is it in the code you sent?

Self-criticism reads as senior only when it arrives with a reason and a boundary. Use the shape: this was deliberate because X, the cost is Y, if it had to handle Z I would do W. Under that rule, "I would rewrite it" is not humility, it is an admission with no engineering in it.

The mirror trap is real too. Defending every line to the last breath reads as someone who will be expensive in code review. The difference is whether you can say out loud which criticisms you accept and which you do not. And if you genuinely cannot remember why a line exists, say what it does now, say what you would choose today, then move on. Never say you have no idea, because from the other side of the call that is indistinguishable from not having written it.

Every admission needs a reason and a fix with a size on it. Without those, you are just reviewing yourself badly in front of someone who was about to hire you.

Where a copilot is the wrong tool for this call

Worth being direct, since this page is published by a vendor. A follow-up call is the hardest possible case for live AI assistance, and OfferPilot AI is Windows 10 and 11 only, so on a Mac none of it is available to you anyway.

The context lives in your head, not on the internet. A drafted answer is grounded in your resume and the company and role you set. Neither one contains the reason you keyed that map by id. Nothing can defend line 42 of a repository it has never read.
You are doing most of the talking. Metering counts listening time only, so on a call where you speak for two thirds of the hour the clock barely moves. That is a signal about how little there is here for a copilot to do.
Capture exclusion covers screen sharing and recording, nothing more. The overlay is excluded at the operating system level, so it does not appear in Zoom, Teams, Meet, OBS or screenshots while staying visible on your own monitor. It does nothing about a webcam, a proctor, a lockdown browser, eye tracking or a second-device camera. On this call you are sharing your screen and reading your own code with your face visible, so looking anywhere else is the wrong instinct regardless of what is captured.
The brief sets the rules. If it prohibited AI during the exercise, treat the call the same way, and ask beforehand if the wording is ambiguous.

Where preparation tooling earns its place is on either side of this call rather than inside it. The company Q&A generator builds a question bank for a named company and role, which covers the behavioural half of the loop rather than the code half. And if the call ends with a live extension or a fresh problem in a shared editor, that is a different round with different rules, which is what Code Copilot is built for: capture the prompt, get intuition, a dry run and complexity back.

None of it substitutes for the half hour in the table above. The people who pass this call are rarely the ones with the cleverest submission. They are the ones who reopened their own code the night before and remembered why.

The take-home follow-up call: defending your submission