Interview rounds
The take-home is homework. The interview is the call about it.
Sergei Skrylkov, Founder, Trippi · facts checked against the product on 2026-09-30
A take-home assignment is a task you do on your own time — a small app, an analysis, a written plan — and send back by a deadline. The assignment itself is not an interview: nobody is watching, and nobody is asking questions. The interview is the call that follows, usually forty-five minutes to an hour, where one or two people walk through your submission with you and ask why. Most candidates put all their effort into the work and none into that call, and the call is where the decision is made.
How a take-home process runs
- 1The brief arrives by email, with a deadline (often three to seven days) and a suggested time budget (“spend no more than four hours”).
- 2You do the work alone. Read the brief for rules: some companies allow any tools, some ask you to note which ones you used, some ask for no outside help at all. Follow what it says.
- 3You submit: a repository, a notebook, a document or a slide deck, often with a short README.
- 4Someone reviews it before the call and writes down three or four questions.
- 5The follow-up call: you walk them through it, they ask about decisions, and sometimes they ask you to change something live while sharing your screen.
If you are here because you searched for take home assignment after interview: that is the usual order for many teams. A recruiter screen or a first interview comes first, then the take-home, then the call about it, which is often the last technical step before a final round.
An example, start to finish
A typical backend brief: “Build a small service that reads a CSV of orders and returns the total spent per customer through an HTTP endpoint. Include tests. Spend about four hours.”
A reasonable submission: one endpoint, a parser, a handful of tests, a README that says what was left out. Then, on the call, the reviewer opens the README and asks:
- 1“Walk me through your solution, from the request coming in.”
- 2“Why did you parse the file on every request instead of loading it once?”
- 3“What happens if the file has ten million rows?”
- 4“I see you used this CSV library. Why that one and not the standard one?”
- 5“What would you change with another day?”
- 6“Let’s add a filter by date. Can you share your screen and show me where it would go?”
None of these are about whether the code works; they already ran it. They are about whether you can explain decisions you made alone, and whether you know where your own work is weak.
The questions on the follow-up call, decoded
| What they say | What they are testing | The shape of a good answer |
|---|---|---|
| “Walk me through your solution.” | Whether you can explain your own work in order, to someone who has read it | Start from the entry point and follow one request or one row through it. Two minutes, then stop and ask where they want detail. |
| “What would you change with more time?” | Whether you know the weak points before they point them out | Two or three concrete things, in order of importance. “Error handling for bad rows, then caching, then a proper config file.” |
| “Why this library / this approach?” | Whether the choice was a decision or a habit | The reason and the alternative you considered. “It handles quoted commas; the standard one needed extra code for that.” If it was a habit, say so and say what you would check next time. |
| “How would this scale / behave with much more data?” | Whether you can reason beyond the brief | Name the first thing that would break and what you would change. You do not need a full design. |
| “How did you test it?” | Whether tests were an afterthought | What you tested, what you did not, and why that trade-off fit four hours. |
| “What was the hardest part?” | Honesty, and how you work when stuck | One real difficulty and how you got through it. Not “nothing was hard”. |
| “Did you use any tools or help?” | Whether you followed the brief | The true answer, matching whatever the brief allowed. If you used an assistant for part of it and that was allowed, say which part. |
Before the call: re-read your own work
- Open the submission the day before. After a week, your own decisions are less clear to you than you think. Read it as a reviewer would.
- Write down three things you would change. Say them before they are asked for, if the moment comes. It shows the same judgement as a better submission would.
- Make sure it runs from a clean start. If they ask you to share your screen and change something, the first minute should not be fixing your setup.
- Prepare one sentence per decision. “I chose X over Y because Z.” Five of these cover most of the call.
If English is not your first language
The walk-through is the longest stretch of talking you do in the whole process, and it is about technical detail, which makes it tiring in a second language. The follow-up questions are short and quick — “why not just cache it?” — and easy to mishear because they use your own code’s names. Useful sentences to have ready: “The main trade-off was…”, “I chose X over Y because…”, “Given more time, I would…”, “That is a fair point; I did not handle that case.” The last one matters most: agreeing clearly with a fair criticism reads better than a long defence.
See also what “walk me through” is asking for.
What Trippi Cue does here — and where it has no role
Trippi Cue has nothing to do with the take-home itself. It is not a call, there is no one speaking, and the brief sets the rules for help. Do the work yourself, within whatever the brief allows.
The follow-up call is different. If it runs in Google Meet, Zoom on the web or Teams on the web, one click on the Trippi Cue icon in that tab starts it listening to the tab’s audio — not your microphone, and nothing joins the call. The reviewer’s lines appear in the window as they are recognised, with a translation under each if you want one, so a quick “why not just stream the file?” is on screen as text. When a question is addressed to you, a short card follows with a structure to answer from.
It does not see your code or your screen, and it does not know your submission. Before the call, type the three decisions and the three things you would change into the note (“About this meeting”); the cards then use them. If you share your whole screen during the call, the Cue window is visible to the reviewer like any other window. It does not hide itself.
FAQ
Take-home assignment, specifically.
Is getting a take-home assignment a good sign?+
It means you passed the first screen and the team wants to see real work. It is not an offer; many candidates get the assignment, fewer reach the final round.
How long should I spend on a take-home?+
Close to the time the brief suggests. Going far over it can backfire: reviewers compare submissions made in similar time, and a huge one raises the question of what took so long.
What happens after I submit it?+
Usually a review, then a follow-up call of forty-five to sixty minutes where you walk through the work and answer questions about your decisions. Some teams skip the call and decide from the submission alone.
Can Trippi Cue help with the take-home itself?+
No. It listens to a call tab, and the take-home is not a call. It is meant for the follow-up call, where it shows the reviewer’s questions as text and a short structure to answer from.
Should I mention that I used AI tools?+
Follow the brief. If it asks you to list the tools you used, list them honestly. If it asks for no outside help, do not use any.
Read next
Your decisions, explained in order, on the call about them.
Trippi Cue is in the Chrome Web Store. One click on the icon when the call begins, and nothing before that.