One post tagged with "react-challenges"

Machine coding rounds are where theory meets reality. You are not asked to explain hooks in abstract terms — you are asked to build a working UI in 60–90 minutes, make reasonable trade-offs under pressure, and communicate your thinking out loud.

This post is a curated guide based on a personal collection of React challenges I have practiced over the years - from Todo list starter problems to company-style components like transfer lists, autocomplete, shopping carts, and async UI testing. Use it as a roadmap: understand the problem statement, know what signals interviewers look for, and practice until the patterns feel natural.

---

What is a React machine coding round?​

In most frontend interviews (especially at product companies and startups), a machine coding round evaluates:

1. Can you translate requirements into component structure?
2. Can you manage state correctly without over-engineering?
3. Do you write readable, maintainable React — not just "it works"?
4. Do you handle edge cases (empty states, disabled buttons, invalid moves, loading/error)?
5. Can you test or at least design for testability?

Unlike LeetCode, there is rarely one optimal algorithm. Interviewers care about product thinking + React fundamentals + execution speed.

---

The skill ladder (how to use this list)​

Level	Focus	Typical time
Warm-up	useState, events, rendering lists	15–25 min
Core UI	Forms, controlled inputs, sorting/filtering	30–45 min
State design	Context, reducer, lifting state	45–60 min
Product components	Transfer list, autocomplete, cart logic	60–90 min
Quality bar	Async fetch, error/loading, RTL/Jest tests	60–90 min

Practice in this order. If you cannot build a counter confidently, a shopping cart will feel overwhelming.

---

Challenge catalog​

Below is a challenge-by-challenge breakdown: problem statement, what interviewers expect, and concepts tested.

---

1. Simple Counter​

Problem statement: Build a counter with an increment button. Display the current count and update it on click.

What interviewers expect:

• Correct useState usage with functional updates when needed: setCount(prev => prev + 1).
• Stable element ids/classes if tests rely on them (#mainButton, count span).
• No stale closure bugs when logic grows (e.g., adding decrement/reset later).

Signals tested: Basic React rendering, event handling, state updates.

Stretch goals: Decrement, reset, min/max bounds, keyboard accessibility.

---

2. Button Toggle (ON/OFF)​

Problem statement: Render a button that toggles label/state between ON and OFF on each click.

What interviewers expect:

• Boolean state (useState(false)).
• Derived UI from state (label reflects state, not duplicated state).
• Clean handler: setToggle(prev => !prev).

Signals tested: Minimal state, controlled UI, readability.

---

3. Static List Rendering​

Problem statement: Given an array like [{ name, age }, ...], render a list of items.

What interviewers expect:

• map() with a stable key (prefer id; index only if static).
• Small presentational components (DataItem, DataList).
• Separation of data and view.

Signals tested: Lists/keys, component composition.

---

4. Context API - Language Toggle​

Problem statement: Provide shared language state via Context. Display current language and a button to cycle/toggle between options (e.g., JavaScript ↔ Python).

What interviewers expect:

• createContext + Provider wrapping subtree.
• Consumer reads context with useContext.
• Avoid prop drilling; keep provider value memoized if object identity matters.

Signals tested: Context pattern, shared state across components.

Common mistakes: Creating context value inline every render causing unnecessary re-renders; putting everything in context too early.

---

5. Phone Book (Form + Table + Sort)​

Problem statement: Build a form to add users (first name, last name, phone). On submit, append to a table sorted by last name.

What interviewers expect:

• Controlled inputs (value + onChange).
• Form submit handling (preventDefault).
• Immutable state updates (setEntries(prev => [...prev, newEntry])).
• Sorting logic (case-insensitive last name compare).
• Reset form after successful submit.

Signals tested: Forms, derived sorted data, useReducer (optional but strong signal).

Bonus: Validation (required fields, phone format), duplicate detection, edit/delete.

---

6. Todo List (Basic)​

Problem statement: Render todos with checkbox to mark complete/incomplete. Toggle completion state on click.

What interviewers expect:

• Immutable updates in reducer or state setter.
• Checkbox checked bound to todo state.
• Clear visual distinction for completed items.

Signals tested: useReducer, list updates, controlled inputs.

---

7. Todo App with Context + Reducer​

Problem statement: Extend todos with add + mark-complete actions shared across form/list components using Context.

What interviewers expect:

• Reducer actions (ADD, COMPLETE) with pure state transitions.
• Context exposes actions, not raw dispatch, when possible (addItem, markAsCompleted).
• Provider wraps app subtree; consumers stay thin.

Signals tested: Scalable state architecture without Redux.

---

8. Toggle State with Context + Reducer​

Problem statement: Manage toggleable app state (e.g., language/theme) using useReducer and Context together.

What interviewers expect:

• Reducer stays pure; side effects stay outside.
• Context API design: { state, toggleLanguage } instead of leaking implementation details.
• Predictable action types (TOGGLE).

Signals tested: Intermediate state management patterns commonly used in real codebases.

---

9. Tic Tac Toe​

Problem statement: Build a 3×3 grid. Two players alternate (X/O). Detect win/draw, prevent invalid moves, optionally support reset.

What interviewers expect:

• Single source of truth for board state (array or map keyed by cell).
• Win detection for rows/columns/diagonals.
• Disable cells after game ends or if already filled.
• Turn indicator and winner display.

Signals tested: Derived state, effects (useEffect) used carefully, edge-case handling.

Stretch: N×N board generalization (see extended grid challenge).

Interview tip: Start with board representation before UI. Most bugs come from duplicated state (currentPlayer vs board-derived turn).

---

10. Star Rating Component​

Problem statement: Render 5 stars. Hover highlights up to hovered star; click sets rating; show current rating.

What interviewers expect:

• Hover vs selected state separated (hoverIndex vs rating).
• Mouse enter/leave handlers that restore selected rating on leave.
• Accessible controls (radio group pattern or buttons with aria-label).

Signals tested: UI interaction state, event handling, component decomposition (Star child).

---

11. Directory Tree (Recursive UI)​

Problem statement: Given nested folder/file data, render expandable tree. Click folder to expand/collapse children.

What interviewers expect:

• Recursive rendering (RenderTree, ExpandedTree).
• Local expand/collapse state per folder node.
• Correct handling of children: null vs empty array.

Signals tested: Recursion in React, conditional rendering, tree data modeling.

---

12. Transfer List (High-frequency interview question)​

Problem statement: Build two lists with controls to move items left/right. Support selecting one or many items via checkbox and transfer selected items between lists.

What interviewers expect:

• Separate list state (leftItems, rightItems).
• Selection state (checkbox per item or Set of selected ids).
• Disabled action buttons when nothing selected / list empty.
• Preserve order or define sort behavior explicitly.

Signals tested: Complex state coordination, UX details, immutable array operations.

What great candidates mention aloud:

• Should moved items keep selection?
• Should we support reorder within a list?
• Should "move all" exist?

This challenge appears frequently because it mirrors real admin UIs (permissions, bucket assignment, playlist management).

---

13. Transfer List - Advanced Variant​

Problem statement (extended): Add reorder (Move Up / Move Down) and multi-select transfer between two lists.

What interviewers expect:

• Set-based selection for multi-select.
• Reorder only selected contiguous groups or single items - clarify behavior.
• Button disabled logic when selection is at boundary (top/bottom).
• No mutation of state arrays in place.

Signals tested: Higher complexity state transitions, the kind asked at mid-senior frontend loops.

---

14. Autocomplete - Offline​

Problem statement: Input filters a local suggestions list as user types (countries, tags, etc.).

What interviewers expect:

• Controlled input.
• Case-insensitive filtering (includes / startsWith / regex - justify choice).
• Debounced filtering for performance on large lists.
• Empty state when no matches.

Signals tested: Controlled components, debouncing, list filtering.

---

15. Autocomplete - Online (API-backed)​

Problem statement: Fetch suggestions from API (e.g., GitHub users) based on search term.

What interviewers expect:

• Debounced API calls (avoid request storm on every keystroke).
• Loading and error states.
• Cancel stale requests or ignore outdated responses (AbortController or mounted flag).
• Render API response shape safely (items?.map).

Signals tested: Async React patterns, network UX, race condition awareness.

---

16. Dynamic Forms (Add More Fields)​

Problem statement: Render one or more form blocks. Clicking "Add More" appends another form dynamically.

What interviewers expect:

• Dynamic list of form entities in state (forms: [{ id }]).
• Stable keys per form instance.
• Context/reducer or state lift to add/remove forms.
• Each form maintains its own local input state.

Signals tested: Dynamic UI generation, context/reducer design, component boundaries.

Common pitfall: Reusing index as key after insert/delete causes input state to jump between forms.

---

17. Shopping Cart + Coupon Strategies​

Problem statement: Add products to cart, apply coupons (percentage/fixed), compute net price.

What interviewers expect:

• Extensible discount logic (strategy pattern or pure functions).
• Derived totals (calculateTotalPrice, calculateNetPrice) instead of storing redundant values.
• Context or reducer for cart state.
• Clear separation: product model vs discount rules vs UI.

Signals tested: Domain modeling in UI, design patterns, derived state.

What interviewers love hearing: "Total is derived; we don't store net price as source of truth."

---

18. Redux Toolkit Counter (Optional round variant)​

Problem statement: Implement counter (or small feature) using Redux Toolkit slice.

What interviewers expect:

• Slice with reducers/actions.
• Store provider at app root.
• Component dispatches actions, selects state via hooks.

Signals tested: Global state familiarity - more common in enterprise teams than startups.

Use this if the JD mentions Redux/Zustand; otherwise Context + reducer is usually enough.

---

19. Async Posts List + Tests (RTL/Jest)​

Problem statement: Fetch posts on mount, show loading, render list, support filter action, handle API failure gracefully.

What interviewers expect:

• useEffect with cleanup (mounted flag or abort).
• Loading/error/success UI branches.
• Tests with React Testing Library:
  • loading state visible initially
  • list renders after fetch resolves
  • filter reduces items
  • rejected promise shows error UI
• Mock fetch in tests (jest.fn, mockRejectedValueOnce).

Signals tested: Async UI lifecycle, testability, production-minded error handling.

This is increasingly common: "make it work" + "prove it works."

---

Cross-cutting expectations in every round​

No matter which challenge you get, interviewers usually score these:

Component design​

• Smart vs presentational split when complexity grows.
• Avoid "god components" beyond ~150 lines.
• Reusable primitives (Button, List, Cell) when repeated.

State management choices​

• Local state first.
• Lift state when siblings need it.
• Context/reducer when prop drilling hurts.
• Redux only when requirements explicitly need global/shared cross-route state.

React correctness​

• Never mutate state directly.
• Keys on lists.
• Effects with correct dependency arrays.
• Avoid unnecessary effects (derive values in render when possible).

UX details that impress​

• Disabled buttons when action invalid.
• Empty states ("No items in List 2").
• Keyboard support for interactive widgets.
• Clear feedback on win/loss/error/loading.

Communication​

• Think aloud: "I'll represent board as a map keyed by cell id."
• Call out trade-offs: "Debouncing at 300ms balances responsiveness and API cost."
• State assumptions explicitly when requirements are ambiguous.

---

A practical 90-minute game plan​

Use this template in real interviews:

1. 0–10 min: Clarify requirements + write acceptance checks.
2. 10–35 min: Build MVP (render + core interaction).
3. 35–60 min: Edge cases + polish (disabled states, empty/error).
4. 60–75 min: Refactor names/structure, extract components.
5. 75–90 min: Tests or self-review checklist.

Acceptance checklist example (Transfer List):

• Can select multiple items
• Can move selected right/left
• Selection clears after move (if required)
• Buttons disabled appropriately
• No item duplication/loss

---

Recommended practice order​

If you are early in your frontend journey, practice in this sequence:

1. Counter → Toggle → List
2. Phone Book → Todo (basic)
3. Context Toggle → Todo with Context/Reducer
4. Star Rating → Directory Tree
5. Tic Tac Toe
6. Autocomplete (offline → online)
7. Transfer List (basic → advanced reorder variant)
8. Dynamic Forms
9. Shopping Cart
10. Async list + RTL tests

Each step adds one new concept without jumping complexity too fast.

---

Final advice for young engineers​

Machine coding rounds can feel intimidating, but they are also the most fair part of many interview loops: your screen shows what you can actually build.

You do not need fancy abstractions. You need:

• calm requirement clarification,
• steady MVP delivery,
• correct React state habits,
• and clear communication.

Pick one challenge from this list, timebox 60 minutes, build it, then rewrite it cleaner the next day. Repeat weekly - that compounding practice is what turns anxiety into confidence.

---

References & further practice​

If you want hands-on walkthroughs of these challenges inside JavaScript360, check the React Challenges section.

Happy building - and remember: interviewers are not looking for perfect code. They are looking for clear thinking, working software, and good React instincts under time pressure.