Victor Jeman Academy
Technical interviews6 min

Live coding example

A live coding brief I hand candidates, plus the small habits that decide who passes.

Task overview

You are given a small React project with a minimal setup:

  • React and React DOM already configured
  • A simple <App /> component where you can add your code
  • A working API mock function fetchUsers() that returns a list of users after a short delay

Your goal is to build a User List component that fetches and displays user data with proper states.

Requirements

  1. Fetch Data

    • Use the provided fetchUsers() function to load data.
    • The function returns a promise that resolves to an array of user objects with { id, name, email }.
  2. Display Users

    • Render the list of users in a simple table or list.
    • Show name and email for each user.
  3. Handle States

    • Show a loading indicator while data is being fetched.
    • Show an error message if the API call fails.
    • Show an empty state if the API returns no users.
  4. Add Interaction

    • Provide a simple text input that filters users by name in real time.

Use of libraries

You may install external libraries if they help you solve the problem faster or clearer. The rule of thumb:

  • Say what the library does and why you reached for it.
  • Show briefly how you would do the same thing without it, so the interviewer can see you understand the underlying problem.

For example:

  • Using a library like axios for data fetching is acceptable, but you should mention that fetch() is already available natively and demonstrate how it would work.
  • Using a library like classnames is fine, but be clear that conditional class handling can also be done manually with string concatenation.

The interviewer wants to see judgment, not a yarn lockfile.

I've watched a candidate lose the room by reaching for lodash before writing a single loop. The hire next to them used Array.prototype.filter, said "I'd swap this for lodash.debounce if the input got chatty", and moved on. Same problem, very different signal.

Expectations

  • The component should be small, focused, and easy to follow.
  • Styling can be minimal; clarity and structure are more important than polish.
  • Write code in small, working increments and narrate your reasoning as you go.
  • If you run out of time, a partial but structured solution with clear communication is better than rushing.

If I'm the interviewer, the partial-but-clear solution wins every time (and yes, I do remember which candidate told me what they would have done with another ten minutes).

Next lesson, we walk through how to narrate your way through this exact task, the same way I'd want to hear it from the other side of the call.