As a Data Scientist at Hinge, you are not just analyzing data; you are the architect of human connection. The company’s mission—to be the dating app "designed to be deleted"—places a unique burden on its data team. You are tasked with balancing complex algorithmic matching with the human element of relationships, ensuring that every user interaction moves them closer to a meaningful, long-term connection.
You will typically operate within product-focused teams like Matching, where your work directly influences the app’s core experience. Your daily impact involves translating abstract product objectives into measurable data science problems, designing rigorous A/B tests, and collaborating with engineers to deploy machine learning models. Because Hinge is obsessed with the metric of "setting up great dates," you will serve as a strategic partner to product managers and designers, using data to bridge the gap between user behavior and product strategy.
This role is ideal for a Data Scientist who thrives at the intersection of statistical rigor and product intuition. You will be expected to balance technical depth with the ability to influence cross-functional stakeholders. Whether you are investigating a sudden dip in engagement metrics or optimizing a recommendation engine, your work is the engine that drives the company’s mission to create a less lonely world.
Initial Screening
reportedWhoever runs this call is usually not a practitioner. They take notes, and a hiring manager skims those notes later, so the real question is whether your work survives being written down by someone outside the field. Test every project sentence against that: could a non-specialist repeat it correctly without knowing what a propensity score is? Carry a plain-language version of each project and one reason you want this particular role that you could not copy onto another application. Vagueness at this stage reads as inexperience, even when the underlying work was genuinely deep.
What to demonstrate
- Whether a non-specialist can restate your projects accurately, since their paraphrase is what reaches the hiring manager
- Whether your reason for wanting the role points at the work itself rather than the company's reputation
- Whether your language signals the level being screened for: what you decided yourself versus what you were handed
How to prepare
- Write a two-sentence, jargon-free version of each major project: the question nobody could answer, and the decision your work changed. Read it to someone outside data and have them repeat it back
- Point your 'why this role' answer at something concrete in the job description or the product surface you would be working on, and keep it to two sentences
- Have two questions ready about measurement: which metric the team is held to, and who acts on an analysis once it lands
Super Day
reportedWhere a loop includes a partner from outside the data team, that conversation usually carries the same weight as the technical ones and gets the least preparation. The person opposite you will not follow a derivation and does not need to. They are working out whether having you involved would make their decisions better or slower. The failure mode is not being too technical. It is answering a question about a decision with a description of your method, leaving the translation to them. What they carry into the debrief is the sentence you handed them, not the analysis underneath it.
What to demonstrate
- Whether a statistical result arrives as something the partner could act on, with the one caveat that would change their decision kept and the rest left out
- Whether you can state what you need from their side, in their terms: instrumentation that does not exist yet, a definition they own, or a holdout they have to agree to
- Whether uncertainty is given as a range someone can plan against, rather than as hedging that invites them to ignore the result
- Whether you ask what decision is actually on the table before explaining anything
How to prepare
- Take a result you know well and write the version for someone who stops reading after one sentence, then the three-minute version, and check the short one is not the long one with the qualifications stripped out
- For a past project, list everything you asked a non-technical partner for and how you phrased it, then rewrite each ask so it names what goes unmeasured without it
- Practise saying where a result does not apply, out loud, in one sentence that a partner could repeat accurately to someone else
PracHub editorial advice for the preparation topics above.
Averaging per-member engagement when the distribution is heavy-tailed
Time spent, impressions and authored actions per member are extremely right-skewed, so the sample mean has high variance and a handful of members can move a reported lift past significance on their own. Two specific errors follow. Averaging per-member rates (mean of ratios) answers a different question from total engagements over total members (ratio of sums), and the two diverge whenever the heavy users behave differently. Capping or winsorising reduces variance but changes the estimand, so the cap must be pre-registered and reported, not chosen after seeing the result. Ratio metrics with the member as randomisation unit also need delta-method or bootstrap variance, since numerator and denominator are correlated.
Randomising individual members when the treatment travels along the social graph
If treated members post, comment or share more, their followers see the extra content whether or not those followers are treated, so the control group is partly treated and the measured difference understates the true effect. For features that redistribute a fixed amount of attention, the leakage runs the other way and the effect is overstated. The size of the bias scales with how dense the neighbourhood is, so it is largest exactly among the connected members whose behaviour the feature was built for. The fix is randomising clusters of the graph (ego networks or communities found by balanced partitioning), clustering the variance at that unit, and accepting that effective sample size falls by roughly the average cluster size.
Extrapolating a first-week lift inflated by novelty effects
Plot the treatment effect by days since first exposure instead of quoting one pooled average. A lift that decays toward zero across the test window is behaviour that will not persist, and annualising it produces a forecast that misses by an order of magnitude.
Reading experiment results before checking the arm split
Compare observed arm counts against the intended allocation ratio, not an assumed even split, and set the alarm far below the conventional 0.05: at 0.05 roughly one healthy experiment in twenty trips it, which is why sample-ratio checks usually run at p < 0.001 or stricter. The test's power scales with sample size, so it misses a real diversion on a small experiment and fires on an imbalance too small to move the estimate on a very large one. A flag means go find the assignment or logging fault before reading any outcome, not report a mismatch.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Roll a daily negative feedback rate up to a week
You have two DataFrames. impressions: impression_id, event_date (date), surface. engagements: event_id, event_date, surface, impression_id (nullable), is_negative_feedback (bool). Compute negative feedback per 1,000 impressions: 1000 times the count of engagement rows with is_negative_feedback True and impression_id not null, over the count of impressions in the same date and surface. Return a daily table by surface, then a weekly table built by re-summing numerator and denominator. Also return the unweighted mean of the seven daily rates for the same weeks, and say which number you would publish.
Approach
- Aggregate the two frames separately to (event_date, surface) grain: a numerator count from engagements filtered on is_negative_feedback and impression_id.notna(), a denominator count from impressions. Keep them as two columns, not a pre-divided rate, because everything downstream needs the parts.
- Outer-join numerator onto denominator so that a day with impressions and zero negative feedback becomes a 0 rather than disappearing. A dropped zero-numerator day silently raises every rolled-up rate.
- Attach a week key to the daily frame, then compute the weekly rate as 1000 * sum(numerator) / sum(denominator) grouped by (week, surface). This is a ratio of sums.
- Compute the second, wrong number for comparison: groupby(week, surface).rate.mean(). Show the two side by side with the daily impression counts so the divergence has a visible cause.
- State the rule: the weighted version is the volume-weighted average of the daily rates, so the unweighted mean over-weights low-traffic days. The two agree only when every daily denominator is identical.
- Report numerator, denominator and rate in the output, never the rate alone, so a reader can tell a denominator move from a numerator move.
Follow-up
- The hide control moved from a submenu to the card on Tuesday. What happens to this metric, and is it a quality regression?
- How would you report this rate split by hide, report, not-interested and unfollow without publishing four charts nobody reads?
- An engagement row has impression_id NULL. Should it be in this numerator, and what is it measuring if you include it?
Classify daily actives into four mutually exclusive flow classes
sessions has member_id, session_start_utc (datetime64[ns]) and is_qualified (bool); members has member_id and tz_offset_minutes. Using qualified sessions only, put every active (member, local_date) pair into exactly one class: new (first ever qualified session that day), retained (also active the previous local day), reactivated (not active the previous day but active at least once in days d minus 28 through d minus 2), resurrected (not active at all in d minus 28 through d minus 1, active before that). Return a daily table of the four counts plus DAU, and report churn separately.
Approach
- Derive local_date as (session_start_utc + tz_offset_minutes).dt.date after joining members. A UTC day boundary cuts an evening session in half for large parts of the world, which depresses the metric by geography alone and makes country cuts uninterpretable.
- Reduce to distinct (member_id, local_date) rows first. Multiple qualified sessions in one local day are one active day, and forgetting this inflates every class equally while leaving the sum check passing, so it is invisible.
- The whole classification collapses to one lag. Sort by (member_id, local_date), take prev = groupby(member_id).local_date.shift(1), and let gap = local_date minus prev in days.
- Map gap to class: prev is NaT gives new; gap == 1 gives retained; 2 <= gap <= 28 gives reactivated; gap > 28 gives resurrected. This is exactly equivalent to the written windows, because the previous active date being in [d-28, d-2] is the same statement as the member being inactive on d-1 and active somewhere in that window.
- Compute churn on day d as members active on d-1 and absent on d. It belongs in its own table: its denominator is yesterday's actives, not today's DAU, so putting it in the same frame invites someone to add five numbers that do not sum to anything.
- Name the left-censoring limit before being asked, and name its direction. prev is NaT for anyone whose prior activity predates the window, so new absorbs those members and is inflated, while resurrected needs an observed gap above 28 days and therefore cannot occur before the 30th date at all. Drop that burn-in or carry a first-ever-active date computed from a longer history, and do not read the burn-in shape as a product change.
Follow-up
- DAU is flat week over week but retained fell and reactivated rose by the same amount. What do you tell the product owner?
- Marketing turned on a paid campaign on Monday. Which of these four classes moves first, and how long before it shows up in the weekly active number?
- How would you extend this to say whether the reactivated members are the same people every week or a rotating set?
Write a data-quality audit over impression and engagement logs
You are given impressions (impression_id, event_date, viewer_member_id, content_id, rank_position, dwell_ms, served_at_utc), engagements (event_id, actor_member_id, content_id, impression_id nullable, action_type, occurred_at_utc, undone_at_utc nullable) and content (content_id, author_member_id, created_at_utc, enforcement_state, enforcement_at_utc). Write audit(impressions, engagements, content) returning one row per check with the failing row count and share. Cover at least six checks across uniqueness, value range, referential integrity and timestamp ordering. Mark each check block-the-refresh or log-only, and say which NULLs are by design rather than defects.
Approach
- Group the checks by failure class first, then write one vectorised expression per check, so the function stays a table of (name, predicate) rather than a wall of conditionals. Every check returns a boolean mask over one frame and the report is built by summing masks.
- Uniqueness and range: duplicated impression_id; rank_position < 1; dwell_ms < 0 or null; served_at_utc in the future relative to the partition date.
- Referential integrity: engagement rows whose non-null impression_id is absent from impressions; impression rows whose content_id is absent from content. Then the sharper one, which is what catches real pipeline breaks: engagement rows joined to their impression where viewer_member_id does not equal actor_member_id, or the two content_id values disagree.
- Timestamp ordering: undone_at_utc earlier than occurred_at_utc; engagement occurred_at_utc earlier than its impression's served_at_utc; content created_at_utc later than an impression of it.
- Separate by-design NULLs from defects explicitly. impression_id is NULL for follow, unfollow and profile_click, and for any deep-linked action, so its null rate is a distribution to monitor, not a check to fail. session_id is NULL for server-side actions. duration_seconds is NULL for non-video media.
- Classify severity by what the number is used for: referential mismatches between actor and viewer corrupt every rate denominated in impressions and should block; a small orphan-FK share from late-arriving partitions is log-only with a threshold and a trend.
Worked solution 25 min
- Define CHECKS as a list of (name, frame, mask_fn, severity) so the report loop is three lines and adding a check is one.
- Build the joined frame once: e2i = engagements[engagements.impression_id.notna()].merge(impressions, on='impression_id', how='left', suffixes=('_e','_i')), then derive the orphan mask from the null right-side key and the mismatch masks from the compared columns.
- Run every mask, collect (check, severity, n_failing, share, n_total) into a DataFrame, and sort by severity then share.
- Add a separate informational block reporting the null rate of impression_id split by action_type, which is the distribution that would reveal a client logging regression without any check failing.
Follow-up
- The orphan rate on engagement to impression is 0.4 percent and all of it is within two hours of the partition boundary. Block or log?
- enforcement_at_utc is later than impressions already served for that content. Is that a defect, and what does it do to a query you ran last week?
- How would you turn this audit into something that fails a pipeline rather than producing a report nobody opens?
How would you handle missing data when joining user profile tables wit…
How would you handle missing data when joining user profile tables with interaction logs?
Approach
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- Say which table is the grain you start from, and join outward from it.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
Follow-up
- How does the query change if the join becomes one-to-many?
- What breaks if events arrive late or out of order?
Write a query using SQL window functions to calculate the running aver…
Write a query using SQL window functions to calculate the running average of user interactions over the last 30 days.
Approach
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- Say which table is the grain you start from, and join outward from it.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
Follow-up
- How does the query change if the join becomes one-to-many?
- How would you verify this result without re-running the same query?
Find original items that earned no engagement, correctly
From fct_content_item(content_id, author_member_id, created_at_utc, item_kind, enforcement_state, deleted_by_author_at_utc) and fct_engagement_event(event_id, content_id, target_member_id, action_type, is_negative_feedback, occurred_at_utc), list original items published last week that received no engagement of any kind in their first 72 hours. Note that fct_engagement_event.content_id is NULL for the follow, unfollow and profile_click action types. Return content_id, author, created_at_utc and the item's impression count from fct_feed_impression. A colleague's version returns zero rows on this data; explain why before you fix it.
Approach
- Name the bug first. NOT IN against a subquery that yields even one NULL evaluates to UNKNOWN for every outer row, because NOT IN expands to a conjunction of inequality comparisons and any comparison with NULL is UNKNOWN. UNKNOWN is not TRUE, the WHERE clause admits nothing, and the result is empty rather than visibly wrong.
- Fix it with NOT EXISTS, or with a LEFT JOIN plus an IS NULL test on the joined key. NOT EXISTS is the better habit because it stays correct when a NULL appears in a column that had none when the query was written, which is the failure mode that reaches production.
- Put the 72-hour condition inside the NOT EXISTS correlation rather than in an outer WHERE. Filtering on the engagement timestamp after a LEFT JOIN converts the anti-join back into an inner join and quietly returns items that were engaged with, just later.
- Separate no engagement from no distribution by joining a pre-aggregated impression count. A zero-engagement item with 3 impressions is a ranking outcome; one with 5,000 impressions is a content outcome, and only the second is worth anyone's afternoon.
- Decide and state the as-of rule. enforcement_state and deleted_by_author_at_utc are mutable and enforcement_at_utc is always later than impressions already served, so an item demoted today reads as unengaging retroactively. Either pin the window to items whose enforcement postdates it, or carry enforcement_state as an output column and let the reader condition on it.
Worked solution 40 min
- Reproduce and diagnose: SELECT COUNT(*) FROM fct_engagement_event WHERE content_id IS NULL returns a large positive number, since every follow, unfollow and profile_click row has no content.
- Rewrite as WHERE NOT EXISTS (SELECT 1 FROM fct_engagement_event e WHERE e.content_id = c.content_id AND e.occurred_at_utc < c.created_at_utc + INTERVAL '72 hours').
- Restrict the outer set to item_kind = 'original', created_at_utc inside last week, and created_at_utc + INTERVAL '72 hours' already elapsed, so every item in the result had its full observation window.
- LEFT JOIN a per-content_id impression count aggregated from fct_feed_impression and COALESCE it to 0.
- Carry enforcement_state through and count how many of the zero-engagement items are labelled, demoted or removed before drawing any conclusion about content quality.
Follow-up
- Write the anti-join three ways — NOT EXISTS, LEFT JOIN with IS NULL, and NOT IN with a NULL guard — and say which one you would put on a billion-row fact and why.
- Half the zero-engagement items have fewer than 20 impressions. What is the real finding, and what is the next cut?
- How would you make this query return the same number when someone re-runs it a month from now?
How would you define a "successful date" in the context of our product…
How would you define a "successful date" in the context of our product metrics?
Approach
- Restate the decision this analysis has to support, and who acts on the answer.
- Fix the population and the time window before naming any metric.
- State what result would change your recommendation, so the answer is falsifiable.
Follow-up
- Which segment would you cut first, and what would that rule out?
- How would you detect that the metric is being gamed rather than genuinely improving?
How do you balance the trade-off between short-term engagement and lon…
How do you balance the trade-off between short-term engagement and long-term user retention?
Approach
- Restate the decision this analysis has to support, and who acts on the answer.
- Name one primary metric, then the guardrail that stops it being gamed.
- State what result would change your recommendation, so the answer is falsifiable.
Follow-up
- How would you detect that the metric is being gamed rather than genuinely improving?
- What would you do if the primary metric and the guardrail moved in opposite directions?
How would you measure the success of a new feature designed to increas…
How would you measure the success of a new feature designed to increase the number of "Likes" sent?
Approach
- Decompose the metric into the rates that drive it, and say which one you would check first.
- Restate the decision this analysis has to support, and who acts on the answer.
- Name one primary metric, then the guardrail that stops it being gamed.
Follow-up
- What would you do if the primary metric and the guardrail moved in opposite directions?
- How would you detect that the metric is being gamed rather than genuinely improving?
If you were launching a feature to reduce "ghosting," what metrics wou…
If you were launching a feature to reduce "ghosting," what metrics would you track?
Approach
- Decompose the metric into the rates that drive it, and say which one you would check first.
- Name one primary metric, then the guardrail that stops it being gamed.
- Restate the decision this analysis has to support, and who acts on the answer.
Follow-up
- Which segment would you cut first, and what would that rule out?
- How would you detect that the metric is being gamed rather than genuinely improving?
Explain the concept of statistical significance to a non-technical pro…
Explain the concept of statistical significance to a non-technical product manager.
Approach
- Decide the analysis before seeing data, including how long it runs and when you look.
- Name the randomisation unit first; it decides the variance and what the test can detect.
- Say whether units interfere with each other, and switch design if they do.
Follow-up
- What would you conclude if the result is positive but the test is underpowered?
- What would you do if you could not randomise at all?
What are the most common experimentation pitfalls you have encountered…
What are the most common experimentation pitfalls you have encountered in your career, and how do you avoid them?
Approach
- Name the randomisation unit first; it decides the variance and what the test can detect.
- Decide the analysis before seeing data, including how long it runs and when you look.
- Say whether units interfere with each other, and switch design if they do.
Follow-up
- What would you conclude if the result is positive but the test is underpowered?
- What would you do if you could not randomise at all?
If we see a sudden drop in daily active users on a specific segment of…
If we see a sudden drop in daily active users on a specific segment of our platform, how would you investigate the root cause?
Approach
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- Work from the decision backwards to the evidence you would need.
Follow-up
- How would you know your answer was wrong?
- What assumption would you test first?
Choose a randomisation unit when reposts travel along the graph
A one-tap repost affordance is proposed for home_feed. Treated members are expected to repost more, and fct_follow_edge shows the median member follows 180 active accounts. A balanced partition of the active follow graph yields clusters averaging 40 members, with an intra-cluster correlation of 0.02 on the primary metric. Deliver the randomisation unit you would use, the sign of the bias if you randomise individual members instead, and the power cost of your design stated as a change in minimum detectable effect at fixed traffic.
Approach
- Name the leakage channel explicitly: the treatment output is content, and content reaches followers through fct_follow_edge regardless of the follower's arm. A control member who follows treated members receives part of the treatment, so the control mean rises and the measured difference understates the true effect.
- Say when the sign flips. For a feature that adds supply, interference attenuates the estimate toward zero. For a feature that reallocates a fixed number of slots, treated members win attention that control members lose, the control arm is pushed down, and the estimate is inflated.
- Randomise clusters of the graph: a balanced partition or ego-network design, assigned whole, so that most of a member's followees share their arm.
- Price the design: design effect = 1 + (m - 1) x rho with m = 40 and rho = 0.02. With unequal cluster sizes the cost is higher, approximately 1 + ((CV^2 + 1) x m - 1) x rho, and social graph partitions always have a heavy size tail.
- Estimate variance at the randomisation unit: cluster-level means weighted by size, or a member-level model with cluster-robust standard errors. With fewer than roughly 40 clusters per arm, fall back on CR2 with G - 1 degrees of freedom or randomisation inference.
- Report containment rather than assuming it: the share of each member's active followees that sit in the same cluster, plus an exposure-response cut on fraction of neighbours treated, which bounds the residual leakage the partition did not remove.
Worked solution 30 min
- Compute the design effect: 1 + (40 - 1) x 0.02.
- Convert to an MDE multiplier by taking the square root, and to a sample multiplier directly.
- Apply it to an individually randomised baseline of 95,900 members per arm to get the members and clusters required.
- Write the analysis plan at cluster grain: one size-weighted mean per cluster, difference of arm means, variance across clusters.
- Add the containment diagnostic and the exposure-response cut as pre-registered secondary output.
Follow-up
- When would a switchback beat a cluster design here, and what property of the repost feature breaks a switchback?
- Your partitioner can only produce 30 clusters per arm. What changes in the analysis?
- How would you estimate the spillover effect itself rather than just eliminating it from the direct estimate?
Weekly active members fell 1.8 percent: find the flow
Weekly members with at least one qualified session fell from 12.40M to 12.18M week over week, a 1.8 percent drop. You have dim_member, fct_feed_impression, fct_engagement_event and fct_content_item. The release log shows nothing shipped that week. Produce an ordered diagnostic checklist and run it far enough to name which flow moved: new, retained, reactivated or resurrected. Deliverable is a one-page readout stating the flow, the segment carrying most of the absolute member delta, and the residual you could not explain.
Approach
- Confirm the number before explaining it. Check partition completeness for the last two event_date partitions in fct_feed_impression and fct_engagement_event against the trailing four-week median rows per hour, and check whether a metric-definition commit landed. A 1.8 percent move is well inside what one late or partial partition produces, and explaining an artefact is the most expensive failure mode here.
- Rule out the calendar before the product. Confirm both weeks have identical weekday composition, no holiday in either, and compare the same week in prior years rather than only against last week, since this metric has a weekly and an annual shape.
- Decompose into the four DAU flow classes (new, retained, reactivated, resurrected) for every day in both weeks and verify they sum exactly to DAU each day. Read which class moved: a fall in new is acquisition and cannot be a same-week product regression, a fall in retained is.
- Cut the moved class by client_platform, app_version, country_code, tenure bucket and acquisition_channel, one dimension at a time, and rank the cuts by absolute member delta rather than percentage. A 20 percent drop inside a segment holding 1 percent of members cannot produce a 1.8 percent platform move.
- Separate mix from rate: recompute the platform number holding the prior week's segment weights fixed. The difference between that and the actual move is the mix term, and it is a different product conversation from a within-segment decline.
- Write the readout as flow plus segment plus residual, and name the single query that would close the residual instead of asserting a cause you have not isolated.
Follow-up
- If the entire drop sits in the new class, how far back must the acquisition change have happened, and why is a same-week product explanation almost certainly wrong?
- A qualified session needs 30 or more foreground seconds. How would you check whether a client timing change altered how strict that threshold effectively is?
- What evidence would make you call this seasonal rather than a regression, and what would you tell the product owner in the meantime?
Instead of guessing where the week should go, day one measures it under a fixed rubric and allocates the remaining hours in proportion to the gaps. The method is deliberately rigid: the allocation is written down before any studying starts and is not renegotiated when a topic turns out to be unpleasant.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Diagnostic, scored before you study anything
- Sit a 100-minute timed diagnostic in four blocks: 30 minutes of SQL across three prompts, 25 minutes of short-answer statistics, 25 minutes on one modelling or case prompt, and 20 minutes delivering one behavioural story aloud.
- Score each block from 0 to 3 on a fixed rubric where 3 is correct and fluent, 2 is correct but slow or prompted, 1 is partially correct, and 0 is stuck, grading the output rather than how the attempt felt.
- Allocate the hours for days two to five roughly in proportion to 3 minus the score in each block, write the allocation down, and commit to not revising it midweek.
Deliverable: A scored rubric and a fixed hour allocation for the rest of the week.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Largest gap: find the boundary rather than the subject
- Break the weakest area into five named sub-skills (for query work: grain control, window frames, date arithmetic, set logic with NULLs, and reading a query plan) and rate each one, so the rest of the week targets a sub-skill instead of a subject.
- Solve three problems chosen to sit just above where the rating drops off, and for each write the first move you failed to make.
- Re-solve one of them from memory four hours later, on paper, with nothing open.
Deliverable: A five-item sub-skill map with the two blocking sub-skills circled.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Largest gap: drill the blocking sub-skill
- Do eight short repetitions of the same shape rather than eight different problems, so what you practise is the pattern and not the puzzle.
- Write the rule you now hold in one sentence, then test it against a case built to break it: a ranking function over a column with ties, or a two-sample test on observations that are obviously dependent.
- Have someone else read your one-sentence rule and find the precondition you left out.
Deliverable: One rule statement with its preconditions attached and one counterexample that would have caught the incomplete version.
Practice prompt ↗Practice prompt ↗Practice prompt ↗04Second gap, plus maintenance on your strongest area
- Run the same sub-skill map and boundary protocol on the second-largest gap, compressed into half the day.
- Spend 25 timed minutes on your strongest area to stop it decaying, choosing the hardest problem you can still finish rather than an easy warm-up.
- Compare how the two areas fail: whether you lose time on recall, on setup, or on arithmetic, because the fix differs for each.
Deliverable: A second sub-skill map plus a one-line diagnosis of how each area fails you.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗05The gap that is not a skill
- Record yourself answering one technical and one behavioural prompt, then count two things in the playback: how many seconds before your first clarifying question, and how many sentences you started without knowing where they ended.
- Rewrite your three most-used stock phrases into shorter versions, and practise saying "I do not know, here is how I would find out" without softening it into a guess.
- Deliver one answer again with a hard 90-second limit to force structure before detail.
Deliverable: Two recordings with a counted improvement in time-to-first-question.
Practice prompt ↗Practice prompt ↗06Retest under day-one conditions
- Sit the same 100-minute diagnostic structure with new prompts of comparable difficulty and score it on the identical rubric.
- Compare block by block, and for any block that did not move, change the method rather than adding hours: a block stuck at 1 usually means the practice was too varied, not too short.
- Write which single block you would still lose the offer on.
Deliverable: A second scored rubric placed next to the first, with one named remaining risk.
Practice prompt ↗Practice prompt ↗07Full loop under interview conditions
- Run a 60-minute mock covering the two blocks that moved least, with an interviewer instructed to interrupt and change direction.
- Write your recovery script for the moment you go blank: restate the question, state your assumption, name the first thing you would check.
- Reduce the week to the rule statements you wrote, each with its preconditions attached, then say every one of them out loud without reading it and cut any you cannot state in a single sentence, since a rule you have to reconstruct mid-answer will not survive being interrupted.
Deliverable: A one-page card holding the recovery script and only the rules you could state from memory.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Work that nobody used is a common and unflattering pattern in data careers, and interviewers probe for it. Have a story about an analysis that changed a decision, and be specific about how you got it in front of the person who could act. Also have one about work that went nowhere, with your reading of why.
Describe a situation where you had to balance technical rigor with the…
Describe a situation where you had to balance technical rigor with the need for speed in product development.
Approach
- State the situation in two sentences and spend the rest on your reasoning.
- Close with what you would do differently, concretely.
- Quantify the outcome, including what you would not claim credit for.
Follow-up
- How did you know the outcome was caused by your change?
- What did you decide not to do, and why?
State the impact of your last six months without inflation
Summarise your last two quarters in five minutes, with numbers. For each claim state the decision it changed, the counterfactual (what would have been decided without your work), how the effect was measured (randomised read, before-after, or estimate), and who else has to be credited. Rank the projects by realised impact, not effort, and name the one that produced nothing. Do not present a shipped feature as your impact unless you can say what would have shipped otherwise.
Approach
- Structure every claim the same way so the interviewer can compare them: decision changed, counterfactual, measurement method, shared credit. A list of projects without counterfactuals is a job description, not an impact statement.
- Separate the two kinds of impact an analyst actually has and price them differently instead of converting both into a revenue figure. Decisions changed (a launch held, a cap not raised, a metric redefined before it locked in) are one kind; capability added (a definition, a holdout, a pipeline that later decisions ran on) is the other and usually compounds harder.
- Label the measurement honestly per claim. A randomised read supports a causal number; a before-after during a season or a marketing push supports a bounded statement at best. Saying which is which before being asked is the fastest credibility signal available in this question.
- Discount shared attribution out loud. A launch carries engineering, design and product with it, so claim the part your analysis moved: the decision that would have gone the other way, or the magnitude that was wrong until you corrected it.
- Name the project that produced nothing and say when you should have stopped it. Then rank by realised impact and be ready for the ranking to put your largest effort in third place, which is the point of the exercise.
Follow-up
- Which of these would have happened without you, roughly on the same timeline?
- What did you stop working on, and what was the signal that made you stop?
- How would your manager order this list differently, and why?
Defend a qualified-session definition against two motivated objections
The north star is weekly members with at least one qualified session: 30 or more foreground seconds plus at least one non-negative engagement or authored item. A utility surface team argues the 30-second floor penalises fast successful visits. A video team argues requiring an explicit action undercounts passive watching. Both teams are reviewed on this metric. In fifteen minutes, defend or revise the definition, state what each proposed change does to gameability, and name the evidence that would justify a revision.
Approach
- Split the two objections, because they attack different clauses and fail differently. The utility objection is about a threshold (30 seconds); the video objection is about the qualifying condition (an explicit action). Answering both with the same argument is the common tell that the definition was never understood.
- Test each proposed change for gameability before discussing its merit. Dropping the action requirement makes the metric movable by autoplay, by longer video, and by any change that keeps an item in the viewport, which is precisely the failure the clause exists to prevent. A per-surface floor lets one team obtain a definitional lift without changing member outcomes, and makes the platform total a sum of incomparable parts.
- Answer the video objection with evidence rather than principle, and say what evidence would move you: compare week-1 retention among members whose only qualifying signal was long dwell on video_short impressions against members whose qualifying signal was an explicit action. If a fitted dwell threshold predicts return at the same rate as a like, a dwell-based qualifier is defensible, fitted per media_type and re-fitted per period rather than inherited.
- Answer the utility objection by separating the metric from the review. One definition platform-wide, with surface-level diagnostics beside it, and a review conversation that credits the utility surface on its own funnel rather than on a whole-platform north star it structurally cannot move. Forking the definition solves the review problem by destroying the metric.
- Fix the change process in advance so revisions cannot be mistaken for wins: any new definition is dual-reported beside the old one for at least four weeks, the size of the definitional jump is published, and the team proposing the change does not own the analysis that evaluates it.
Follow-up
- The utility team says they are graded on a number they cannot move. What do you actually offer them?
- What evidence would make you drop the 30-second floor entirely, rather than adjust it?
- Enforcement state changes after impressions are served. Does a session stay qualified when its only engagement was on content later removed?
- 01
Describe a situation where you had to balance technical rigor with the need for speed in product development.
- 02
Summarise your last two quarters in five minutes, with numbers. For each claim state the decision it changed, the counterfactual (what would have been decided without your work), how the effect was measured (randomised read, before-after, or estimate), and who else has to be credited. Rank the projects by realised impact, not effort, and name the one that produced nothing. Do not present a shipped feature as your impact unless you can say what would have shipped otherwise.
- 03
The north star is weekly members with at least one qualified session: 30 or more foreground seconds plus at least one non-negative engagement or authored item. A utility surface team argues the 30-second floor penalises fast successful visits. A video team argues requiring an explicit action undercounts passive watching. Both teams are reviewed on this metric. In fifteen minutes, defend or revise the definition, state what each proposed change does to gameability, and name the evidence that would justify a revision.
Is this an official Hinge interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Hinge. Rounds and questions reflect what candidates have reported, not a process Hinge has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How much time should I spend preparing?
Most successful candidates spend 3–4 weeks of focused preparation, specifically reviewing SQL window functions and experimentation theory.
PracHub interview research ↗What differentiates top candidates?
Successful candidates don't just solve the math; they connect their solutions to the user experience and the company's core mission of "setting up great dates."
PracHub interview research ↗What is the culture like at Hinge?
Hinge emphasizes Authenticity and Empathy. They value people who can challenge ideas respectfully while maintaining a collaborative, team-first attitude.
PracHub interview research ↗Is the process always the same?
While the structure is consistent, the specific focus of the technical rounds can vary by team (e.g., Matching vs. Growth).
PracHub interview research ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
PracHub page · Accessed 2026-09-22 - 02PracHub Data Scientist practice ↗
Cross-company practice questions for this role.
PracHub page · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
TELUS Digital AI Community Data Scientist Interview Questions & Guide 2026
SQL sets for data scientist prep ahead of TELUS Digital AI Community, covering window functions, funnel and retention queries, and the joins that quietly drop the rows you needed.
Suno Data Scientist Interview Questions & Guide 2026
Timed practice for Suno data scientist candidates who freeze under a clock: short SQL and probability sets run end to end, then reviewed against a written rubric.
Strike Social Data Scientist Interview Questions & Guide 2026
Product-sense practice for a Strike Social data scientist interview: define a social and content platforms metric, pick its guardrails, and argue why a tempting alternative would mislead you.
Reddit Data Scientist Interview Questions & Guide 2026
Data-quality drills for Reddit data scientist prep: survivorship and selection bias, leakage through time-ordered features, and extreme values where provenance decides the call. A logging fault or unit slip gets corrected or dropped; a genu