Snap Practice: Algorithms, Product Thinking, and Evidence

This guide contains original exercises. It is not a Snap placement-paper archive, a record of a live assessment, or a prediction about who may be hired. The Snap careers page and an application-specific written notice are the sources to consult for current employer facts. This page does not publish a job count, compensation range, interview sequence, score, or candidate outcome.

Model a feed without guessing the product

Consider a list of items, each with a creation time and an author identifier. Write a function that returns the newest item for each author. Explain whether two items with the same timestamp need a tie rule and how your function behaves when the list is empty.

The important part is to identify the contract. If you choose a map, state what the key represents and when an existing entry is replaced. If you sort, explain whether that changes the order a caller expects. A clear response makes the design reviewable without relying on a named company's internal product.

Ask a product question before proposing a metric

Suppose a new feature lets people organise saved items. Before choosing a success metric, ask what user problem it is intended to solve and what action would indicate that the problem is less severe. A count of clicks may be interesting, but it does not always show whether the feature helps.

Describe one qualitative signal and one quantitative measurement you would need, then explain the limitation of each. Do not invent usage volumes or retention figures. An honest plan says what evidence is unavailable.

Test a recommendation rule for fairness

Imagine a ranking system that chooses items based on recent interaction. List a scenario in which a new user sees poor results and a scenario in which a narrow interest dominates the feed. For each, propose a test dataset and an expected property of the result.

This exercise is about defining behaviour before tuning an algorithm. It does not assert that any existing platform uses the rule described.

Debug an intermittent client failure

A screen occasionally shows no content even though a request was made. Write the observations you would collect: the request identifier, response status, state transition, and whether a retry occurred. Distinguish a symptom from a root cause. If you cannot reproduce the issue, say what telemetry or test environment would help rather than naming a cause.

Keep an application decision source-safe

Before applying to a live role, revisit the current official posting and preserve the version you read. If a condition matters to your eligibility or timing, rely on the written employer material that applies to you. General preparation pages and online speculation cannot establish that condition.