I'll be honest. I have read a few dozen of these take-homes over the years, and last year I handed out this exact assignment to four candidates. The strongest one did not finish every bonus. They shipped the core, wrote a README I could actually follow, and left a note about what they would do on day two.

That is the whole game. Below is the spec I sent them, almost verbatim.

Logistics

• Time: 8 hours (Working day)
• Tech Stack: React (you may use additional libraries if justified)
• Submission: GitHub repository with README, optional short demo video

Task description

Build a small but realistic front-end feature inside a tight time budget. That is what we are checking.

Build a Movies Explorer application using the OMDb API (requires a free API key) or a similar open API of your choice.
The application should allow users to:

• Search for movies by title (API query).
• Display results with poster, title, year, and type (movie/series).
• Add a filter bar that allows the user to:
  • Filter by type (movie, series, episode).
  • Sort results by year (ascending/descending).
• Implement pagination to navigate through multiple result pages.
• Handle loading, error, and empty states when fetching data. Empty state matters more than you think. The first thing I click as a reviewer is the search bar with no query, within ten seconds of opening the app.
• Add a detail view: clicking on a movie should open a page/modal showing its description, genre, and rating (fetched from the API).

(Yes, you can use TanStack Query, SWR, or plain useEffect. Tell me why in the README. I have hired people who used useEffect and rejected people who reached for Redux Toolkit Query on a 200-line app.)

Important details

• The UI should be functional and easy to understand.
• Styling can be minimal. Code clarity and structure matter more.
• You may use external libraries, but you must:
  • Explain what the library does.
  • Show (briefly) how the same could be done without it.
• Commit regularly to Git. I do read the commit history. A single "final commit" with 47 files changed tells me something I do not want to know.

Required deliverables

• A Git repository with your project code.
• A README file that explains:
  • How to run the project.
  • How to test the features.
  • What trade-offs or assumptions you made.
• A short demo video to showcase the app in action.

The most common reason a take-home gets rejected on my desk is a README that does not say how to run the project. I am not joking. Half the rejects never make it past pnpm install.

Bonuses (optional)

If you have extra time, pick one or two. Mention in the README what you did and why.

1. Additional Filters: Add filtering by year range or genre.

2. Improved UX: Implement infinite scrolling instead, and allow switching between infinite scroll and classic pagination.

3. Persistence: Store search queries, filters, and pagination in the URL query params so they survive refresh.

4. Testing: Add a few simple unit tests for your filtering logic or API layer.

5. Performance: Cache API results to avoid unnecessary re-fetching when navigating back and forth.

If I had to pick one, it would be #3. URL persistence tells me you thought about the user coming back tomorrow with a bookmarked link. (Testing is the second one I care about, but only if the tests are real, not a snapshot of the empty state.)

Tomorrow morning, before you write a single line of code, open a blank README and type the three sentences you want me to read first. Then build the thing that makes those sentences true.

Next lesson walks through what a reviewer actually looks at when your repo lands in their inbox. That is the other side of this same exercise, and it will change how you scope your 8 hours.