Interview Questions — Movie Recommendation System¶
These questions appear regularly in data science and ML engineering interviews when candidates have listed recommendation systems on their CV. Each question probes depth: the ability to explain a concept clearly, identify failure modes, and connect theory to real-world constraints.
Q1. What is the difference between content-based and collaborative filtering?¶
Show answer
Content-based filtering recommends items similar to what a user has already engaged with. Similarity is computed from item features — in this project, genre one-hot encodings. The system needs no data from other users, only a description of the items and the target user's history. If a user liked Inception, content-based will find other Sci-Fi movies with similar genre profiles.
Collaborative filtering ignores item features entirely. It finds users with similar rating patterns and recommends movies those users liked. The logic is: "people who agreed with you in the past will agree with you in the future." It does not need to know anything about what a movie is — only how users have rated it.
Key practical differences:
| Dimension | Content-Based | Collaborative Filtering |
|---|---|---|
| Features needed | Item metadata (genre, director, tags) | User-item interaction history only |
| New user | Cannot personalise without history | Cannot personalise without history |
| New item | Can recommend immediately (uses metadata) | Cannot recommend — no ratings yet |
| Filter bubble risk | High — stays in known genres | Lower — can cross genre boundaries |
| Scalability | Scales with item count | Scales with user × item count (hard) |
Most production systems combine both in a hybrid: content-based for new items, collaborative filtering for active users, and a rule-based popularity fallback for new users.
Q2. What is the cold start problem and how did you handle it?¶
Show answer
Cold start is what happens when a recommender encounters an entity with no historical data.
New user cold start: a brand-new user has rated nothing. Collaborative filtering has no similarity signal to work with. Content-based has no history to build a taste profile from.
New item cold start: a newly added movie has received zero ratings. Collaborative filtering cannot include it in recommendations at all — it has no column in the ratings matrix.
How this project handles it:
- New user: fall back to the popularity baseline (most-rated movies globally). It is not personalised, but it is better than a random list. In practice, you would also ask new users to rate a small seed set of movies during onboarding.
- New item: content-based filtering partially solves this. A new Sci-Fi movie can be recommended immediately because it has genre features. It will appear in recommendations for users with a strong Sci-Fi taste profile, even before a single rating arrives.
What you would do at scale: hybrid systems assign a new user a "cold start" mode that runs content-based or popularity logic, then gradually transitions to collaborative filtering as the user accumulates ratings (typically 10–20 ratings is the threshold). New items get a "launch boost" where they are shown to a small random user sample to quickly gather seed ratings.
Q3. The ratings matrix is ~85% empty. How does sparsity affect collaborative filtering?¶
Show answer
Sparsity creates three concrete problems for collaborative filtering:
1. Unreliable similarity scores. User-user cosine similarity is computed from shared rated movies. If user A rated 8 movies and user B rated 9 movies, they may share only 1–2 movies in common. A similarity score computed from 2 data points is noisy. You can end up treating users as "similar" or "dissimilar" based on almost no evidence.
2. Coverage gaps. When generating recommendations for a target user, you look for movies that similar neighbours have rated. If those neighbours are also sparse, many movies will have no predicted rating — the system cannot make a recommendation even when one would be appropriate.
3. Computational approaches that depend on matrix density fail. Simple mean imputation (fill NaN with the global mean) distorts the similarity structure. Filling with 0 before mean-centering (not after) corrupts the centering calculation.
Mitigations:
- Mean-centering before filling: center each user's ratings, then fill NaN with 0. This means 0 represents "average preference" not "no preference."
- Minimum co-rated threshold: only use a user as a neighbour if they share at least K co-rated movies with the target user. Reduces coverage but improves quality.
- Matrix factorisation: SVD and NMF compress the full matrix into dense latent factors. Every user-item pair gets a predicted rating, even if neither the user nor the item had many observed ratings. This is why model-based methods outperform memory-based methods at scale.
- Implicit feedback: use clicks, plays, and dwell time instead of explicit ratings. Implicit data is far denser — a user might rate 10 movies but play 500. The implicit library implements ALS for this use case.
Q4. Why did you mean-center ratings before computing user similarity?¶
Show answer
Mean-centering corrects for individual rating scale biases — the "harsh rater" and "easy rater" problem.
Consider two users: - User A gives everything 2–4 stars. Their "love it" is a 4. - User B gives everything 4–5 stars. Their "it was okay" is a 4.
Both users give Movie X a rating of 4. Without centering, their ratings look identical. With centering, User A's 4 becomes +1.0 (above their mean of 3.0) and User B's 4 becomes -0.5 (below their mean of 4.5). These are very different signals.
After centering, a positive value means "this user liked this more than average" and a negative value means "this user liked this less than average." Cosine similarity computed on centered ratings captures genuine agreement in preference direction, not coincidental agreement on absolute scale.
The correct order matters: 1. Compute each user's mean rating across their rated movies. 2. Subtract that mean from each of their ratings. 3. Fill NaN (unrated cells) with 0.
Filling with 0 after centering means "unrated = neutral / no opinion," which is a reasonable assumption. Filling with 0 before centering pulls the user's mean toward 0, making all their actual ratings appear positive, which distorts the centering entirely.
Q5. How do you evaluate a recommendation system offline? What are the limitations?¶
Show answer
The standard offline approach is train-test splitting the rating history per user. For each user, hold out one or more ratings as the test set (the "ground truth") and train on the rest. Then generate a top-K recommendation list for each user and check whether the held-out items appear in those lists.
Common offline metrics: - Hit Rate@K: fraction of users for whom at least one held-out item appears in their top-K list. - Precision@K: fraction of top-K recommendations that are held-out items, averaged across users. - Recall@K: fraction of held-out items that appear in the top-K list, averaged across users. - NDCG@K (Normalised Discounted Cumulative Gain): like precision, but weights hits higher if they appear earlier in the list. Closer to real user behaviour where position 1 gets more clicks than position 10. - RMSE/MAE: if the model predicts a rating value, measure the error against observed ratings. Rarely used in modern practice because predicting the exact rating value is less important than ranking correctly.
Limitations of offline evaluation:
- Only observed interactions are evaluated. A model might recommend a movie the user would love but has never seen — this is penalised as a miss, even though it is a good recommendation.
- Popularity bias. Held-out items are more likely to be popular movies (popular movies accumulate more ratings). Popularity baselines score disproportionately well offline even though they are not actually personalising anything.
- Position is ignored. Most offline metrics treat a top-K list as a set, not an ordered list. Real users click the first result far more often than the tenth.
- No context. Offline metrics ignore session context (time of day, device, mood), which are signals that matter enormously in practice.
- No novelty or serendipity signal. Recommending The Dark Knight to a Batman fan is "correct" by offline metrics but low value — they already know about it.
The only reliable evaluation is online A/B testing. Deploy the new model to a random subset of users and measure real engagement, retention, and business metrics over weeks.
Q6. What is Precision@K and why can't you just use accuracy?¶
Show answer
Precision@K = (number of relevant items in your top-K list) / K.
It measures how many of your recommendations were actually useful to the user. If K=10 and 2 of your recommendations match items the user engaged with, Precision@10 = 0.20.
Why standard accuracy fails:
Classification accuracy is defined as (correct predictions) / (total predictions). For a recommender, the "total predictions" would be every possible user-item pair. In a 200-user × 50-movie system, that is 10,000 pairs. The model correctly predicts "will not rate" for ~8,500 of them just by saying "no" to everything. Accuracy would be 85% for a model that never recommends anything — which is useless.
The fundamental issue is class imbalance. Relevant items are a tiny fraction of all items. Accuracy rewards predicting the dominant class (not relevant) without any useful signal.
Precision@K sidesteps this by only evaluating the top-K items the system actually commits to recommending. It focuses the evaluation on the specific subset the user will see.
The trade-off with Recall@K: a model that returns only 1 recommendation can achieve Precision@1 = 1.0 (if it gets it right) but Recall = 0.10 (it only found 1 of 10 relevant items). Precision and Recall trade off — that is why you report both, or use F1@K to combine them.
Q7. How would you handle a new user who has only rated 2 movies?¶
Show answer
A user with 2 ratings sits in a grey zone — not fully cold-start, but not warm enough for reliable collaborative filtering. The right strategy depends on what you know:
Immediate: popularity fallback with genre filtering. Take the user's 2 rated movies, identify their genres, and show the most popular movies in those genres. This is personalised (genre-aware) without needing neighbourhood similarity. Better than a pure global popularity list.
Content-based works reasonably well. With 2 rated movies you can build a basic taste profile: a weighted average of 2 genre vectors. Content-based recommendations from this profile will stay within the genres the user has shown interest in. The profile is noisy (2 data points), but it is better than nothing.
Collaborative filtering is unreliable. User-user similarity computed from 2 data points will share very few co-rated movies with most neighbours. The similarity scores will be based on sparse evidence. If you use CF, require a minimum co-rating threshold (e.g., at least 3 shared movies) before treating a user as a valid neighbour. If the user cannot meet that threshold with anyone, fall back to content-based.
Medium-term: active learning / onboarding. The best solution is to proactively ask the user to rate a few seed movies during onboarding. Show 10–15 well-chosen movies (covering diverse genres, well-known titles) and ask for quick ratings. Netflix does this with "how do you feel about these genres?" Spotify does this with "pick some artists you like." Five seed ratings are enough to significantly improve CF quality.
Long-term: implicit feedback. Track what the user watches, how long they watch it, and whether they return to the same genre. Even 10–20 implicit signals are enough to build a reasonable taste profile without requiring explicit ratings.
Q8. If building this for Netflix at scale, what would you change?¶
Show answer
This project is a learning tool. Netflix operates at a fundamentally different scale (250M users, millions of titles, real-time personalisation). Here is what would change and why:
Architecture: two-tower neural model instead of cosine similarity. At Netflix scale, you cannot compute pairwise cosine similarity over all users and items at query time — it would take minutes. Two-tower models train a user encoder and an item encoder independently, each producing a dense embedding vector. At query time, you retrieve candidates using approximate nearest-neighbour search (FAISS, ScaNN, or Google's ScaNN) over pre-computed item embeddings. This is O(log n) lookup instead of O(n).
Training signal: implicit feedback at massive scale. Netflix users rarely rate movies. The real training signal is: play start, play completion rate, pause events, rewatch, search queries, and hover time on thumbnails. These implicit signals are orders of magnitude denser than explicit ratings. Loss functions like Bayesian Personalised Ranking (BPR) and WARP are designed for implicit data.
Multi-stage retrieval pipeline. Production recommenders do not run one model over all items. They use a pipeline: 1. Candidate generation — retrieve ~500 candidates per user from a fast approximate model (matrix factorisation or two-tower). 2. Ranking — score the 500 candidates with a heavier model (gradient boosted trees or a deep neural net with user features, item features, context features, and interaction features). 3. Re-ranking — apply business rules: diversity constraints, catalogue freshness, licensed content windows, A/B experiment arms.
Feature richness. Genre one-hot encoding is a toy feature. Production systems use: title embeddings (from language models), visual embeddings (from thumbnail images), audio features, director/cast embeddings, user session history (last 5 viewed, not just lifetime history), time-of-day, device type, and country-specific popularity.
Online learning. User preferences change. A model trained monthly will miss the user who just finished a drama series and now wants something completely different. Netflix uses near-real-time feature updates and periodic model retraining (daily or more frequently for some components).
A/B testing infrastructure. Every model change is evaluated through rigorous A/B tests with 7–14 day holdout periods, measuring retention, engagement, and subscriber growth — not Precision@K.