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
-
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 }.
- Use the provided
-
Display Users
- Render the list of users in a simple table or list.
- Show
nameandemailfor each user.
-
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.
-
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
axiosfor data fetching is acceptable, but you should mention thatfetch()is already available natively and demonstrate how it would work. - Using a library like
classnamesis 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.

