Skip to content
Take-home ยท 240 minutes

Projects and todos from a design file

You get a design file for a small 'projects and todos' app, and four hours. Build it in React with TypeScript. The app has a list of projects, and each project has tasks. The user can add, edit, complete and delete tasks, and filter them by status. The data is saved in localStorage, so a reload keeps it. The layout must match the design on desktop and on a phone, and the app must work with a keyboard and a screen reader. Send a repository with a README. Reviewers score working features, code quality and closeness to the design, not extra features. For this rehearsal, choose a free todo app design from a design community before you start the clock, and treat it as the specification.

Requirements

  • Projects: create, rename and delete a project; select a project to see its tasks
  • Tasks: add, edit the title, mark as complete and delete; each task belongs to one project
  • Filters: all, active and completed, with a count of active tasks
  • State is saved in localStorage and restored on load; missing or broken stored data does not crash the app
  • Responsive: the layout matches the design at desktop width and at 390 px, with no sideways scroll
  • Accessible: every action works with the keyboard, every input has a label, and focus is always visible
  • Spacing, colors and text styles use the values from the design file
  • The repository has a README, tests for the main behavior and a clean commit history

What reviewers look for

  • It works: no broken flow, no console errors, and the data survives a reload
  • Closeness to the design: spacing, text styles, colors, and the hover, focus and empty states
  • Component structure and state: small components, one source of truth, no duplicated state
  • TypeScript used well: typed models, no any, no type assertions that hide errors
  • Accessibility basics: semantic elements, labels, keyboard use, and a logical focus position after add and delete
  • Judgment under a time limit: a well-chosen scope, with the trade-offs written in the README
  • Tests that check what a user sees and does, not implementation details

Check before you hand it in

  • Tasks can be added, edited, completed, deleted and filtered, and projects can be created, renamed and deleted, with no console errors
  • After a reload, the projects, the tasks and their completed state are still there
  • I put my screens next to the design at desktop width and at 390 px, and fixed the differences I found
  • I did every action with the keyboard only; focus was always visible and went to a logical place after add and delete
  • The README says how to run the app and explains my decisions, what I left out, and what I would do with more time
  • Tests cover the main behavior: adding a task, completing it, filtering, and loading saved data
  • The history has small commits, and each message says what changed and why
  • I stopped when the four hours ended, and the app was in a state I could send

If there is time

  • Drag and drop to reorder tasks, with a keyboard alternative
  • Undo after delete, offered in a short message
  • A dark theme built from the same design tokens
  • Deploy the app and put the link in the README