Take-home vs live coding vs pair programming
Published
A remote company can't watch you at a whiteboard in its office, so it tests you through a screen, a repository and your writing. Most remote hiring loops are built from four formats:
- A take-home: a small project you build on your own time, usually with a suggested limit of two to six hours, then hand in as a repository.
- Live coding: you solve a problem in a shared editor while an interviewer watches over video, usually 45 to 60 minutes.
- Pair programming: you and an interviewer work together on something closer to real work, often in an existing codebase, with them acting as your teammate.
- System design over video: the classic design round, drawn on a shared whiteboard tool instead of a wall. (The 45 minute round covers how it runs.)
All four test the same two things underneath: can you build it, and can you work with us while you do? Each format just weighs those two differently.
You get a take-home: 'Build a small API for booking meeting rooms. Spend about 4 hours.' You finish the core in 4 hours but have no tests and no README. Do you hand it in now, or spend 3 more hours? What does the reviewer see either way?
What each format is really testing#
Take-homes are closest to the real job: no audience, your own tools, time to think. What they test most is judgement. What did you build first, what did you cut, did you test the part that could break, and can a stranger run your code? They are also your first long writing sample, because the README is where you explain yourself to someone you will never meet before they decide.
Live coding tests whether you can break a problem down and think out loud under a bit of pressure. The interviewer is scoring the conversation as much as the code. A correct solution in silence scores worse than a nearly correct one where they followed every step.
Pair programming is the most "remote" of all. It tests how you work with someone through a screen: do you ask before you change things, do you explain what you are doing, do you take a suggestion well, do you say when you are lost? Your teammates would get the same experience every day.
| Choice | What you gain | What you pay | Pick it when |
|---|---|---|---|
| Take-home | Shows how you work with no pressure and your own tools. Fair to people who freeze when watched. | Takes your evenings, and there is a strong pull to spend 15 hours on a "4 hour" task. | Common at smaller and fully remote companies. Always ask how long it should take, and stick to it. |
| Live coding | Short, the same for every candidate, and shows how you think out loud. | Nerves matter a lot, and the problems are often further from the real job. | The most common screen. Practise talking while you code, which is a separate skill. |
| Pair programming | Closest to a real working day. Shows how you collaborate through a screen. | Depends heavily on the interviewer, and an unfamiliar codebase takes time to read. | Often a later round. Treat the interviewer as a teammate, not a judge. |
The take-home a reviewer enjoys#
A reviewer often has a pile of submissions and less than an hour for each. They tend to go through yours in the same order every time, and most of what goes wrong happens before they read any of your logic. Tick what your submission has, and follow the reviewer through it.
- 1. Clones it, runs one command, it starts.
- 2. No tests. The reviewer now has to check your edge cases by hand, and will assume you did not think about them.
- 3. Finds no in-memory cache, no pagination and a single file of handlers. Was that judgement or did you run out of time? They cannot tell, so they write down the worse reading.
- 4. Skims the history: model, then API, then tests, then a fix. They can see how you work.
- 5. Cannot tell if this took 3 hours or 3 days, so it gets compared against the most polished submission in the pile.
- 6. Opens the main files. Nothing distracting, only the code that matters.
The pattern: nothing you leave unsaid is read in your favour. Missing tests read as "didn't think about edge cases". Missing features with no note read as "ran out of time". A two line note saying "I cut pagination to stay within 4 hours; I would add cursor pagination next because the bookings table grows without limit" turns the same gap into evidence of good judgement.
A README that works for a take-home is short:
## Run it
npm install && npm start # Node 20, no other services needed
npm test
## Decisions
- SQLite instead of Postgres, so you can run it with no setup.
- Double bookings are prevented with a unique index on (room_id, slot),
not a check in code, so two requests at once can't both win.
## What I cut, and what I'd do next
- Pagination on GET /bookings (next: cursor based, by start time).
- Auth. Every request is treated as one user.
## Time
About 4 hours, as suggested.Back to the question at the top of the page: hand it in near the time you were given, with tests for the core logic and that README. A 4 hour submission that is honest about its cuts beats a "4 hour" submission that obviously took 12.
Running a round over video#
Live rounds over video go wrong in ways an office interview can't. Most of it is fixed before you join the call.
- Test the setup the day before: camera, microphone, screen sharing, and the exact tool they named (CoderPad, a shared Google Doc, Excalidraw, VS Code Live Share). Sharing a single window works better than your whole screen, because notifications stay private.
- Have a backup: a phone hotspot in case the Wi-Fi drops, and the interviewer's email to send a message if the call dies.
- Talk more than feels natural. In a room the interviewer sees you thinking. On video, silence looks like being stuck. Say what you are trying, even "I'm checking whether this handles an empty list".
- Check in every few minutes. "Does this approach make sense before I write it out?" On video it is harder for the interviewer to cut in, so give them the chance.
- If you are stuck, say so and say what you are thinking. "I'm not sure how to avoid the double loop. I could sort first, which makes it n log n. Is that acceptable?" That counts as progress. Silent staring does not.
Some remote companies publish their whole hiring process, round by round, in their handbook or on their careers page. A few run paid trial projects instead of take-homes. Read whatever they publish before you apply. Knowing whether round two is a take-home or a pairing session changes how you prepare that week.
In the interview#
Checkpoint#
1. Your take-home is missing a feature you ran out of time for. Best move?
2. What is a reviewer most likely to do first with your take-home?
3. You are stuck in a live coding round over video. What do you do?
- Four formats: take-home, live coding, pair programming, design over video.
- Take-home: respect the time limit, and write down what you cut.
- The reviewer runs it first. One command in the README, or nothing else gets read kindly.
- On video, talk more than feels natural and check in every few minutes.
- Test the tool, camera and screen share the day before, and have a backup connection.
Remote companies hire through four formats: a take-home project, live coding in a shared editor, pair programming with an interviewer acting as a teammate, and system design on a shared whiteboard. All of them test whether you can build the thing and whether you can work with the team while you do it. For a take-home I stay close to the time limit, make it run with one command, test the core logic, and write a short README with my decisions and what I cut and why, because anything I leave unsaid is read against me. In live rounds over video I test my setup the day before, think out loud, check in every few minutes, and when I am stuck I say what I am weighing instead of going silent.