What happens in a live coding session

Picture a cooking test. Nobody hands you a written exam on knife technique. They put you in front of a stove with a short recipe and watch you cook while you explain what you're doing and why. That's much closer to live coding than any school test. You aren't proving you memorized a textbook. You're showing someone, in real time, how you think when you build something small and it doesn't work right away.

This lesson walks through one of these sessions end to end, so the format itself won't surprise you. The previous course covered the technical screen in general. This one zooms in on the fifteen to thirty minutes inside it when you write code while someone watches.

The setup: a shared browser editor

Most entry-level live-coding rounds happen in a shared browser editor: a tool that opens from a link, needs no install, and shows your code to both of you as you type. There's a text area, a "Run" button and an output panel showing what your code printed or returned. The interviewer sees every keystroke, and many of these platforms record the session so it can be watched again later.

That matters for two reasons. First, you can't paste in a finished solution and pretend you wrote it live; a large block of text appearing at once is what these tools surface. Second, the environment is usually minimal: no gems, no external libraries, sometimes no web search, just the standard library. If the prompt says "Ruby," assume you have Array, Hash, String and friends, and nothing more unless told otherwise.

A typical shared-editor layout
-------------------------------------
| Prompt / problem statement         |
|-------------------------------------|
| def solve(input)                    |
|   # your code here                  |
| end                                  |
|-------------------------------------|
| [ Run ]           Output:            |
|                   (appears here)     |
-------------------------------------

The shape of the exercise

At intern and first-junior level, live-coding prompts are small: reverse a string, count word frequency, check whether a number is prime, find the longest word in a sentence. Nobody expects a full application in twenty minutes. The interviewer is testing three skills. Can you turn a plain-English description into a few correct lines? Can you explain your reasoning the whole way? And, only third, do you know the syntax?

An exercise usually arrives in stages. First comes a starting version ("write a method that reverses a string"). Once it works, a follow-up adds a wrinkle ("now do it without the built-in reverse," or "now handle nil input"). That escalation is deliberate. It tests whether you understood your first solution or got lucky.

What the interviewer is watching for

Four things, and none of them is "the right answer in the fewest lines":

1. Do you narrate while you work? Two minutes of silent typing is the most common reason a correct solution reads as a weak interview. The next lesson covers it in depth.
2. Do you clarify before diving in? Starting to code on an ambiguous prompt ("does the string include punctuation? are we case-sensitive?") says more than any syntax mistake.
3. Do you test what you wrote? Running your code on a couple of examples, including an edge case like an empty string, before calling it done is a habit interviewers look for.
4. How do you react when something breaks? Almost everyone hits a bug or a wrong turn. Staying calm, saying "that's not right, let me see why," and working through it is worth more than never making the mistake.

What a live coding round isn't

It isn't a timed multiple-choice quiz or a take-home you finish alone. Nobody expects your first draft to run cleanly; real code rarely does, and interviewers make typos too. At this level it also isn't an algorithms grind. You're very unlikely to implement a red-black tree or reason about Big O on your first internship screen. If you are, that says the company's process doesn't fit the role, not that you're behind.

A realistic timeline

For a fifteen-to-twenty-five-minute segment, expect about two minutes for the interviewer to introduce the prompt and for your clarifying questions. Then ten to fifteen minutes of coding with discussion, and a few minutes at the end to run your solution on examples and maybe extend it. That's a short window. Thirty silent seconds at the start costs a noticeable share of the time you have to show your thinking.

Where this course goes

This lesson gave you the map: a shared editor, a small prompt in stages, and four things being watched: narration, clarification, testing and composure under a bug. The rest of the course builds each into a skill:

• Lesson 2: thinking out loud, the habit that changes how everything else reads.
• Lesson 3: clarifying the problem before you write a line.
• Lesson 4: the classic string and array warm-ups, worked through in Ruby.
• Lesson 5: testing your own code live, the way an interviewer expects.
• Lesson 6: what to do the moment you get stuck.
• Lesson 7: a full mock session that puts it together, plus a coding challenge.

By lesson 7, the format will feel like a conversation you've rehearsed, not a test you hope to survive.