As a Data Scientist at Viber, you will play a pivotal role in transforming data into actionable insights that influence product development, enhance user experience, and drive business strategy. Your work will directly impact millions of users by improving features like messaging efficiency, user engagement, and personalized content delivery. This role is not just about analyzing data; it's about synthesizing complex datasets into strategic recommendations that guide product teams and inform key business decisions.
The significance of a Data Scientist at Viber is underscored by the scale and complexity of the platform. With a diverse user base and a multitude of communication features, you will engage with sophisticated data challenges. You'll collaborate with teams across engineering, product management, and marketing to innovate solutions that address user needs and business objectives. This role is critical for those who thrive at the intersection of technology, data analysis, and user-centric design, providing rich opportunities to influence the future of communication.
HR Screening
reportedA screening call is a matching exercise run by someone who will not evaluate your statistics. They are checking that the work described on your resume is work you personally did, and that its scope matches the level the role is written for. Logistics get settled in the same half hour so nobody spends an interviewer's afternoon on a mismatch. The answer that fails is the one narrated in the plural. If every sentence is 'we built' and 'the team decided', there is nothing specific to write down about you. Name the piece that was yours, the decision you made inside it, and what changed after.
What to demonstrate
- Whether the ownership implied by your resume survives one round of follow-up about who actually did which part
- Whether your described scope (data size, stakeholders, what shipped) matches the seniority the role is written at
- Whether timeline, location and compensation expectations make the rest of the loop worth scheduling
How to prepare
- Rewrite your top three resume bullets in the first person singular, each with the decision you made and what moved afterwards, then say them out loud once so the 'we' does not return under pressure
- Attach one number to each project: the baseline, the change, and the window it was measured over. Where impact was never measured, say that plainly rather than inventing a figure
- Settle your compensation range before the call and give it as a range with a reason behind it, such as current total comp or a competing timeline, instead of deflecting the question twice
Technical Interviews
reportedMuch of what gets scored here happens out loud while you type. Nobody can see your reasoning inside a half-written query, so five silent minutes read as being stuck even when they are not. State the plan in plain language first: which tables, what grain you are aggregating to, and the one filter that defines the population. Then write it. The narration doubles as insurance, because a wrong plan gets caught early and cheaply while a wrong query gets caught at the end with no time left to redo it. A timed statistics section, where one exists, is a separate test with its own clock.
What to demonstrate
- Whether the query you write matches the plan you just described
- What you do with a hint, meaning whether the correction gets absorbed or the first approach gets defended
- Whether you can debug your own wrong output by reading the result set and naming which part of the query produced the anomaly
How to prepare
- Solve three problems while screen-sharing into a recording, then watch it back and mark every stretch longer than thirty seconds where you said nothing
- Practise compressing the plan into one sentence before typing, then check afterwards whether the finished query actually matched it
- Time yourself on statistics questions that carry a business reading, such as what a confidence interval does and does not claim, rather than re-reading notes without a clock
Final HR Interview
reportedA loop is not scored one interview at a time. The people you meet compare notes afterwards, usually in a meeting you are not in, and the outcome turns on what each of them can say about you when asked. That rewards something other than survival: every room needs one specific thing worth repeating, and none of them can contradict another. The common way to lose is to tell the same project four times with different numbers in it, or to be uniformly fine in a way that leaves nobody with anything to argue for.
What to demonstrate
- Whether your account of a project survives being told twice, with the same scale, the same metric definition and the same numbers each time
- Whether each interviewer leaves with one concrete claim they could make on your behalf later, rather than an absence of complaints
- Whether a question you already answered in an earlier room gets the same answer at the same depth, without visible impatience
How to prepare
- Write a one-page fact sheet for your two or three main projects that fixes the numbers you will quote: rows of data, the metric as a single sentence, the effect you measured and how long the work took. Say them aloud from the sheet until they come out identical every time
- For each kind of room you expect, decide the one sentence you want that interviewer repeating in a debrief, then check during the mock that you said it outright instead of implying it
- Rehearse answering the same project question twice in one sitting, the second time as though you had not just answered it, because the thing that needs fixing is the flatness that creeps into a repeated story
PracHub editorial advice for the preparation topics above.
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.
Using report volume as a measurement of how much violating content exists
Reporting is a member behaviour, not an observation of the content. Report counts rise when the report control is made easier to reach, when a coordinated campaign targets an account, and when the audience shifts toward people who object; they fall when violating content is shown mainly to members who agree with it. A ranker that gets better at matching bad content to receptive audiences will drive reports down and harm up at the same time. Prevalence must come from a random sample of served impressions with recorded selection probabilities, labelled by humans against the written policy, and reported with an interval. Reports are useful as a detection signal and as a demand-side complaint rate, not as a denominator-anchored measure of harm.
Dropping rows with missing values without naming the mechanism
Say whether the values are missing at random, missing by a known process, or missing in a way that depends on the outcome, and handle them accordingly. Deleting incomplete rows silently redefines the population whenever missingness correlates with what you are measuring.
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.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Write a function to calculate the mean and standard deviation of a lis…
Write a function to calculate the mean and standard deviation of a list of numbers.
Approach
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
- Write down the assumption the method needs before you use the method.
- Say what the estimate is of, and over what population it generalises.
Follow-up
- How would you explain this result to someone who does not know statistics?
- Which assumption here is most likely to be violated in practice?
What machine learning algorithms are you most familiar with, and when …
What machine learning algorithms are you most familiar with, and when would you use them?
Approach
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- Check what information would not exist at prediction time, and exclude it.
- Pick an evaluation metric that matches the cost of each error type, not a default.
Follow-up
- Where could label leakage enter this setup?
- What would you monitor after launch to know the model is still valid?
Given a dataset, how would you approach building a predictive model fo…
Given a dataset, how would you approach building a predictive model for user churn?
Approach
- Check what information would not exist at prediction time, and exclude it.
- Pick an evaluation metric that matches the cost of each error type, not a default.
- Set a baseline first, so any model has something honest to beat.
Follow-up
- How would you choose the decision threshold, and who owns that choice?
- What would you monitor after launch to know the model is still valid?
Trailing seven-day distinct actives without a rolling window
activity has member_id (int64) and local_date (date), one row per member per active local day, about 60 million distinct pairs spanning 400 dates. For every date d in the range, compute the number of distinct members active on at least one day in the closed window [d minus 6, d]. You may not use rolling, and you may not loop over dates recomputing a distinct count across the full frame. Return a DataFrame of date and wau, and state the time and memory cost of the method you chose.
Approach
- Say why the obvious answers fail. Summing seven daily active counts double-counts anyone active on more than one day, which is most of the active base. Looping over 400 dates with a nunique over 60 million rows is 400 full passes. Neither is a rolling-window problem in the pandas sense, because the aggregate is a distinct count and distinct counts do not decompose additively.
- Reframe it geometrically. A member contributes to wau(d) exactly when d lies in [t, t+6] for one of their active dates t. So the answer is the size of the union of those intervals, counted across members, evaluated at each date.
- Merge each member's intervals before counting, which is the step that removes the double counting. After sorting by (member_id, local_date), a new interval starts wherever the gap to the previous active date exceeds 7 days; otherwise the interval extends. The run's interval is [first t of the run, last t of the run + 6].
- Turn merged intervals into a difference array: plus one at each interval start, minus one at end plus one day, then a cumulative sum over the full date index. That is O(number of runs) memory and one sort overall.
- Offer the simpler alternative and price it: explode each (member, date) into the seven dates it covers, drop duplicates on (member, target_date), then count per target_date. Correct and easy to defend, but it materialises seven times the rows before the dedupe, so it is a memory decision rather than a correctness one.
- Handle the edges: dates in the first six days of the range have a truncated window and should be reported as such or dropped, not silently published as a lower wau.
Worked solution 35 min
- a = activity.drop_duplicates().sort_values(['member_id','local_date'])
- gap = a.groupby('member_id').local_date.diff().dt.days; run_start = gap.isna() | (gap > 7); run_id = run_start.groupby(a.member_id).cumsum()
- runs = a.groupby([a.member_id, run_id]).local_date.agg(['min','max']); runs['end'] = runs['max'] + pd.Timedelta(days=6)
- deltas = pd.concat([runs['min'].value_counts(), -(runs['end'] + pd.Timedelta(days=1)).value_counts()]).groupby(level=0).sum()
- wau = deltas.reindex(full_date_index, fill_value=0).cumsum().rename('wau').to_frame()
- Mark the first six dates as truncated and either drop them or carry a flag column
Follow-up
- Now report wau by country. What breaks in the interval approach and what do you change?
- The definition changes to distinct members with at least two active days in the window. Does either method survive?
- How would you compute the same number incrementally each day without recomputing the whole history?
Explain the time complexity of your solution.
Explain the time complexity of your solution.
Approach
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- State the window function and its partition and ordering out loud before writing it.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
Follow-up
- What breaks if events arrive late or out of order?
- How does the query change if the join becomes one-to-many?
Split daily actives into new, retained, reactivated and resurrected
From daily_active(member_id, activity_date), one row per member per member-local day with a qualified session, classify every member active on day d into exactly one class: new (first-ever activity on d), retained (also active on d-1), reactivated (inactive on d-1 but active somewhere in d-28 to d-2), resurrected (inactive across all of d-28 to d-1 but active before d-28). Return day, class and member count; the four classes must sum to that day's active count. Report churn (active on d-1, absent on d) as a separate series, not a fifth class.
Approach
- Derive one value per row with LAG(activity_date) OVER (PARTITION BY member_id ORDER BY activity_date). Every class in the definition is a statement about the previous active day, so this single window function does all four.
- Map the definitions onto the gap: prev_date IS NULL means new; gap = 1 means retained; prev_date in [d-28, d-2], that is a gap of 2 through 28, means reactivated; prev_date earlier than d-28, a gap above 28, means resurrected. That equivalence is worth stating, because it is what makes the classes exhaustive rather than three predicates and an else.
- Write the classification as one CASE with branches in that fixed order, so exclusivity holds by construction. Four independent EXISTS subqueries look clearer and are the usual source of a member landing in two classes.
- Compute churn in a separate pass: day d-1's actives anti-joined to day d, indexed to the day the member went absent. Churn is not a class of actives on day d, since a churned member has no row on day d at all, and adding it would break the sum.
- Assert the check before showing anyone the result: for each day, the four class counts must sum to COUNT(DISTINCT member_id) in daily_active for that day. That check is the whole reason this decomposition is believed.
Worked solution 30 min
- WITH a AS (SELECT member_id, activity_date, LAG(activity_date) OVER (PARTITION BY member_id ORDER BY activity_date) AS prev_date FROM daily_active).
- Classify: CASE WHEN prev_date IS NULL THEN 'new' WHEN activity_date - prev_date = 1 THEN 'retained' WHEN activity_date - prev_date <= 28 THEN 'reactivated' ELSE 'resurrected' END.
- GROUP BY activity_date, class and count members.
- Churn: SELECT d.activity_date + 1 AS churn_date, COUNT(*) FROM daily_active d LEFT JOIN daily_active n ON n.member_id = d.member_id AND n.activity_date = d.activity_date + 1 WHERE n.member_id IS NULL GROUP BY 1.
- Run the sum check per day and only then join the class counts to the churn series for reporting.
Follow-up
- DAU is flat but the retained share fell four points while reactivated rose four. What happened, and what is the next query you run?
- How do these classes change if the day boundary is each member's local midnight rather than UTC midnight?
- Produce the same decomposition weekly instead of daily. Which class definition stops making sense?
Describe a complex data problem you encountered and how you resolved i…
Describe a complex data problem you encountered and how you resolved it.
Approach
- Fix the population and the time window before naming any metric.
- 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
- What would you do if the primary metric and the guardrail moved in opposite directions?
- Which segment would you cut first, and what would that rule out?
How would you prioritize features for a new product based on user data…
How would you prioritize features for a new product based on user data?
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
- 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?
How would you handle missing data in a dataset?
How would you handle missing data in a dataset?
Approach
- Clarify what is being asked and what a complete answer would contain.
- Work from the decision backwards to the evidence you would need.
- Say what you would check first and why it is the highest-information step.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Measure violating content prevalence when reports are the wrong instrument
Leadership tracks content quality with weekly report volume, counted from fct_engagement_event where action_type = 'report'. It fell 14 percent after a ranker release and the release was declared safe. Explain in mechanism terms why that inference is invalid, then specify the measurement you would build: the sampling frame over fct_feed_impression, the selection probabilities, the estimator, and the sample size needed to separate 0.50 percent from 0.60 percent prevalence at 80 percent power and 5 percent two-sided alpha. State what the resulting estimate still cannot tell you. Deliverable: critique, design with numbers, limitation.
Approach
- Give the mechanism for the fall rather than calling it suspicious. Reporting is a viewer behaviour, so a ranker that matches violating content more precisely to receptive audiences lowers reports and raises harm at the same time. Report counts also move with where the control sits in the UI and with coordinated campaigns, neither of which is a property of the content.
- Set the frame as served impressions, not content items, because harm scales with delivery. An item seen once and an item seen a million times are one row each in fct_content_item and wildly different in fct_feed_impression.
- Specify sampling with recorded, strictly positive probabilities: stratify by surface and language_code, record p_i per stratum, allow no stratum at zero. Then estimate prevalence as the ratio of sum(1/p_i) over sampled impressions labelled violating to sum(1/p_i) over all labelled impressions, with a ratio-estimator interval rather than a binomial one, because the denominator is itself a weighted sum.
- Do the arithmetic. For two proportions with p1 = 0.005 and p2 = 0.006, n per arm is approximately (1.96 * sqrt(2 * 0.0055 * 0.9945) + 0.8416 * sqrt(0.0050.995 + 0.0060.994))^2 / (0.001)^2, which is about 86,000 labelled impressions per arm. Inflate by the design effect implied by the variation in sampling weights, roughly 1 plus the squared coefficient of variation of those weights.
- State the limitation: the estimate is bound to one written policy version and carries label noise, it says nothing about harm from content that is within policy, and it cannot be compared against any figure derived from a report-based or classifier-tail sample.
Worked solution 40 min
- Write the report-volume critique as three named mechanisms, audience selection, control placement and coordinated campaigns, each with the direction it pushes the number.
- Define the frame and stratification: served impressions in the calendar week, stratified by surface and language_code, with p_i recorded per stratum and no stratum at zero.
- Write the Horvitz-Thompson ratio estimator and the form of its variance, and state that the confidence interval must be a ratio-estimator interval.
- Do the sample-size arithmetic for 0.005 against 0.006 and report the per-arm figure, then inflate it by the design effect from weight variation.
- Write the limitation paragraph and name the one change that makes the series comparable across quarters: attaching the frozen policy version to every label.
Follow-up
- Human labelling costs money. Given a fixed weekly budget, do you buy one large weekly estimate or a smaller daily one?
- The written policy changes mid-quarter. What happens to your series and what do you do about it?
- How would you measure the effect of a demotion, which changes distribution rather than removing the item?
Hide rate doubled overnight: content regression or affordance change
Negative feedback per 1,000 home_feed impressions rose from 3.1 to 5.8 in one day and stayed there. A client release went out the same day on one platform only. Using fct_engagement_event (action_type, is_negative_feedback, impression_id, surface, event_date) and fct_feed_impression (event_date, surface, client_platform, app_version, dwell_ms, session_id), decide whether content quality changed or the measurement did. Deliverable: a verdict, the evidence that separates the two causes, and a statement of what this rate is now comparable to.
Approach
- Split the ratio before interpreting it. Plot the numerator (negative feedback events) and the denominator (impressions) as separate daily series by client_platform. A rate doubles just as easily because the denominator halved, and this costs one query.
- Cut both series by app_version rather than only by platform. A staged rollout produces a rate that tracks adoption share day by day, which is a fingerprint no content change leaves.
- Use the platform that did not ship as a control. It draws from the same content pool over the same days, so a flat series there is strong evidence the content did not change.
- Split the numerator by action_type. Relocating one control moves that action alone, while a genuine quality regression moves hide, report, not_interested and unfollow together, with report typically lagging rather than stepping.
- Interrogate the denominator definition. An impression counts once the item held half the viewport for 250 ms, so a render or scroll change can alter what qualifies. Compare impressions per session and the dwell_ms distribution across the release boundary.
- Close on comparability: this rate is a function of how reachable the control is, so post-release values can only be compared to post-release values. Re-baseline the alert threshold and record the discontinuity in the metric definition.
Follow-up
- The UI change is permanent. How do you set a new alert threshold without waiting a full seasonal cycle?
- If hides really did rise because the control is easier to reach, is that extra signal good or bad for the ranker that consumes it?
- What would convince you that content quality also degraded underneath the affordance change?
For someone who can already write the query and train the model but stalls when asked what to measure or whether a change is worth making. Metric definition and case structure come first; the technical work is kept as maintenance rather than the centre of the week.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Metric anatomy
- For three products you use daily, write one primary metric, two input metrics that plausibly move it, and one guardrail that would catch a cheap way of moving the primary at the cost of the product.
- For one of them, specify the metric precisely enough that two analysts would return the same number: numerator, denominator, unit of observation, time window, and how returning and deleted accounts are treated.
- Pick a ratio metric and write what happens to it when the denominator shrinks for reasons unrelated to the numerator, with a concrete example of that happening.
Deliverable: A one-page metric tree for one product, with the primary metric written as an unambiguous spec.
Practice prompt ↗Practice prompt ↗Worked solution ↗02Diagnosing a drop without guessing
- Take the prompt "weekly active users fell 8 percent week over week" and write the segmentation plan before proposing any cause: platform, region, tenure cohort, acquisition channel, and whether the movement sits in the numerator or in a changed denominator.
- List the instrumentation failures that manufacture fake drops (a client release that stopped firing an event, a bot filter change, a shifted date boundary or timezone) and write the query that rules out each one.
- Rehearse stating the boring explanations first, seasonality and day-of-week composition, before reaching for a product cause.
Deliverable: A drop-diagnosis checklist short enough to recite from memory in under a minute.
Practice prompt ↗Practice prompt ↗03Should we build it
- Take a feature idea and write it as a bet: what you believe is true, what would have to be true for it to pay off, the metric that would confirm it, and the effect size that would justify the engineering cost.
- Size the opportunity top-down and bottom-up, then reconcile the two numbers in writing instead of quoting whichever is friendlier.
- Write the counter-metric that would make you kill the feature even if it wins on the primary metric.
Deliverable: A one-page product memo ending in a decision rather than a list of considerations.
Practice prompt ↗Practice prompt ↗04The places aggregate numbers lie
- Construct a Simpson's paradox numerically: two segments where the treatment wins within each segment yet loses overall, and identify the shift in segment weights that causes it.
- Take a heavy right-tailed quantity such as revenue per user and write why the mean is the wrong summary, which percentile you would report instead, and what a moving mean with a stable median tells you.
- Write your definition of a session for the product from day one, then name two real behaviours it misclassifies.
Deliverable: One page holding a worked Simpson's paradox table and a session definition with its two known failure cases.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Technical maintenance, aimed at metrics
- Solve four timed SQL prompts that all end in a ratio metric, so the question of grain stays live in every answer.
- Compute a 95 percent confidence interval for a proportion on a small sample, and state why the normal approximation is unreliable when either np or n(1 minus p) falls below roughly 10, along with which interval you would use instead.
- Take one metric from your day-one tree, write the query that computes it correctly, then write the query that computes it wrong in the most plausible way and explain how you would notice.
Deliverable: Four solved prompts plus a matched correct and plausible-wrong query for one metric.
Practice prompt ↗Practice prompt ↗06Turning engineering work into data science stories
- Write three project stories as situation, decision, trade-off, outcome, each carrying one number and one thing you got wrong.
- For the story you will lead with, prepare an answer to "what would you do differently" that names a decision you made, not a constraint you were handed.
- Practise the sentence that reframes a systems project as a question project: the question the work answered, ahead of the pipeline it shipped.
Deliverable: Three written stories with the lead story delivered aloud and timed under four minutes.
Practice prompt ↗Practice prompt ↗07Mock case and gap list
- Run a 40-minute mock case with someone playing a product manager who pushes back on your metric choice, and record it.
- Listen back and mark every moment you proposed a solution before the success metric existed.
- Rewrite those moments as the question you should have asked, and rehearse the first 90 seconds of the case until scoping comes before solving.
Deliverable: A recorded case plus a rewritten opening 90 seconds.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Have two ready. In one, the data was on your side and you had to move someone who outranked you. In the other, the pushback was correct and you changed position. The second is the harder story and it lands better, because it shows you separate being right from being attached to an answer. Name the person's actual objection.
Describe a time when you used statistical analysis to solve a problem.
Describe a time when you used statistical analysis to solve a problem.
Approach
- Quantify the outcome, including what you would not claim credit for.
- Name the disagreement or constraint, and how you resolved it with evidence.
- State the situation in two sentences and spend the rest on your reasoning.
Follow-up
- What would you do differently if you ran that project again?
- What did you decide not to do, and why?
Tell me about a time you had to work with a difficult team member.
Tell me about a time you had to work with a difficult team member.
Approach
- Pick a story where you drove the decision, not one where you observed it.
- Quantify the outcome, including what you would not claim credit for.
- Name the disagreement or constraint, and how you resolved it with evidence.
Follow-up
- What did you decide not to do, and why?
- How did you know the outcome was caused by your change?
Choose between three requests with one analyst week
You have one analyst week and three open requests. Ranking wants an off-policy estimate of a candidate ranker, but log_propensity is NULL on 92 percent of home-feed impressions. Growth wants a week-1 retention read on a registration cohort whose day 7 to 13 window closes in four days. Integrity wants the audit sample re-sized because the prevalence interval cannot detect a 20 percent change. Give the order, what each requester gets and when, and the request you refuse outright with the reason.
Approach
- Sort by identification before sorting by importance. A request that cannot be answered correctly with any amount of effort is not competing for the week; it is competing for a different conversation.
- Rule out the off-policy estimate on positivity grounds and say it in one line: log_propensity NULL means serving was deterministic top-k, so the unserved slots had zero logging probability, and no inverse-propensity or doubly-robust estimator is identified there. The fix is a randomised exploration slot or an online test, which is a platform change and not an analyst task.
- Rule out the retention read on timing: days 7 to 13 must have closed for every member in the cohort. Reading it four days early truncates the window for the late-registering half of the cohort and biases the estimate by registration day, which correlates with acquisition channel.
- Do the integrity re-size, because it is tractable in hours and unblocks a standing measurement. At a two-sided alpha of 0.05 and 80 percent power, detecting a move from 0.50 percent to 0.40 percent needs roughly 70,000 labelled impressions per comparison period under simple random sampling, before any design effect from unequal weights. That number reframes the request: the honest deliverable may be a stratified design plus a longer comparison window, not a bigger weekly sample.
- Convert each refusal into a dated deliverable so the week does not end in three unhappy teams: ranking gets the exploration-slot design and the randomised fraction it needs; growth gets the date the cohort closes plus the activation rate on days 0 to 6, which is already readable and is a leading indicator of the number they want.
Follow-up
- Ranking says a biased estimate is better than none. Answer them in two sentences.
- How large an exploration fraction would you request, and what does it cost in served quality?
- If integrity cannot fund 70,000 labels a week, what do you offer instead?
- 01
Describe a time when you used statistical analysis to solve a problem.
- 02
Tell me about a time you had to work with a difficult team member.
- 03
You have one analyst week and three open requests. Ranking wants an off-policy estimate of a candidate ranker, but log_propensity is NULL on 92 percent of home-feed impressions. Growth wants a week-1 retention read on a registration cohort whose day 7 to 13 window closes in four days. Integrity wants the audit sample re-sized because the prevalence interval cannot detect a 20 percent change. Give the order, what each requester gets and when, and the request you refuse outright with the reason.
Is this an official Viber interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Viber. Rounds and questions reflect what candidates have reported, not a process Viber has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult is the interview process, and how much preparation time is typical?
The interview process can be challenging, particularly in the technical assessments. Candidates typically spend several weeks preparing to ensure they are well-versed in relevant skills and concepts.
PracHub interview research ↗What differentiates successful candidates?
Successful candidates demonstrate a strong balance of technical proficiency, problem-solving ability, and cultural fit. They effectively communicate their thought processes and showcase their adaptability.
PracHub interview research ↗What is the culture and working style like at Viber?
The culture at Viber promotes collaboration, innovation, and a user-first mindset. Teams work closely together, fostering an environment where diverse perspectives are valued.
PracHub interview research ↗What is the typical timeline from initial screen to offer?
Candidates can expect a timeline ranging from a few weeks to a couple of months, depending on the number of interview stages and team availability.
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