Zscaler · Data Scientist
Updated · 2026-09-22

Zscaler Data Scientist
Interview Questions & Guide 2026

THE 60-SECOND BRIEF

This guide prepares a Data Scientist candidate at Zscaler using original exercises built around B2B software and infrastructure data problems. PracHub assigns that framing to shape the practice; it is not a claim about Zscaler's business or its interviews.

Most of the loop measures decision-making under uncertainty rather than recall. You are scored on whether you state your assumptions, commit to an estimate you can defend, and say explicitly what evidence would change it.

These checkpoints are not equal in size, so do not give each one an equal evening. One may be a week of reps and another an afternoon of revision, and the split between them reflects how the skills divide rather than how anyone schedules a day.

Strip CI, retry and synthetic traffic firstMeasure churn only on renewal-eligible accountsSeparate contracted seats from actively used seats

45 min read

Practice 12 Data Scientist prompts
10Candidate experiences ↗Read their reports
12Practice promptsAcross five skill areas
3With worked solutionsIncluded in the practice prompts

Data science work in business software, infrastructure and developer tooling sits between a telemetry stream and a contract system, and most of the job is making those two agree. The unit of analysis is the account, not the person: an organisation signs, an organisation renews, and a hundred engineers inside it are correlated observations rather than a hundred independent ones. The recurring questions are narrow and concrete, covering which accounts will expand at renewal and which will contract, what a unit of usage costs to serve for a given account at its negotiated discount, whether a packaging change moved consumption or merely moved it between SKUs, and which accounts a capacity-limited customer-success team should contact this week. The deliverable is usually an account-level list with a threshold attached, handed to a team with finite capacity, so a ranking without an operating point is an unfinished piece of work. The audience is rarely another data scientist, so a definition also has to survive being repeated by someone who did not write it.

The skills that carry the most weight are, in order, SQL across mismatched grains with an explicitly defended denominator, cohort and survival thinking applied to contracts rather than to individuals, and experiment design that survives clustering and heavy tails. Concretely that means as-of joins against a versioned subscription table, randomisation at the account level with the design effect accounted for in the power calculation, pre-registered winsorisation or a capped metric when the outcome is revenue, and variance reduction using pre-period usage as a covariate. Unit economics matters more than in most domains because infrastructure cost is a real and allocable per-account quantity, so being able to say which accounts are unprofitable and why is a routine expectation. The last skill is unglamorous and decisive: when the product number and the finance number disagree, being able to say which one is right, by what definition, and what the reconciling difference is.

What makes the analysis hard here is the shape of the data rather than its volume. The account population is small by consumer standards, often a few thousand paying accounts, and revenue across it is extremely skewed, so the top fraction of a percent holds a large share of the total and any mean over accounts is effectively a statement about a handful of customers. Outcomes within an account are strongly correlated because colleagues share workspaces and influence each other, which both inflates apparent sample size and lets treatment leak between arms when randomisation is done at the user level. Contracts are annual, so churn is a rare, censored, calendar-driven event that most monthly metrics are structurally incapable of measuring. And the telemetry itself is largely machine-generated: a customer changing one line in a CI configuration can multiply request volume overnight without a single human deciding anything about the product.

01

Account-grain SQL against versioned contracts

editorial

Query usage, membership and contract tables together at the account grain without fanning out rows, and resolve every contract question as of a date rather than as of now. This is the substrate for nearly every other analysis in the domain, because the subscription table is versioned and the usage tables are not.

What to demonstrate

  • Writing an as-of join from a daily usage fact to fct_subscription_period, selecting the version whose term_start_date and term_end_date bracket the usage_date, rather than joining to is_current and silently backdating today's plan over last year's usage
  • Joining a one-row-per-account dimension to a many-row-per-account fact without multiplying revenue, including the case where dim_account is type 2 and contributes several versions in the window
  • Stating the denominator and its exclusions out loud before writing the SELECT, specifically is_internal accounts, non-production environments, service accounts and synthetic traffic classes
  • Recognising when a question needs a rollup from fct_api_request and when it must come from fct_usage_daily, and explaining why the two will not reconcile exactly

How to prepare

  • Write one query returning monthly net revenue, allocated COGS and gross margin per account, joined as-of to the contract version live during each month, and confirm the total ties to the sum of net_amount_cents
  • Practise the type 2 dimension pattern until it is automatic: filter to the version live at the event timestamp, never to is_current, and be able to say what breaks when you get it backwards
  • Build a query that separates interactive, CI, batch and synthetic traffic into columns for the same account and week, and look at how different the engagement story is under each filter
  • Rehearse explaining, in two sentences, why request counts from fct_api_request and billable quantities from fct_usage_daily diverge, including retries, failed requests and restatement
PracHub interview preparation framework
02

Retention, expansion and contract cohort arithmetic

editorial

Build net revenue retention, gross logo retention and expansion rate from a versioned contract table, and defend each denominator. This is the numerical language the domain uses to talk about itself, and small definitional errors here change the headline number by tens of points.

What to demonstrate

  • Constructing net revenue retention as a ratio of sums over a cohort frozen twelve months earlier, and explaining why the mean of per-account ratios gives a different and much noisier answer given that contraction is floored at zero while expansion is not
  • Restricting logo churn to the renewal-eligible base and articulating why a monthly rate on the whole base is off by roughly the reciprocal of the annual renewal fraction
  • Handling censoring properly when contracts have not yet reached their renewal date, including when a survival estimator is required instead of a simple rate
  • Separating booked_at from term_start_date and knowing which one belongs in a sales-effectiveness question and which in a revenue question

How to prepare

  • Compute net revenue retention two ways on the same data, ratio of sums and mean of ratios, and be ready to explain the gap from the shape of the expansion distribution
  • Derive from first principles how much a naive monthly churn rate understates the truth when all contracts are annual, and be able to do that arithmetic aloud
  • Work through the ways net revenue retention can rise while the business shrinks, and name the guardrail that catches each one
  • Build a renewal-eligible cohort for a given month from fct_subscription_period, including the 45-day grace for late paperwork, and sanity-check that roughly a twelfth of the base appears
PracHub interview preparation framework
03

Experimentation with clustered, skewed outcomes

editorial

Design and read out experiments where the randomisation unit is an account, the sample is a few thousand clusters at most, and the outcome of interest is revenue or consumption with an extreme right tail. Most standard experimentation instincts are calibrated on large-sample consumer data and mislead here.

What to demonstrate

  • Choosing the account as the randomisation unit and computing power with the design effect 1 + (m - 1) * rho, rather than quoting a user-level sample size
  • Recognising when the experiment is simply not powerable on revenue and proposing a proximate outcome, a longer horizon, or a switchback design for a platform-level change that cannot be randomised across accounts at all
  • Applying variance reduction with a pre-period covariate, for example CUPED using the account's prior consumption, and stating the approximate variance reduction as one minus the squared correlation
  • Pre-registering the winsorisation or capping rule and being explicit that it changes the estimand rather than pretending it is a neutral cleaning step

How to prepare

  • Run a power calculation for an account-randomised test on consumption, with and without the design effect, and note how much longer the clustered version has to run
  • Practise the diagnostic for a heavy tail: plot the running sample variance against sample size and say what it means when it does not stabilise
  • Prepare one clear explanation of interference inside a shared workspace and how it biases a user-level estimate toward zero
  • Have a switchback or stepped-wedge design ready for an infrastructure change that is global by nature, including how you would handle carryover between periods
PracHub interview preparation framework
04

Usage telemetry hygiene and unit economics

editorial

Turn raw machine-generated traffic into a defensible measure of human value, and attach cost to it. The gap between what the platform serves and what a customer values is wider in this domain than almost anywhere else, and allocating infrastructure cost to an account is a routine expectation rather than a finance task.

What to demonstrate

  • Systematically excluding internal accounts, non-production environments, synthetic monitors, load tests, service-account traffic and retried requests, and being able to quantify how much each exclusion removes
  • Computing gross margin at the account level from net_amount_cents and cogs_cents, and identifying structurally margin-negative accounts rather than reporting a blended rate that conceals them
  • Establishing the metering settling time empirically from first_written_at against restated_at, and excluding an appropriate trailing window from every reported figure
  • Explaining how a rising error rate can inflate metered volume through client retries, and designing a metric that does not reward that

How to prepare

  • Take one week of request-level data and produce the same engagement number under four progressively stricter traffic filters, then be ready to argue for one of them
  • Build the per-account margin distribution and answer, with a number, what share of revenue sits in margin-negative accounts
  • Measure how much a given usage_date's total shifts between first write and settlement, and set a lag window from that measurement rather than from convention
  • Write down the specific mechanism by which a platform outage can increase billable units, and the guardrail metric that would expose it
PracHub interview preparation framework
05

Renewal-risk and expansion scoring with an operating point

editorial

Build an account-level model that ranks renewal risk or expansion opportunity, with leakage-free features and a threshold tied to the capacity of the team that will act on it. The output is a worklist, so ranking quality at the top matters far more than calibration across the whole distribution.

What to demonstrate

  • Constructing features strictly from data available before the prediction point, and spotting the leakage that comes from features updated retroactively, such as a churn reason code, a downgrade amendment or a support ticket opened after the renewal conversation began
  • Choosing an evaluation metric that matches how the list is used, meaning precision or recall at the k the team can actually work, not a global AUC over thousands of accounts most of which will never be contacted
  • Handling class imbalance and small positive counts honestly, since annual contracts produce few churn events per period, and knowing when the honest answer is that there is not enough signal to model
  • Turning the score into a decision by attaching a threshold to the expected value of an intervention and the capacity constraint, and stating what happens to accounts below the line

How to prepare

  • Build a leakage audit habit: for every feature, name the timestamp that guarantees it existed before the prediction date, and drop anything you cannot date
  • Practise reporting precision at k for several plausible team capacities instead of a single headline number
  • Prepare an argument for why a simple, inspectable model that a customer-success team will actually trust can outperform a stronger model they ignore
  • Work out how you would evaluate whether the intervention itself worked, given that assignment of coverage is not random, and name the design you would ask for
PracHub interview preparation framework

10 candidate reports. Individual accounts describe a particular role and hiring cycle.

Software Engineer

Zscaler Software Engineer interview: online assessment, group discussion, and two interviews

Online Assessment → Other

My process at Zscaler followed a pretty standard structure. It started with an Online Assessment covering aptitude, coding, and communication. After that, I went through a Group Discussion round, followed by two interview rounds focused on knowledge, problem-solving, and teamwork. The overall difficulty felt about average. Even with the group setting, the process stayed straightforward. The inter…

Read full experience
Software Engineer

Zscaler Software Engineer interview: DSA, OOPs, DBMS, and C++

Technical Screen → Other

My process was compact. I had one technical interview followed by a project round. The technical discussion included an hour of general discussion and then two DSA questions. We also covered basic OOPs, database management system topics, and C++ fundamentals. The overall level felt easy, and the structure didn't overwhelm me with too many moving parts. I still didn't receive an offer. My lingerin…

Read full experience
Software Engineer

Zscaler Software Engineer interview after an 8-month job hunt

Outcome: offer

I came out of an 8-month job hunt, and once things started moving at Zscaler, they moved quickly. I had been working at Oracle as an SMTS (IC3) until I was laid off in September 2025. My application timeline ran roughly from November 2025 to May 2026. My path to the offer involved both outreach and applications. I used referral support and applied directly through the company's portal. I stayed i…

Read full experience
Software Engineer

Zscaler Software Engineer interview with a 75-minute DSA round

Online Assessment → Technical Screen → Other

After an online assessment, I went through pre-interview sessions about Zscaler's journey and the interview process. They helped me understand what the company was looking for and what the next steps would feel like. The technical interview lasted about 75 minutes and focused mainly on medium-level DSA and problem-solving. The interviewer was genuinely friendly, which helped me think more clearly…

Read full experience
Account Executive

Zscaler Account Executive objection-handling role plays

HR Screen → Other

The process started with a recruiter screen, followed by a round with two interviewers at the same time. That middle stage was more hands-on. I had to work through an objection-handling role play, which forced me to focus on responding in the moment instead of polishing a perfect story. After that, I had another round with senior leadership and a new role-play scenario. The interviews focused on…

Read full experience

PracHub editorial advice for the preparation topics above.

01

Computing monthly churn against the entire customer base when contracts are annual

An annual contract has no opportunity to churn except at its renewal date, so an account that is eleven months from renewal is in the denominator while being incapable of appearing in the numerator. The resulting rate is smaller than the real one by roughly the ratio of the base to the renewal-eligible base, and it oscillates with the seasonality of when deals were originally signed rather than with anything about the customers. The corresponding trap on the other side is counting a churn on the date the record was updated rather than on term_end_date, which shifts losses into whichever month the operations team did its paperwork.

02

Randomising an experiment at the user level when users share an account

Two problems fire at once. Colleagues in one workspace see each other's work and talk to each other, so a treated user changes the behaviour of a control user in the same account, which violates the no-interference assumption and biases the estimate toward zero. Separately, outcomes within an account are strongly correlated, so the effective sample size is roughly n / (1 + (m - 1) * rho) for m users per account and intra-class correlation rho, not n. With rho around 0.3 and twenty users per account that is a design effect near 6.7, meaning a user-level confidence interval is about two and a half times narrower than it should be and results cross significance thresholds on noise alone. Randomise the account and cluster the standard errors.

03

Interpreting a change before checking data quality and logging

Spend the first pass on row volume by day, null rates, duplicate keys, and whether the step change lands on a release or tracking-migration date. A discontinuity that coincides with a deploy is an instrumentation hypothesis before it is a behavioural one.

04

Comparing periods without accounting for seasonality or day-of-week

Compare whole weeks against whole weeks and check whether the same swing appeared in prior cycles or prior years before attributing it to anything you changed. Weekday and weekend populations often differ enough that a Tuesday-to-Saturday comparison is meaningless.

Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.

9 technical prompts3 include a worked solution

Audit daily usage rows for grain and arithmetic violations

easy
data-qualitypandasgrain

You are handed fct_usage_daily as a pandas DataFrame with account_id, workspace_id, sku_code, usage_date, billable_quantity, included_quantity_applied, overage_quantity, list_amount_cents, discount_amount_cents, net_amount_cents, cogs_cents, is_restated, first_written_at and restated_at. The declared grain is one row per (account_id, workspace_id, sku_code, usage_date). Write audit(df) returning a DataFrame with one row per failing check: check name, failing row count, and one example key. Cover at minimum grain duplication, negative quantities or amounts, the identity net = list - discount, billable = included + overage, and rows where is_restated is true but restated_at is null.

Approach
  1. Check the grain before anything else with df.duplicated(subset=key, keep=False), and count rows rather than groups so a key appearing twice contributes 2 — if the grain is broken every arithmetic count below it is uninterpretable.
  2. Express each invariant as a boolean Series over the whole frame. The cent columns are integers and compare exactly, so use !=; the numeric(18,6) quantity columns need np.isclose with atol=1e-6 because included + overage is a decimal sum.
  3. Handle null as its own failure mode. Comparisons against NaN return False, so a check written as rows_that_pass = (a == b - c) silently files every null-amount row wherever the negation happens to land; build each check as violations = ~condition | column.isna().
  4. Collect the checks as a list of (name, mask) pairs and assemble the output in one pass, so adding a check is one line and every check reports in the same shape.
  5. Order the output with structural failures (grain, null keys) above arithmetic failures, and report zero-count checks too — a check that silently disappears when it passes is indistinguishable from a check that was never run.
Follow-up
  • Which of these should block a dashboard refresh and which should only warn?
  • Rows with is_restated = true legitimately change value after first write. How do you make yesterday's audit result reproducible?
  • How would you extend this to catch a partition that is missing entirely rather than wrong?

Simulate how the renewal calendar distorts monthly churn rates

medium
simulationchurnnumpycohorts

Simulate 1,200 accounts on annual contracts. Draw each account's renewal month from a deliberately lumpy calendar: 30% renew in January and the remaining 70% are spread evenly over the other eleven months. At each renewal an account churns with probability 0.18, independent of month; survivors renew and come back twelve months later. Run 24 simulated months. For each month compute two rates: churned accounts over all live accounts, and churned accounts over accounts whose term ended that month. Report the mean and the month-to-month standard deviation of each series, and state which one belongs in an executive summary.

Approach
  1. Build the panel with numpy state arrays rather than a per-account loop: a next_renewal_month vector, an alive boolean vector, and a loop over the 24 months only. Looping over 24 months is fine; looping over 1,200 accounts inside it is what makes the simulation too slow to iterate on.
  2. Maintain the live set honestly. An account that churned in month m must leave the denominator from m+1 onward and can never be renewal-eligible again; if it stays, the naive rate drifts downward for reasons that have nothing to do with churn and the calendar effect gets buried.
  3. Compute both series over the same months and compare dispersion, not only level. The eligible-base rate should sit near 0.18 with binomial noise scaled by that month's renewal count; the naive rate spikes in January and collapses in thin months.
  4. Quantify the gap instead of describing it: the ratio of the two means is roughly the reciprocal of the average monthly renewal-eligible fraction, and the naive series' standard deviation is driven by the signing calendar rather than by customer behaviour.
  5. Check against the closed form before trusting the output. With the live set maintained correctly the eligible-base rate is an unbiased estimator of 0.18 in every month, so a systematic offset means the bookkeeping is wrong, not that the simulation found something.
Follow-up
  • Compounded over twelve months the naive rate lands close to the true annual churn. Does that rescue it?
  • How would you report churn in a month where only nine accounts were renewal-eligible?
  • Eighteen-month terms are now being sold alongside annual ones. What breaks?

Bootstrap a confidence interval for net revenue retention

mediumWorked solution
bootstrapretentionresampling

You have one row per account with arr_start_cents (ARR twelve months ago) and arr_end_cents (ARR today, zero if churned), covering the fixed cohort of accounts that had ARR twelve months ago. Net revenue retention is sum(arr_end_cents) / sum(arr_start_cents). Write a nonparametric bootstrap from scratch, without scipy.stats.bootstrap: resample accounts with replacement, recompute the ratio of sums on each resample, and return the point estimate with a 95% percentile interval from 10,000 resamples. Also report the interval you would get from the mean of per-account ratios, and explain the difference.

Approach
  1. Resample the account, because the account is the unit the estimand is defined over. One bootstrap draw is a vector of account indices and both numerator and denominator are recomputed from that same draw; resampling the two sides independently destroys the within-account correlation that makes a ratio estimator stable.
  2. Vectorise the draws: idx = rng.integers(0, n, size=(B, n)), then end[idx].sum(axis=1) / start[idx].sum(axis=1). A 10,000 by n index matrix is usually far cheaper than a Python loop; if the matrix is too large for memory, chunk over B rather than reverting to a loop.
  3. Take the interval from np.quantile(ratios, [0.025, 0.975]). The percentile interval differs from estimate +/- 1.96 * bootstrap SE whenever the resample distribution is skewed, which it will be here, and the skew is the thing you want represented.
  4. Compute the mean-of-ratios version on the same resamples, and state the exact relationship rather than guessing which of the two is larger. With r_i = arr_end_i / arr_start_i, the ratio of sums is the arr_start-weighted mean of exactly those r_i, so sum(end)/sum(start) - mean(r) = Cov(arr_start, r) / mean(arr_start) using the population covariance. The gap is positive when larger accounts retain and expand better than smaller ones, and negative when they do not; a cohort whose small accounts churn at a higher rate has positive covariance, which puts the mean of per-account ratios BELOW the ratio of sums. Requires arr_start_i > 0 for every account, which the fixed-cohort definition guarantees; r_i is floored at 0 and unbounded above, so a handful of 4x expansions among small accounts can flip the sign. Compute the covariance and report it instead of asserting a direction.
  5. Report the interval width beside the concentration of the cohort. If the largest account is 12% of starting ARR, a narrow interval is evidence that the resampling unit is wrong rather than evidence that the estimate is precise.
Worked solution 30 min
  1. start = df.arr_start_cents.to_numpy(float); end = df.arr_end_cents.to_numpy(float); n = len(start); point = end.sum() / start.sum()
  2. rng = np.random.default_rng(7); idx = rng.integers(0, n, size=(10_000, n)); ratios = end[idx].sum(1) / start[idx].sum(1)
  3. lo, hi = np.quantile(ratios, [0.025, 0.975]); return point, lo, hi
  4. per_acct = end / start; mean_point = per_acct.mean(); mean_boot = per_acct[idx].mean(1); compare np.quantile(mean_boot, [0.025, 0.975]) against (lo, hi), and report np.cov(start, per_acct, ddof=0)[0,1] / start.mean() as the quantity that accounts for the gap between the two centres.
EXPECTED RESULTA point estimate equal to sum(end)/sum(start) on the unresampled data — the bootstrap mean is close but must not be substituted for it — and a percentile interval that is asymmetric around the point when expansion is skewed. The mean-of-ratios interval is centred on a different estimand, and which side it falls on is decided by Cov(arr_start, r): it sits below the ratio of sums in the common case where small accounts churn at a higher rate than large ones, and above it when the large accounts are the ones shrinking. Its width is governed by the spread of per-account growth, while the ratio-of-sums width is governed by how concentrated starting ARR is, so neither interval is reliably the wider one.
Follow-up
  • The cohort has 800 accounts and the largest is 12% of starting ARR. How much do you trust a percentile interval here?
  • How would you extend this to an interval on the year-over-year change in NRR?
  • Two accounts merged mid-window and one contract was co-termed into the other. How do you keep the cohort fixed?

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.

Small steps. Visible outcomes.0 / 7 completed
ONE WEEK · YOUR PACE

Prepare, practise & reflect

One practical outcome each day. Spend longer where you need it.

0 / 7 done
01Diagnostic, 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 ↗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 ↗
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 ↗Worked solution ↗
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 ↗
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 ↗Worked solution ↗
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 ↗
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 ↗Worked solution ↗

Expand any day for tasks and deliverables. Your progress is saved on this device.

Half of this section is about translation. Be ready to describe how you explained a result to someone who did not want the method, only the implication, and what you did when the simplified version started being repeated in a way that overstated it. Correcting your own simplification is a strong beat.

Announce a metric fix that cuts the headline number

medium
metric definitionsstakeholderscommunication

Weekly active organisations, the count on the company dashboard, has never excluded rows where dim_account.is_internal is true, and it counts traffic with traffic_class in synthetic_monitor and load_test. Correcting both reduces that count by 11 percent and removes most of the growth reported over two quarters. The figure appears in a board deck and in two teams' quarterly goals, one written on the count and one on the weekly active organisation ratio, whose denominator is accounts whose account_status was in ('trial','free','active_paid') through the week. Decide the order in which you tell people, what the dashboard shows during the transition, and what you propose happens to goals already set against the old definition.

Approach
  1. The interviewer is probing whether you can land a correction as an operational change with a plan attached, rather than as an announcement other people then have to clean up after.
  2. Quantify each exclusion separately before telling anyone: internal accounts, synthetic monitors, load tests. Three known quantities are a discussion; one alarming total is an argument.
  3. Be precise about which side of the metric each exclusion touches, because one team's goal is on a count and the other's is on a ratio. The traffic-class filters remove requests, so they shrink the numerator only. Dropping internal accounts removes them from the ratio's denominator as well, since internal accounts carry ordinary account_status values and therefore sit in that denominator. Internal accounts are active in almost every week while the real base is not, so the numerator loses a larger share than the denominator and the ratio falls by less than the count does. Compute both and say which one the 11 percent is before anybody assumes.
  4. Check whether the trend changes, not only the level. A constant 11 percent shift is a rebasing and nothing more. A shift that widens over time means the reported growth was partly internal or synthetic, which makes the existing goals unachievable as written and changes what you are asking teams to do.
  5. Sequence the disclosure: the metric owner and the two teams whose goals move first and privately, then the board channel with a written bridge, then the dashboard. The dashboard is last because a number that changes without explanation is read as instability rather than as a fix.
  6. Run both series for one reporting period with the bridge visible, restate history rather than letting the series break at a date, and set the date the old series is removed.
  7. Propose the goal treatment yourself: rebase each target by the shift measured on the metric that target is written against, rather than leaving each team to negotiate individually, which is where corrections of this kind usually die.
Follow-up
  • One team's quarterly goal is now unreachable. Rebase the target or let it miss, and what does each choice teach the organisation?
  • How would this have been caught when the metric was first defined?
  • What else on that dashboard shares this failure mode, and how would you find out this week?

Walk through an analysis you later discovered was wrong

easy
data qualityerror ownershipmetering

Six weeks ago you reported that consumption fell 9 percent in the last week of the month, and a team spent a sprint investigating the cause. The fall was an artefact: rows in fct_usage_daily land late and are restated in place, and you queried before the tail had settled. Describe how you found the error, what you told the people who acted on it, and the control you put in place so this class of mistake cannot reach a dashboard again. Be specific about how the settling window was measured.

Approach
  1. The interviewer is probing whether you self-report errors before someone else finds them, and whether your fix is structural rather than a promise to be more careful. Say plainly that the number was wrong and that a sprint was spent on it, before describing any diagnosis.
  2. Establish the artefact quantitatively instead of asserting that data lands late. For each usage_date, compare the total as of first_written_at against the settled total and read the settling time off that curve, for example 97 percent of final by day three and 99.5 percent by day five.
  3. Correct the record the same day, in the channel the original number went out in, to the same audience. The cost of the wasted sprint belongs in the correction, not in a footnote.
  4. Make the fix structural: exclude a trailing lag window from every reportable figure, and make the reporting view return no rows inside that window rather than returning partial ones. A dashboard that shades unsettled days still gets read as a decline.
  5. State what generalises. Any fact table restated in place has this failure mode, so the guard belongs at the source rather than on the one dashboard that embarrassed you. A strong answer ends with the class of error closed; a generic one ends with a lesson learned.
Follow-up
  • How did you choose the completeness threshold behind the lag window, and what would make you recalibrate it?
  • What did you say to the team that lost the sprint, and what did they say back?
  • Is there a legitimate case for showing the unsettled tail at all, and to whom?

Scope an open-ended request to predict account churn

medium
scopingchurn modellingoperating point

A customer success director asks for a list of accounts about to churn. You know only that the team has six people and that contracts are annual. Available data is fct_subscription_period, fct_usage_daily, fct_api_request, fct_support_ticket and dim_account. Before writing any code, produce the questions you need answered, a proposed definition of about to churn, and the shape of the artefact you would hand back, including the operating point that turns a score into a decision.

Approach
  1. The interviewer is probing whether you convert a vague request into a decision with a capacity constraint attached. A candidate who starts talking about model families has already failed the exercise.
  2. Pin the event and the horizon first. Churn is only possible at term_end_date, so the population is accounts renewing in the next 60 to 90 days, not the whole base. Ask explicitly whether contraction and downgrade count as churn or only full non-renewal, because the three have different base rates and different interventions.
  3. Pin the action and the capacity. Six people times a realistic number of meaningful interventions per week gives k, and k is what the list is ranked to. Evaluate on precision at k rather than a global AUC over accounts that will never be contacted.
  4. Audit leakage before choosing features. Every feature needs a timestamp proving it existed before the prediction date. A downgrade amendment, a churn reason code, and a ticket opened after the renewal conversation started are all leaks that will make the offline number look excellent and the live list useless.
  5. Ask for the counterfactual now rather than later. Coverage is assigned deliberately, so without a held-out slice agreed at the start the intervention can never be evaluated, and you will be asked for its impact in nine months regardless.
  6. Propose the smallest artefact that closes the loop: a weekly ranked list sized to capacity with two or three inspectable reasons per row, plus a stated policy for accounts below the line.
Follow-up
  • The director insists all accounts are in scope, not only those renewing soon. How do you answer without simply refusing?
  • Historical non-renewals number about 30 a year. At what point do you tell them a model is the wrong tool and a rules list is better?
  • Which candidate features would you drop purely because you cannot date them?
  • 01

    Weekly active organisations, the count on the company dashboard, has never excluded rows where dim_account.is_internal is true, and it counts traffic with traffic_class in synthetic_monitor and load_test. Correcting both reduces that count by 11 percent and removes most of the growth reported over two quarters. The figure appears in a board deck and in two teams' quarterly goals, one written on the count and one on the weekly active organisation ratio, whose denominator is accounts whose account_status was in ('trial','free','active_paid') through the week. Decide the order in which you tell people, what the dashboard shows during the transition, and what you propose happens to goals already set against the old definition.

  • 02

    Six weeks ago you reported that consumption fell 9 percent in the last week of the month, and a team spent a sprint investigating the cause. The fall was an artefact: rows in fct_usage_daily land late and are restated in place, and you queried before the tail had settled. Describe how you found the error, what you told the people who acted on it, and the control you put in place so this class of mistake cannot reach a dashboard again. Be specific about how the settling window was measured.

  • 03

    A customer success director asks for a list of accounts about to churn. You know only that the team has six people and that contracts are annual. Available data is fct_subscription_period, fct_usage_daily, fct_api_request, fct_support_ticket and dim_account. Before writing any code, produce the questions you need answered, a proposed definition of about to churn, and the shape of the artefact you would hand back, including the operating point that turns a score into a decision.

PracHub interview preparation framework
Are these confirmed Zscaler interview questions?

No. Every prompt here is an original PracHub practice exercise written for the Data Scientist role and for B2B software and infrastructure data problems. This guide does not claim to reproduce Zscaler's interview questions, rounds or hiring timeline. Confirm the actual format, team and scope with your recruiter.

PracHub Data Scientist practice
Python or SQL when both are allowed?

Use SQL for filtering, joining and aggregating rows. It is shorter and it shows you can work where the data lives. Move to Python when the task needs a statistical test, a simulation, iteration over model fits, or reshaping that SQL makes unreadable. State your choice and the reason in one sentence. Pulling an entire table into a dataframe to do a group-by is the move interviewers quietly note.

PracHub Data Scientist practice
Do I need deep learning for a product data scientist role?

Depth in experimentation, causal inference and metric design pays far more than neural network internals. Know enough to say when a learned model beats a heuristic, what overfitting looks like, and how you would evaluate a classifier and choose a threshold. If the posting names ranking, recommendations or forecasting, go one level deeper on that family. The job description is usually an honest signal about which half of the field is being tested.

PracHub Data Scientist practice
How do I explain a technical result to a non-technical interviewer?

Give the decision, then the number, then the uncertainty, then the mechanism, in that order, and stop early if they are satisfied. Translate jargon into its operational meaning: significance at five percent becomes "if there were truly no effect, we would see a result at least this large about one time in twenty." Practise by writing the one-sentence version first and expanding only when asked a follow-up.

PracHub Data Scientist practice
Sources & methodology 2 sources ↗

Official role evidence, timestamped platform data and clearly labeled preparation advice.