Topic 18.2
Live-Coding Rounds: Build This Chart in 30 Minutes
In one line
A live-coding round asks you to build a small chart from a blank page while someone watches and listens. You learn the clock, the order of work, what interviewers score, and three complete builds: a bar chart, a line with a tooltip and a sparkline.
Think of it like this
A cooking show round. The judges do not only taste the dish. They watch whether you read the ingredients, plan, keep the kitchen tidy, taste as you go and say what you are doing. A live-coding round is the same: the chart is the dish, and the talking is half of the score.
Words you'll meet
New words in this topic, in plain English. Come back here whenever one feels fuzzy.
- live coding
- An interview round where you write code while the interviewer watches and talks with you.
- think aloud
- Saying your decisions and doubts while you work, so the listener follows your reasoning.
- scaffold
- A first small version that runs, which you then grow step by step.
- bisector
- A D3 helper that finds, on sorted data, the position where a value would go. Used to find the nearest point to the pointer.
- sparkline
- A tiny line chart with no axes, small enough to sit in a sentence or a tile.
- direct label
- A value written next to its mark, so the reader does not look back and forth at an axis.
- edge case
- An unusual input (empty list, one row, all zeros) that the happy path ignores.
Step by step
01Plan the 30 minutes before you type
A fair split: 3 minutes questions, 5 data and scales, 7 marks, 5 axes and labels, 5 edge cases, 5 polish and talk-through. If an interviewer interrupts, the clock moves, but the order stays the same: something visible first.
Ask: how many rows? Fixed or live data? Who reads it, and on what screen? Does it need to be accessible? Write the answers as comments at the top of the file. This shows planning and takes two minutes.
02Bar chart, step 1: data, two scales, one rectangle per row
Five stations from station-month.csv, written inline, since typing a file is faster than loading one under a clock. A linear scale starts at 0 (so lengths stay proportional) and a band scale places the bars. The stage shows the first picture, after about ten minutes of an interview.
03Bar chart, step 2: axes, so the bars can be read
Add a bottom axis with short tick labels (d3.format("~s") turns 10000 into 10k) and a left axis with no tick lines. Say why: the band names are the labels, and the domain line adds nothing, so it is removed.
04Bar chart, step 3: sort and label directly
The data arrived in a random order. Sort a copy ([...data].sort(...)) so the caller's array is not changed, and write each value at the end of its bar. The reader now compares lengths and reads exact numbers without looking at the axis.
05Line chart, step 4: June as one path
The second task: June's daily rides as a line. Read daily.csv with d3.autoType (dates become UTC Date objects), keep June, and use a UTC time scale, a linear scale from zero and d3.line. Say which scale is which: dates on x, rides on y, with the y range flipped.
06Line chart, step 5: the tooltip
On pointermove, turn the pointer's x back into a date with x.invert, find the nearest day with a bisector, move a dot there and write the text. The bisector needs the data sorted by date: the code sorts it first and says why in a comment. The stage starts with 12 June already showing, so you see the tooltip without hovering.
Try it yourself
- 1
Sort the other way
In Round 1, change
b.rides - a.ridestoa.rides - b.rides. The bars flip: Windmill first. Neither is wrong, but "largest first" answers "who is busiest?", which is the usual question. Say that choice aloud. - 2
Make the tooltip follow a different rule
In Round 2, change
.centerto.left, and change the second pointer in the proof loop from0to520. For a pointer between two days,.leftreturns the next day, not the nearest, and a pointer right of the last day makes the index run past the end of the array. The Console then showsUncaught TypeError: Cannot read properties of undefined (reading 'date'), and the tooltip keeps showing the old text from 12 June, because the handler stopped before it wrote the new one..centernever does this: it returns the nearest day and stays inside the array. - 3
Draw a rainy week as a sparkline
In Round 3, replace
last30withall.slice(225, 232).map((d) => d.rides). That is 14 to 20 August, and the first day (14 August, 8.6 mm of rain) had only 439 rides, so the line starts at the bottom and jumps up. The console sayslast 30 days, drawn: 7 pointsand the words "Last 30 days of 2025" beside the line are now wrong, because they are typed by hand in the page: a label that is not built from the data goes stale. The sparkline's aria-label saysTrend over 7 days, from 439 to 3033, so the description follows the data.
Code & diagrams
This is the answer to give when the interviewer asks "what if the data is empty?" after the happy path works: four inputs, four sensible pictures, no NaN.
Preview
Console
Nothing logged yet.Expected console output
five stations: 5 bars, first width 367.1
empty array: 0 bars, first width -, says No data
one station: 1 bars, first width 358.4
all zero: 5 bars, first width 0.0Sending a synthetic pointer event is a good habit in an interview: it proves the handler works without waiting for a mouse. A pointer left of the plot clamps to the first day (the bisector never returns an index outside the array).
Preview
Console
Nothing logged yet.Expected console output
pointer at x=221: Thu 12 Jun: 3,987 rides
pointer at x=0: Sun 1 Jun: 3,166 rides
after leaving, tooltip display: noneA sparkline has no axes, so its honesty lives in the scale: here it spans the data's own minimum and maximum, which is fine for a trend and wrong for comparing two tiles (Topic 16.1).
Preview
Console
Nothing logged yet.Expected console output
last 30 days, drawn: 30 points
one point, drawn: 1 point, 0 line
no data, drawn: 0 points, label: No data
with a null: 2 points
flat data y: 3 points, clean: trueBreak it on purpose
Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.
Break #1
A negative value in the bar chart
In Round 1, change { name: "Windmill", rides: 10486 } to { name: "Windmill", rides: -500 }.
Break #2
Forget to sort for the bisector
In Round 2, add june.sort((a, b) => a.rides - b.rides); right after the line const nearest = ….
Myth vs fact
Myth
A live-coding round tests whether you remember the API by heart.
Fact
Interviewers usually let you look up syntax. They score your order of work, your scales, your handling of odd data and how you explain your choices. Typing speed matters little.
Myth
Silence while thinking looks confident.
Fact
Silence hides your reasoning. A short sentence ("I'm choosing a band scale because …") shows it, and gives the interviewer a chance to steer you before you lose ten minutes.
Myth
You should reach for a library to save time.
Fact
Ask first which library you may use. With D3 you still write the scales and marks yourself. If a charting library is allowed, say what it hides and when you would stop using it.
Pro corner
Extra depth for experienced readers. New to this? Skip it for now and come back later.
- ▸
If data loading is part of the task, show
response.okhandling and a loading and an error message within the first fifteen minutes. A chart without those states is not production code, and interviewers who build dashboards look for exactly that. - ▸
Two things impress almost every reviewer: a title or
aria-labelthat states what the chart shows, and a measurable check (such assvg.selectAll("rect").size()) logged to the console. They show you think about users and about proof. - ▸
When time runs out, stop adding features and spend the last five minutes on the talk-through: what you built, what you left out, what you would do with another hour (axes titles, responsive viewBox, a table twin, tests). A clear "next steps" list is part of a good result.
Remember this
- 1
The problem this solves: under a clock and an audience, people freeze, start with colours and fonts, and have nothing on screen after twenty minutes. A fixed order of work gives you something correct on screen in the first ten minutes, and everything after that is an improvement you can stop at any time.
- 2
The order: data, scales, marks, axes, then edge cases, then polish. Spend the first three minutes asking questions: how many rows, which columns, what the chart must say, what the user does with it. Next, shape the data (a small array). Then write the two scales. Then draw the marks, so something is visible. Then add axes and labels. Only now think about empty data, one row, zeros and negatives. Polish (colours, tooltips, transitions) comes last and only if there is time.
- 3
Talk in decisions, not in keystrokes. Not "now I write
.attr", but "I use a band scale for the stations because bars need a width, and a linear scale for rides starting at zero so the lengths stay honest". Say what you are unsure about: "I'll check the SVG's y direction when I draw, since it grows down." Interviewers prefer a candidate who notices a risk aloud to one who is silent and right. - 4
What interviewers check, in order. One: does it run, and does it show the right numbers? Two: are the scales and the join used correctly (a baseline at zero, a flipped y, a key)? Three: do you handle empty or odd data without being asked? Four: is the chart readable (labels, sorted bars, a title or a name for screen readers)? Five: can you explain every line and say what you would change with more time?
- 5
Keep every build small enough to finish. The three builds below are each 30 to 50 lines. Bar chart: sorted horizontal bars with direct labels. Line with tooltip: a time scale, one path and a bisector for the nearest day. Sparkline: a line with no axes for a KPI tile (Topic 16.1). If you get stuck, say what you would try next and move on; a visible partial result beats a perfect plan.
- 6
Recover out loud when something breaks. A blank chart or a console error is normal, and the interview is often about the next minute. Name the symptom, form a guess, test one thing (log the value, inspect the element), and say what you found. Topic 18.4 gives the full method. Interviewers remember a calm debug far better than code that never broke.
Explain it without notes
How do you split the first ten minutes of a live-coding chart round, and why in that order?
In the line chart with a tooltip, why do you need the data sorted, and what happens when it is not?
What edge cases do you handle in a bar chart without being asked?
What do you say out loud while coding?
Practice
Build, in under ten minutes, a horizontal bar chart of the three busiest stations from this inline data, sorted, with the values written at the ends of the bars: Quay 58584, Lantern 58090, Library 55536. Use d3.scaleLinear from 0 and d3.scaleBand.
Write nearestDay(days, date) that returns the day closest to a date, given an array of { date, rides } sorted by date, and returns undefined for an empty array. Test it with three dates, one before the first day.
Sketch, in words, what you would say in the first three minutes of the line-with-tooltip round: five questions you would ask the interviewer.
Trade-offs
- ↔
Writing inline data is fast under a clock but says nothing about loading and error states; fetching a file shows more skill but costs minutes. Ask which the interviewer wants.
- ↔
Polish earns points, but a correct chart with its edge cases handled beats a pretty one that shows NaN when the data is empty. Finish correctness first.
Done when you can
I can describe the order of work: questions, data, scales, marks, axes, edge cases, polish.
I can build a sorted, labelled bar chart in about ten minutes and say why each scale is what it is.
I can build a line with a bisector tooltip and explain why the data must be sorted.
I can draw a sparkline that survives empty, one-point, flat and null data.
I can narrate decisions out loud, and recover calmly from a console error.