Movie Recommendation API

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.

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/<movieId>/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:

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