Practice interview-style frontend machine coding rounds by building and studying reusable React components.
This repository is designed for two outcomes:
- Learn core frontend problem solving through guided mini-projects.
- Build production-leaning, reusable components that hold up in interviews.
- Beginners who want structure, not random tutorials.
- Developers preparing for frontend machine coding interviews.
- Engineers who want to practice API design and reusable component thinking.
- Node.js 20+
- npm 10+
npm install
npm run devOpen http://localhost:3000 and then go to http://localhost:3000/<your-challenge>.
For each challenge:
- Read the problem statement first (when available in
.mdinside the challenge folder). - Try implementing it yourself before reading the existing code.
- Compare your approach with the current implementation.
- Refactor it into a reusable component API (props, callbacks, sensible defaults).
- Note tradeoffs: accessibility, performance, edge cases, testing strategy.
Use the reusable component checklist in docs/REUSABLE_COMPONENT_PLAYBOOK.md.
All challenge routes live under /<challenge-name>.
| Challenge | Route | Interview Focus |
|---|---|---|
| Accordion | /accordion |
Controlled state, keyboard interactions |
| Chips Input | /chips-input |
Input parsing, keyboard UX |
| Controlled Dropdown Button | /controlled-dropdown-button |
Controlled components, event handling |
| File Explorer | /file-explorer |
Recursive rendering, tree state |
| Generic Dialog | /generic-dialog |
Portals, focus management, composability |
| Grid Row Sortable Filterable | /grid-row-sortable-filterable |
Data transforms, sort/filter architecture |
| Images Carousel | /images-carousel |
Navigation state, transitions |
| Images Pagination | /images-pagination |
API fetching, pagination patterns |
| Infinite Scroll | /infinite-scroll |
Progressive loading, viewport handling |
| Interactive Shape | /interactive-shape |
SVG/canvas-style interaction modeling |
| Markdown Preview | /markdown-preview |
Parsing pipeline, editor-preview sync |
| Notification Toast | /notification-toast |
Queueing, timers, transient UI |
| OTP Input | /otp-input |
Input orchestration, focus chaining |
| Pro Todo App | /pro-todo-app |
Global state design, predictable updates |
| Progress Bar | /progress-bar |
Timed state updates, visual feedback |
| Search Ahead | /search-ahead |
Query handling, async UX |
| Snake Game | /snake-game |
Game loop, grid simulation |
| Star Rating | /star-rating |
Interactive rating primitives |
| Stopwatch | /stopwatch |
Timers, control flow |
| Tab Form | /tab-form |
Multi-step forms, state partitioning |
| Tic Tac Toe | /tic-tac-toe |
Grid logic, winner detection |
| Virtualized List Performance | /virtualized-list-performance |
Rendering performance, virtualization |
src/
app/
page.tsx # Challenge links
<challenge>/
page.tsx # Route entry for the challenge
<ChallengeComponent>.tsx # Main implementation
*.css / data / notes # Optional support files
A good solution in this repo should:
- Expose a clean API with typed props.
- Avoid hardcoding behavior that should be configurable.
- Separate business logic from presentational details where practical.
- Handle edge cases and communicate state clearly.
- Be extendable (theming, data source swap, accessibility improvements).
Read docs/REUSABLE_COMPONENT_PLAYBOOK.md for the full rubric.
Use these docs before opening a PR:
At minimum, each new challenge should include:
- A clear problem statement.
- A reusable component API expectation.
- Edge cases and evaluation criteria.
- A working route under
/<slug>.
npm run dev
npm run build
npm run start
npm run lint
npm run test
npm run test:watch
npm run test:coverageTests are powered by Vitest + React Testing Library.
- Component tests:
src/test/components - State/reducer tests:
src/test/state
Run all tests:
npm run testRun with coverage report:
npm run test:coverageStart with: accordion, star-rating, stopwatch, progress-bar, then move to file-explorer, search-ahead, and virtualized-list-performance.
No. The goal is both interview fluency and real component engineering habits.
Those are challenge specs. Treat them like interviewer prompts: requirements, constraints, edge cases, and evaluation criteria.