React Live Coding Interview: Build a Travel Cost Calculator

THE CONCEPTS

The mental models, one by one

1. 01

   Ask Questions Before You Type

   Bogdan did not open the editor first. He walked the mockup and asked: does the starting point need validation? Do the vehicle options come from the API? Should the total refetch every time a destination changes? Is submit in scope?

   Each answer cut scope: no validation, mock the API, refetch on every change, submit is out. Five minutes of questions is cheaper than twenty minutes of building the wrong thing. Interviewers score the questions too.

   requirementsinterview technique
2. 02

   Sketch the State Before the Components

   Before code: a quick sketch of the component structure and the state. A starting point string. A destination array. The vehicle type options. The expense name. The total amount.

   Destinations are an array of objects, not strings — each needs a unique id, because React needs a stable key when rendering lists and you will add and remove entries. Modeling the shape up front saves the mid-interview scramble.

   Reactstate designdata modeling
3. 03

   Essential State vs Derived State

   Essential state changes independently — you cannot compute it from other state. Derived state is calculated from other variables. Example from real work: in a checkout cart, the items are essential; the total and the tax are derived.

   Here the total amount looks derived — but it is computed on the backend, not the client, so on the client it is essential state that arrives over the network. Getting this classification right decides how much state you store and how many bugs you avoid.

   derived stateReactstate management
4. 04

   Brute Force the Markup, Then Add Behavior

   The build order: write the whole static JSX first — labels, inputs, the select with hardcoded options, the button, the total — with no components and no CSS. Then wire state in.

   This is deliberate. Splitting into components while the requirements are still moving wastes interview time. Get the skeleton on screen, confirm it matches the mockup, then make it dynamic. Small accessibility touches for free: htmlFor on labels, names on inputs.

   Detail that saves you a bug: give the button an explicit type of button. If the markup ever gets wrapped in a form, a default submit type triggers weird behavior.

   JSXHTMLaccessibility
5. 05

   Controlled Inputs: value Plus onChange

   Every input gets binded to state: value from the state variable, an onChange handler that calls the setter with event.target.value. That is a controlled component — the standard React pattern for forms.

   Bogdan chose independent controlled fields over a single HTML form element. With separate fields, reading and validating values on submit is slightly easier than digging them out of the form target. Then verify in the browser with React DevTools: type, watch the state update. Always debug with the debugger, not with hope.

   controlled componentsformsReact
6. 06

   The Dynamic Destination List: map, Keys, and IDs

   The destinations render with a map over the list. Each row needs a key — that is why every destination carries an id. For the interview, Math.random stringified is good enough for ids, with the disclaimer said out loud: never in production.

   In production: a UUID, or create the record on the backend so the id is consistent with what the server has. Adding a destination is a state transition — spread the old list, append a new object with a fresh id and an empty value.

   Declare the TypeScript interface for the destination early. Type inference then flows through the map and the handlers and makes everything easier.

   React keysUUIDTypeScriptlists
7. 07

   Updating One Item in a List Without Mutating

   Changing one destination's value means: find its index by id, build a new destination object, copy the list, replace the item at that index, set the new list. Never mutate the existing array — React state updates must be immutable.

   Bogdan flagged the trade-off himself: this array search is inefficient. A hash map keyed by id makes updates cheaper but rendering clumsier, because you iterate object keys. For a form this size the array wins; knowing the alternative is what the interviewer is listening for.

   immutabilitystate updatesdata structures
8. 08

   Mocking API Calls with the Promise Constructor

   No real backend in the interview, so the fetches are faked properly: an async function that returns a new Promise resolving with the data. That mimics real network behavior instead of just returning a value — the component code stays identical to production.

   Two mocks: getVehicleTypes resolving with value-label pairs, and calculateTotalAmount resolving with a number. Each option keeps a separate value and label — labels are for humans and get translated, values stay universal.

   Promiseasync/awaitAPI mocking
9. 09

   useEffect for Fetching — and Why Fewer Effects Is Better

   The vehicle types load in a useEffect on mount. The expense name recomputes in an effect when the starting point or destinations change. The total amount refetches in a third effect. It works. It is also the part to improve.

   The interviewer asked the drawback directly: effects run after render and then trigger another render, so every effect is extra re-renders. The fix is to move state transitions into the event handlers that caused them — set the expense name inside onChange, not in an effect watching the inputs.

   For the data fetching, useQuery replaces the effect entirely and gives you loading and error state for free, like a real network client should. This component can be written with zero effects. Saying that unprompted is a senior signal.

   useEffectuseQueryre-rendersReact
10. 10

    The Follow-Up Questions: Testing and Styling

    How would you test this? First extract components — everything in one file is untestable. Unit test each field component that carries logic, then an end-to-end test of the whole form with Cypress. For the API integration, mock the calls with Cypress fixtures.

    Styling: CSS-in-JS via styled-components, because scoping styles to components and driving styles from JavaScript values — say, coloring a field on validation state — is easy. Plain CSS works too once styles are scoped to components.

    Also asked: why Vite over webpack? Vite is faster and easier to set up, and that is where the ecosystem has moved. Short answer, no essay.

    CypresstestingCSS-in-JSVite
11. 11

    Why Live Coding Is the Skill of 2025: Take-Home Inflation

    AI broke the take-home task. With GPT and Cursor, backend devs submit decent frontend tasks and vice versa. Where a company used to get three submissions, they now get twenty. The signal is gone.

    Take-homes are high effort, low value. Companies say two hours; delivering something that actually advances you takes closer to twenty — deployment, tests, a README. Then a reviewer spends a minute on it and rejects on a whim. The commitment is asymmetric and the candidate is the losing side.

    And you will live code anyway: pass the take-home and the next stage is extend this code live. If AI wrote it and you cannot explain it, you are in trouble. The few developers who can actually live code stand out automatically — and the feedback loop is days faster. You can do ten live interviews in the week one take-home consumes.

    take-home tasksAI toolsinterview strategy
12. 12

    Why Developers Go Blank: Four Real Reasons

    The same four patterns show up in every developer who freezes in a live coding interview:

    1. The LeetCode disillusion. Grinding LeetCode for months burns you out, and the interview problem is one you never touched anyway. It is one of the most inefficient ways to get good at live coding.
    2. Tooling dependency. Interview editors often have no autocomplete, no AI, no Google. If you have never coded from the top of your head, that is a new world — and it says nothing about your ability.
    3. Framework abstractions. You never write a for loop because you use map and reduce; you never construct a Promise because fetch hands you one. When the abstraction is gone, it feels like you know nothing. It is just unpracticed territory.
    4. Past trauma. One brutal interview and people refuse the next one, even from a dream company. The elitism in tech amplifies it. The result: developers who can code but cannot program. That is fixable.

    LeetCodefundamentalsinterview psychology
13. 13

    The Fix: Make Fundamentals Second Nature

    The exercise: open a plain notepad and write a program that sums an array with a for loop. No IDE, no autocomplete, no framework. Code is just text that a compiler interprets — going to that extreme strips the dependency and shows you the fundamentals were always simple.

    Then think in first principles: every time you write a map or a reduce, ask how you would write it with a for loop, with a while loop, and recursively. Those three questions cover almost everything that matters about that piece of code.

    Complexity is only an aggregate of simplicity. Every problem in isolation is small; interviews feel hard because the small things arrive together. Master each atom — loops, recursion, basic iteration — and the higher level gets fast on its own.

    fundamentalsfor loopsrecursionfirst principles
14. 14

    Pick Your Battles, Learn Patterns, Know Your Keyboard

    Do not train dynamic programming unless you are interviewing at Google — and even there, only a small fraction of interviews contain it. Ninety-nine percent of companies will never ask it. Get fully confident at iteration first — confident meaning you can write it in a plain text document — then two pointers and sliding window, then graphs if you ever actually need them.

    Focus on patterns, not problems. Solving one company's exact question teaches you nothing transferable. After every problem, name the pattern you used and apply it to three or five more until it is part of your mental toolset.

    Bonus: touch typing. In the red zone of an interview, every mechanical mistake compounds toward paralysis. Fifteen to thirty minutes of typing practice a day removes a whole class of failure. Fundamentals plus typing plus patterns adds up to a performance that surprises even you.

    algorithm patternstouch typinginterview prep