5 exercises — choose the best-structured answer to common RecSys Platform Engineer interview questions. Focus on retrieval architecture, ANN indexes, feature stores, evaluation gaps, and A/B testing.
Structure for RecSys interview answers
Separate retrieval from ranking: two-tower retrieval → ANN index → re-ranking is the standard pipeline
Name loss functions: sampled softmax, BPR, InfoNCE — and their in-batch negative trade-offs
Distinguish offline from online stores: point-in-time correctness, freshness SLA, and recency feature computation
Quantify evaluation limits: Pearson r 0.3-0.5 offline/online correlation, SUTVA violations in A/B tests
0 / 30 completed
1 / 30
The interviewer asks: "Explain two-tower retrieval architecture for recommendation systems — how are the towers trained, what loss functions are used, and how is the model served at scale?" Which answer best covers two-tower architecture?
Option B provides the complete architecture: embedding dimensionality, sampled softmax mechanics with in-batch negatives and the popularity bias problem they introduce, hard negative mining as the solution, BPR and InfoNCE loss variants, the offline/online serving split (item embeddings batch-indexed, user tower online at query time with latency targets), specific ANN tools, the negative sampling pitfall and the mixed-negative fix, and recall@K as the right evaluation metric (not precision). Options A, C, D each describe the architecture correctly but don't cover loss function details, the popularity bias from in-batch negatives, or the serving latency targets.
2 / 30
The interviewer asks: "Compare HNSW and IVF-PQ for approximate nearest neighbour search — when would you choose each for a recommendation retrieval system?" Which answer best covers ANN index trade-offs?
Option B provides the complete comparison: HNSW graph search mechanics (multi-layer, greedy navigation), tuning parameters (ef, M, ef_construction), memory formula (O(N × dim × 4 bytes) + graph overhead), IVF-PQ two-stage mechanics (Voronoi partitioning + PQ 8-bit codes), memory compression factor (32× vs float32), the training requirement for IVF, practical scale thresholds (<10M for HNSW, billion-scale for IVF-PQ), ScaNN as an alternative, and the IVF-PQ + exact re-rank pattern to recover recall. Options A, C, D each identify the right use cases but provide no memory formulas, compression factors, tuning parameters, or the re-rank pattern.
3 / 30
The interviewer asks: "How does a feature store handle real-time user features for a recommendation system — explain the online/offline store duality and how recency features are computed and served?" Which answer best covers feature store architecture?
Option B covers all five dimensions: the online/offline store duality with specific technologies, point-in-time correctness with the data leakage problem and feature platform names (Feast, Tecton, Hopsworks), three real-time recency feature solutions (Flink streaming, session store with TTL, lambda architecture), freshness SLA per-feature with monitoring approach, and serving performance guidance (bulk get, P99 target, warm-up for top-K users). Options A, C, D each mention the dual store model and point-in-time joins but don't cover recency feature computation approaches, freshness SLA monitoring, or serving performance patterns.
4 / 30
The interviewer asks: "Why do offline recommendation metrics often fail to predict online performance — explain the offline/online gap and the role of popularity bias." Which answer best covers evaluation methodology?
Option B covers all six dimensions: the gap magnitude with a correlation range (Pearson r 0.3-0.5), root cause 1 (selection bias and false negatives for novel items), root cause 2 (power law distribution in interaction logs with the 90/10 example), root cause 3 (distribution shift), three mitigation techniques (IPS with its mechanism, interleaving with the statistical efficiency advantage, bandit-based replay), and the practical recommendation for how to use offline metrics. Options C and D identify popularity bias and selection bias but don't give the correlation range, the false-negative mechanism, distribution shift as a third cause, or the specific mitigation techniques.
5 / 30
The interviewer asks: "What are the unique challenges of A/B testing a recommendation system change — explain hold-out set contamination, network effects, and how you design a clean experiment?" Which answer best covers RecSys A/B testing?
Option B covers all six challenges: SUTVA violation and hold-out contamination with a concrete viral sharing example, network effects (social proof carry-over), novelty effect with the minimum duration recommendation, user-level vs item-level vs geo-based randomisation strategies for contamination prevention, CUPED variance reduction technique, MDE pre-calculation, and the experimental hygiene rules (one primary metric, 10% holdback). Options A, C, D each mention novelty effects but don't cover SUTVA, network effects with carry-over, CUPED, or the item/geo randomisation alternatives.
6 / 30
Code Review Comment: "This query is extremely slow. The `LIKE '%keyword%'` search on the user profile table is a major bottleneck. Consider using full-text indexing or a more sophisticated similarity search approach, perhaps leveraging an ANN index for faster retrieval."
The reviewer's comment correctly pinpoints a performance issue (slow `LIKE` query) and suggests appropriate solutions – full-text indexing or an ANN index. It avoids simply saying "it's slow" by offering concrete alternatives. The incorrect options misinterpret the comment's purpose or provide irrelevant feedback.
7 / 30
Slack Message from Alex (RecSys Engineer) to Ben (Data Scientist): "Hey Ben, I'm seeing a significant drop in click-through rates on the 'Trending Now' recommendations. The model seems to be heavily favoring items with extremely high popularity scores. Could you investigate if we're overfitting to the most popular items and potentially exacerbating the popularity bias?"
Alex's message identifies a critical performance issue – a drop in CTR driven by popularity bias. He frames it as a potential overfitting problem, prompting Ben to investigate. The incorrect options misunderstand the context or fail to grasp the core concern of the message.
8 / 30
PR Description: "Implemented a new feature to incorporate user session data into the recommendation model. This allows us to capture short-term preferences and improve relevance for users who are actively browsing. The update includes adding session ID as a feature and updating the training pipeline to include this data."
The PR description accurately details the changes – adding a session ID feature and updating the training pipeline. It explains the *why* (capturing short-term preferences) which is crucial for understanding the impact. The incorrect options misinterpret the scope or fail to explain the benefits.
9 / 30
Standup Update from Sarah (RecSys Engineer): "I've been working on optimizing the HNSW index for our product recommendations. I'm currently experimenting with different quantization parameters to balance search speed and recall. Initial results show a 15% improvement in average query latency, but we need to monitor recall more closely."
Sarah's standup update concisely describes her task (optimizing HNSW index), provides relevant metrics (15% latency improvement), and outlines her next steps (monitoring recall). This level of detail is appropriate for a daily standup. The other options fail to capture the essential information.
10 / 30
API Response (from Feature Store): `{
"version": "v2",
"data": [
{"user_id": "U1234", "item_category": "Electronics", "time_since_last_purchase": 7, "average_rating": 4.5},
{"user_id": "U1234", "item_category": "Books", "time_since_last_purchase": 30,
"average_rating": 3.8}
]
}` – This API returns user features for a specific product recommendation request.
The API response accurately represents a feature store data point – it includes attributes like user ID, item category, and relevant derived features (time since last purchase, average rating) useful for building recommendations. The incorrect options misinterpret the response's role or technical details.
11 / 30
Code Review Comment: "This query is extremely slow. The `LIKE '%keyword%'` search on the user profile table is a major bottleneck. Consider using full-text indexing or a more sophisticated similarity search approach, perhaps leveraging an ANN index for faster retrieval."
The reviewer's comment correctly pinpoints a performance issue (slow `LIKE` query) and suggests appropriate solutions – full-text indexing or an ANN index. It avoids simply saying "it's slow" by offering concrete alternatives. The incorrect options misinterpret the comment's purpose or provide irrelevant feedback.
12 / 30
Slack Message from Alex (RecSys Engineer) to Ben (Data Scientist): "Hey Ben, I'm seeing a significant drop in click-through rates on the 'Trending Now' recommendations. The model seems to be heavily favoring items with extremely high popularity scores. Could you investigate if we're overfitting to the most popular items and potentially exacerbating the popularity bias?"
Alex's message identifies a critical performance issue – a drop in CTR driven by popularity bias. He frames it as a potential overfitting problem, prompting Ben to investigate. The incorrect options misunderstand the context or fail to grasp the core concern of the message.
13 / 30
PR Description: "Implemented a new feature to incorporate user session data into the recommendation model. This allows us to capture short-term preferences and improve relevance for users who are actively browsing. The update includes adding session ID as a feature and updating the training pipeline to include this data."
The PR description accurately details the changes – adding a session ID feature and updating the training pipeline. It explains the *why* (capturing short-term preferences) which is crucial for understanding the impact. The incorrect options misinterpret the scope or fail to explain the benefits.
14 / 30
Standup Update from Sarah (RecSys Engineer): "I've been working on optimizing the HNSW index for our product recommendations. I'm currently experimenting with different quantization parameters to balance search speed and recall. Initial results show a 15% improvement in average query latency, but we need to monitor recall more closely."
Sarah's standup update concisely describes her task (optimizing HNSW index), provides relevant metrics (15% latency improvement), and outlines her next steps (monitoring recall). This level of detail is appropriate for a daily standup. The other options fail to capture the essential information.
15 / 30
API Response (from Feature Store): `{
"version": "v2",
"data": [
{"user_id": "U1234", "item_category": "Electronics", "time_since_last_purchase": 7, "average_rating": 4.5},
{"user_id": "U1234", "item_category": "Books", "time_since_last_purchase": 30,
"average_rating": 3.8}
]
}` – This API returns user features for a specific product recommendation request.
The API response accurately represents a feature store data point – it includes attributes like user ID, item category, and relevant derived features (time since last purchase, average rating) useful for building recommendations. The incorrect options misinterpret the response's role or technical details.
16 / 30
Code Review Comment: "This query is extremely slow. The `LIKE '%keyword%'` search on the user profile table is a major bottleneck. Consider using full-text indexing or a more sophisticated similarity search approach, perhaps leveraging an ANN index for faster retrieval."
The reviewer's comment correctly pinpoints a performance issue (slow `LIKE` query) and suggests appropriate solutions – full-text indexing or an ANN index. It avoids simply saying "it's slow" by offering concrete alternatives. The incorrect options misinterpret the comment's purpose or provide irrelevant feedback.
17 / 30
Slack Message from Alex (RecSys Engineer) to Ben (Data Scientist): "Hey Ben, I'm seeing a significant drop in click-through rates on the 'Trending Now' recommendations. The model seems to be heavily favoring items with extremely high popularity scores. Could you investigate if we're overfitting to the most popular items and potentially exacerbating the popularity bias?"
Alex's message identifies a critical performance issue – a drop in CTR driven by popularity bias. He frames it as a potential overfitting problem, prompting Ben to investigate. The incorrect options misunderstand the context or fail to grasp the core concern of the message.
18 / 30
PR Description: "Implemented a new feature to incorporate user session data into the recommendation model. This allows us to capture short-term preferences and improve relevance for users who are actively browsing. The update includes adding session ID as a feature and updating the training pipeline to include this data."
The PR description accurately details the changes – adding a session ID feature and updating the training pipeline. It explains the *why* (capturing short-term preferences) which is crucial for understanding the impact. The incorrect options misinterpret the scope or fail to explain the benefits.
19 / 30
Standup Update from Sarah (RecSys Engineer): "I've been working on optimizing the HNSW index for our product recommendations. I'm currently experimenting with different quantization parameters to balance search speed and recall. Initial results show a 15% improvement in average query latency, but we need to monitor recall more closely."
Sarah's standup update concisely describes her task (optimizing HNSW index), provides relevant metrics (15% latency improvement), and outlines her next steps (monitoring recall). This level of detail is appropriate for a daily standup. The other options fail to capture the essential information.
20 / 30
API Response (from Feature Store): `{
"version": "v2",
"data": [
{"user_id": "U1234", "item_category": "Electronics", "time_since_last_purchase": 7, "average_rating": 4.5},
{"user_id": "U1234", "item_category": "Books", "time_since_last_purchase": 30,
"average_rating": 3.8}
]
}` – This API returns user features for a specific product recommendation request.
The API response accurately represents a feature store data point – it includes attributes like user ID, item category, and relevant derived features (time since last purchase, average rating) useful for building recommendations. The incorrect options misinterpret the response's role or technical details.
21 / 30
Code Review Comment: "This query is extremely slow. The `LIKE '%keyword%'` search on the user profile table is a major bottleneck. Consider using full-text indexing or a more sophisticated similarity search approach, perhaps leveraging an ANN index for faster retrieval."
The reviewer's comment correctly pinpoints a performance issue (slow `LIKE` query) and suggests appropriate solutions – full-text indexing or an ANN index. It avoids simply saying "it's slow" by offering concrete alternatives. The incorrect options misinterpret the comment's purpose or provide irrelevant feedback.
22 / 30
Slack Message from Alex (RecSys Engineer) to Ben (Data Scientist): "Hey Ben, I'm seeing a significant drop in click-through rates on the 'Trending Now' recommendations. The model seems to be heavily favoring items with extremely high popularity scores. Could you investigate if we're overfitting to the most popular items and potentially exacerbating the popularity bias?"
Alex's message identifies a critical performance issue – a drop in CTR driven by popularity bias. He frames it as a potential overfitting problem, prompting Ben to investigate. The incorrect options misunderstand the context or fail to grasp the core concern of the message.
23 / 30
PR Description: "Implemented a new feature to incorporate user session data into the recommendation model. This allows us to capture short-term preferences and improve relevance for users who are actively browsing. The update includes adding session ID as a feature and updating the training pipeline to include this data."
The PR description accurately details the changes – adding a session ID feature and updating the training pipeline. It explains the *why* (capturing short-term preferences) which is crucial for understanding the impact. The incorrect options misinterpret the scope or fail to explain the benefits.
24 / 30
Standup Update from Sarah (RecSys Engineer): "I've been working on optimizing the HNSW index for our product recommendations. I'm currently experimenting with different quantization parameters to balance search speed and recall. Initial results show a 15% improvement in average query latency, but we need to monitor recall more closely."
Sarah's standup update concisely describes her task (optimizing HNSW index), provides relevant metrics (15% latency improvement), and outlines her next steps (monitoring recall). This level of detail is appropriate for a daily standup. The other options fail to capture the essential information.
25 / 30
API Response (from Feature Store): `{
"version": "v2",
"data": [
{"user_id": "U1234", "item_category": "Electronics", "time_since_last_purchase": 7, "average_rating": 4.5},
{"user_id": "U1234", "item_category": "Books", "time_since_last_purchase": 30,
"average_rating": 3.8}
]
}` – This API returns user features for a specific product recommendation request.
The API response accurately represents a feature store data point – it includes attributes like user ID, item category, and relevant derived features (time since last purchase, average rating) useful for building recommendations. The incorrect options misinterpret the response's role or technical details.
26 / 30
Code Review Comment: "This query is extremely slow. The `LIKE '%keyword%'` search on the user profile table is a major bottleneck. Consider using full-text indexing or a more sophisticated similarity search approach, perhaps leveraging an ANN index for faster retrieval."
The reviewer's comment correctly pinpoints a performance issue (slow `LIKE` query) and suggests appropriate solutions – full-text indexing or an ANN index. It avoids simply saying "it's slow" by offering concrete alternatives. The incorrect options misinterpret the comment's purpose or provide irrelevant feedback.
27 / 30
Slack Message from Alex (RecSys Engineer) to Ben (Data Scientist): "Hey Ben, I'm seeing a significant drop in click-through rates on the 'Trending Now' recommendations. The model seems to be heavily favoring items with extremely high popularity scores. Could you investigate if we're overfitting to the most popular items and potentially exacerbating the popularity bias?"
Alex's message identifies a critical performance issue – a drop in CTR driven by popularity bias. He frames it as a potential overfitting problem, prompting Ben to investigate. The incorrect options misunderstand the context or fail to grasp the core concern of the message.
28 / 30
PR Description: "Implemented a new feature to incorporate user session data into the recommendation model. This allows us to capture short-term preferences and improve relevance for users who are actively browsing. The update includes adding session ID as a feature and updating the training pipeline to include this data."
The PR description accurately details the changes – adding a session ID feature and updating the training pipeline. It explains the *why* (capturing short-term preferences) which is crucial for understanding the impact. The incorrect options misinterpret the scope or fail to explain the benefits.
29 / 30
Standup Update from Sarah (RecSys Engineer): "I've been working on optimizing the HNSW index for our product recommendations. I'm currently experimenting with different quantization parameters to balance search speed and recall. Initial results show a 15% improvement in average query latency, but we need to monitor recall more closely."
Sarah's standup update concisely describes her task (optimizing HNSW index), provides relevant metrics (15% latency improvement), and outlines her next steps (monitoring recall). This level of detail is appropriate for a daily standup. The other options fail to capture the essential information.
30 / 30
API Response (from Feature Store): `{
"version": "v2",
"data": [
{"user_id": "U1234", "item_category": "Electronics", "time_since_last_purchase": 7, "average_rating": 4.5},
{"user_id": "U1234", "item_category": "Books", "time_since_last_purchase": 30,
"average_rating": 3.8}
]
}` – This API returns user features for a specific product recommendation request.
The API response accurately represents a feature store data point – it includes attributes like user ID, item category, and relevant derived features (time since last purchase, average rating) useful for building recommendations. The incorrect options misinterpret the response's role or technical details.
What does "RecSys Platform Engineer — Interview Questions — Best-Answer Practice" cover?
Practice answering RecSys Platform Engineer interview questions in professional English. 5 exercises on two-tower retrieval, ANN index selection, feature stores, offline/online evaluation gap, and A/B testing recommendation systems.
How many questions are in this interview set?
This set has 30 exercises, each with a full explanation.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do these exercises include model answers?
Yes. Each interview question gives you several possible responses and asks you to pick the one that communicates most clearly and completely — the explanation then breaks down exactly why that answer works, including the specific vocabulary a strong candidate would use.
What if I choose an answer that isn't the strongest one?
You'll see which option was correct and read a full explanation of why it's stronger than the alternatives, plus the key vocabulary and phrasing worth reusing in a real interview.
Can I retry the questions?
Yes — use the "Try again" button on the results screen to reset and go through the set again.
Is this the same as a real technical or behavioural interview?
No — it's focused practice for the language side of interviewing: recognising which phrasing sounds precise and confident versus vague, and knowing the vocabulary interviewers expect for this role. It won't replace mock interviews, but it builds the vocabulary you'll need in one.
Where can I find interview prep for other roles?
Browse the full Interview exercises hub for 170+ modules covering behavioural, technical, and system design rounds across dozens of IT roles, or check the "Next up" link below to continue.
Do I need an account, and is my progress saved?
No account is needed. Progress is tracked only for your current visit — reloading or leaving the page resets the counter.
Who writes these interview questions?
Every question is written by the CoderSlingo team based on real technical interview patterns for this role, then reviewed for accuracy and clarity.