You're asked to build the backend for the "More Like This" section on a movie's details page. Given a movie, return other movies a viewer is likely to enjoy, ranked by how much they have in common with it: shared genres, shared cast, and the same director. The application already exists. It's a Django and React project with a seeded catalog of around ninety movies, working authentication, and a details page whose "More Like This" section is already built and waiting for an endpoint that returns nothing yet. Adapted from a full-stack take-home of the kind HackerRank hosts for product engineering roles. ## What's in the codebase - **`backend/apps/movies/`.** The `Movie` model, its serializer, the URL table, and the views for listing, searching, and fetching a movie by ID. Your endpoint goes here. - **`backend/apps/core/data/movies.py`.** The seed catalog, with genres, cast, director, year, rating, and popularity on every record. - **`backend/apps/core/management/commands/seed.py`.** Loads the catalog. `bun run reset` returns the database to a known state. - **`backend/tests/test_similar_movies.py`.** The test suite for the endpoint you're adding. It builds movies with known overlap profiles so each scoring signal can be checked in isolation. - **`frontend/src/components/SimilarMovies.jsx`.** The component that will call your endpoint. - **`setup.sh`.** Installs dependencies, migrates, and seeds. `bun run setup` runs it. The existing views in `apps/movies/views.py` show the house pattern for error handling, serialization, and query parameter parsing. Follow it rather than inventing your own. ## Your task Add `GET /api/movies//similar`, a public endpoint that returns movies similar to the given one, ranked by score. The score is the sum of three weighted signals, each of which produces a value between 0 and 1: | Signal | How it's calculated | Weight | | --- | --- | --- | | Genre | Genres the two movies share, divided by all distinct genres across both | 0.5 | | Cast | Cast members they share, divided by the number of cast members in the given movie | 0.3 | | Director | 1 if the directors match, otherwise 0 | 0.2 | Ties break on `rating`, then `popularity`, then `year`, each highest first. An optional `limit` parameter defaults to 6, has to be at least 1, and is capped at 50. A malformed ID returns 400, a valid ID that doesn't exist returns 404, and a movie with no overlap anywhere in the catalog returns an empty list with a 200. ## What to focus on - **Reading the spec as a contract.** The two denominators are different on purpose: genre divides by the union, cast divides by the given movie's cast size. Getting that backwards produces plausible rankings that fail the tests. - **Matching the codebase you landed in.** The error shapes, the serializer, and the way limits get parsed are already established in the neighboring views. An endpoint that returns its own error format is a correctness problem, not a style one. - **Scoring against a catalog rather than a pair.** You're comparing one movie against every other movie. Ninety records will not punish a careless implementation, and the interviewer will ask what happens at a hundred thousand. ## The scale follow-up Expect to be asked what changes when the catalog is large. Scoring every movie against every other on each request is the obvious first target, and the honest answer involves precomputation, inverted indexes from genre and cast to movie, or a nightly job that materializes the top N per movie. Be specific about what each option costs. A precomputed table is fast to read and stale the moment the catalog changes, and saying so is worth more than naming the technique. ## Using AI on this problem The repository is large enough that comprehension is the most useful thing to delegate. Ask where movies are serialized, how the existing views report errors, and which file registers routes, and have the agent quote the function names so you can check each answer against the code. Be careful about letting it write the scoring function from the spec. Models tend to normalize both signals the same way, which is exactly the mistake the tests are built to catch. Read the denominators yourself. ## Leveling signals | | | | --- | --- | | Mid-level | Implements the endpoint with correct scoring and the documented error cases. Follows the existing view patterns once pointed at them. Handles the tie-break rules with some prompting. | | Senior | Reads the spec carefully enough to get both denominators and the full tie-break chain right the first time. Matches the codebase's conventions without being told. Raises the per-request scoring cost before being asked. | | Staff+ | Treats the endpoint as a recommendation surface rather than a formula: names the staleness tradeoff in precomputation, notes that a content-based score has a cold-start advantage over collaborative filtering, and points out where the weights should come from measurement rather than a spec. |

Movie Recommendation API

Community answers

Related questions

Your answer