Live coding versus take-homes

From concept questions to real work

The previous course, "Junior Rails interview questions", walked through the technical conversation. Someone asks what a request cycle looks like, or how a validation stops a bad row from reaching the database, and you can now hold that conversation. Most Rails hiring pipelines add one more stage after it. Instead of talking about code, someone hands you a task and asks you to produce some.

That stage comes in two shapes. In a live coding session, you write code out loud on a call while someone watches. In a take-home project, you build something on your own time and submit it for review. This course covers both, because a junior Rails pipeline can hand you either one, and the two reward almost opposite instincts.

What a live coding session tests

A live coding round puts you in a shared editor, usually in the browser and not on your own machine, with an interviewer watching in real time. Sometimes there's a video call; sometimes they only watch the code appear. The prompt is almost always small enough to finish in 30 to 45 minutes: transform a collection, parse a string, implement a small algorithm.

What's measured is rarely whether you land on the fastest solution. It's whether you can think out loud while typing, stay calm when your first approach fails, check your code against a couple of examples before calling it done, and take a hint without spiraling. A candidate who writes a correct but silent solution in 40 minutes often scores worse than one who talks through a slightly rougher one. The interviewer is picturing what it would be like to pair with you on a ticket next Tuesday.

What a take-home project tests

A take-home removes the audience and adds scope. You get a written spec, sometimes a paragraph and sometimes a full document with example inputs and outputs, and a few days to build something. It might be a small Rails feature, an API endpoint, or occasionally a whole tiny app.

Nobody watches you type, so the things a live session can't measure become the whole point. Can you read a spec correctly and build what it asks for, instead of what you assumed? Can you manage your own time without a clock counting down? Do you write tests, or does your only proof that the code works live in your head? Does your README tell a reviewer what you built and why, or must they reverse-engineer your decisions from a diff? A take-home is graded on delivery as well as correctness.

Same skills, different pressure

It's tempting to treat these as two unrelated skills to cram separately, but they share a spine. Both start with a spec you didn't write and must understand before touching code. Both reward a small, working vertical slice over a large, half-finished one. Both expect you to test what you built instead of assuming it works.

What changes is the pressure. Live coding squeezes everything into a visible half hour with someone watching your reasoning. A take-home stretches it into unsupervised days where the reviewer sees only the result and what you wrote about it. Get good at reading a spec and shipping a small, correct slice, and you've covered most of what either format asks. The rest is knowing which behaviors matter more when someone is watching and when nobody is.

How to prepare for either one

Preparation for the two formats overlaps more than it looks. Practicing small coding problems without a timer builds the muscle memory a live round later demands under a clock. Practicing the same problems against a countdown, even one you set yourself, builds the second skill: handling the pressure when the timer, more than the problem, is what makes you nervous.

For take-homes, the best practice isn't grinding algorithms. Build a tiny end-to-end feature from a spec you write yourself, then grade your own README and tests the way a stranger would. Would they convince someone who has never talked to you that you know what you're doing? Neither format punishes someone who prepared for the other, because the overlap is large. One habit helps with both. After finishing a practice problem, write one sentence about what you'd have said out loud or put in a README. Most candidates skip that sentence in practice and then fumble it for real, under pressure.

Which one you'll get

Whether a pipeline uses live coding, a take-home, both or neither varies by company, and company size doesn't predict it. A five-person startup might skip both and talk through your GitHub history. A larger team might run a live round and still ask for a small take-home before an offer. What doesn't vary is what each format checks once it shows up, which is why this course treats them side by side.

What this course covers

Lesson 2 - Building a Rails feature under time: scaffold vs hand-written,
            bin/rails g, migrations, params.expect, and a Minitest check,
            all under a visible or self-imposed clock.
Lesson 3 - Reading a take-home spec: turning a written prompt into a short
            task list, spotting ambiguity, and deciding what's in scope.
Lesson 4 - Enumerable and Hash problems: group_by, tally, each_with_object,
            sum, sort_by, transform_values, filter_map — plus a coding
            challenge you submit and get graded on.
Lesson 5 - Tests and a README that impress: what a reviewer reads,
            and how to write both so your decisions survive without you
            in the room.
Lesson 6 - Submitting and the review call: commit hygiene, how to submit,
            and the call where someone asks you to defend or extend what
            you built.
Lesson 7 - Take-home: putting it all together, and what comes next.

By the end of this course you'll have written a small Rails feature against a clock and solved an Enumerable and Hash problem under the kind of grading a live-coding platform uses. You'll also know what a reviewer looks for in your tests and your README before you submit one for real. None of that needs more Rails knowledge than the earlier courses gave you. It needs you to spend a limited amount of time well, which is the skill both formats test.