DEV Community: Feng Zhang

Secure Multitenant SaaS Architecture Explained — Tech Interview Concept (2026)

Feng Zhang — Wed, 02 Sep 2026 14:27:12 +0000

Multitenant SaaS design questions are easy to answer badly.

A weak answer says, "Add tenant_id everywhere and encrypt the database." A better answer explains where tenant isolation is enforced, how authorization works across each access path, how background jobs carry tenant context, and how you stop one customer from hurting another customer's availability.

This topic comes up often in system design interviews, especially for enterprise products with sensitive data. The original PracHub concept write-up on secure multitenant SaaS architecture frames it around legal workflows, where documents, matters, privileged communications, and audit trails all raise the bar.

Let's turn that into a practical interview-ready design.

What the interviewer is really testing

The interviewer wants to know if you can design a SaaS system where many customers share infrastructure without sharing:

Data
Permissions
Search results
Cached responses
Background jobs
Operational blast radius
Observability access

That last point matters more than many candidates expect. Multitenancy is not just a database problem. It touches authentication, authorization, queues, object storage, search indexes, logs, metrics, admin tools, and incident response.

A good answer should show that you understand tradeoffs. Shared infrastructure is cheaper and simpler early on. Dedicated infrastructure gives stronger isolation for large or regulated customers, but it adds migration, deployment, cost, and operations work.

Pick the tenancy model first

Most SaaS systems use one of three models:

Shared database, shared schema

Every tenant's data lives in the same tables. Tenant-owned tables include a tenant_id.

This is cost-effective and simpler to operate, but it depends on correct tenant scoping everywhere.

Shared database, separate schema

Each tenant has its own schema inside the same database.

This gives a stronger boundary than shared tables, but migrations and schema management become harder.

Separate database per tenant

Each tenant has its own database.

This improves isolation and noisy-neighbor control, but connection management, migrations, backups, and provisioning are more complex.

For most interview answers, start with shared services and a shared Postgres database with strong logical isolation. Then mention that large or regulated tenants can move to a dedicated database, bucket, or deployment tier.

That tradeoff sounds realistic. It avoids pretending every customer gets fully dedicated infrastructure from day one.

Tenant isolation must exist at multiple layers

Do not rely on one WHERE tenant_id = ? check and call it done.

A serious design applies tenant scoping across the system:

API authentication
Authorization middleware
Database predicates
Postgres row-level security
Object storage key prefixes
Signed URL generation
Search and vector index filters
Cache key prefixes
Queue routing
Worker pools
Audit logs
Admin tools
Observability permissions

For example, a document might be stored in S3 under:

tenant/{tenant_id}/matter/{matter_id}/doc/{doc_id}

That naming pattern helps, but naming alone is not security. Your service should authorize the request before it generates a signed URL. The signed URL should have a short TTL. Metadata should be checked before bytes are served.

Authentication and authorization are different

Authentication answers: "Who are you?"

Authorization answers: "What can you access?"

Enterprise SaaS often supports SAML or OIDC single sign-on. The system maps identity-provider groups into application roles. Session tokens or JWTs may contain claims such as:

{
  "sub": "user_123",
  "org_id": "tenant_456",
  "roles": ["admin"],
  "exp": 1760000000
}

Roles are useful, but roles alone are usually too coarse.

RBAC works for broad permissions like:

admin
member
viewer

Legal-style workflows often need ABAC too. Access may depend on:

tenant_id
matter_id
document_classification
jurisdiction
ethical_wall_group

A common pattern is to combine them. Roles grant capabilities. Attributes constrain which resources those capabilities apply to.

For example, a user may have permission to view documents, but only for matters they belong to, and only if the document is not blocked by an ethical wall.

Put authorization near every resource access

Route-level checks are not enough.

You need a common authorization API, something like:

authorize(actor, action, resource)

That call should happen before sensitive resource access, whether the caller is:

A REST endpoint
A GraphQL resolver
A background worker
A CSV export job
A search endpoint
A document preview service
An admin impersonation tool

Policy can live in application code or a system like Open Policy Agent. The key idea is consistency. Every path that reads or writes tenant data needs a policy decision.

This is where many designs fail. The main API may be scoped correctly, while a batch export, preview endpoint, webhook retry, or support tool bypasses the same checks.

Design the database so unsafe queries are harder to write

In a shared-schema model, every tenant-owned table should include tenant_id.

Example tables:

documents (
  tenant_id,
  matter_id,
  document_id,
  title,
  created_at
)

matters (
  tenant_id,
  matter_id,
  name,
  created_at
)

Indexes should match tenant-scoped access patterns:

CREATE INDEX documents_tenant_matter_created_idx
ON documents (tenant_id, matter_id, created_at);

Business identifiers should usually be unique within a tenant, not globally:

UNIQUE (tenant_id, external_id)

Postgres row-level security can backstop application mistakes:

tenant_id = current_setting('app.tenant_id')

RLS is not a replacement for clean application design, but it can reduce the damage from an unscoped query.

Treat search and vector retrieval as high-risk paths

Search is a common leak point.

If you use OpenSearch, Elasticsearch, pgvector, or a vector database, every query must include tenant and permission filters before results are returned.

For sensitive documents, retrieval should filter by:

tenant_id
matter_id
User-accessible document IDs

Do not fetch the top-k chunks globally and then filter afterward. That can leak through ranking, snippets, timing, logs, or accidental response fields. The permission boundary needs to be part of retrieval, not a cleanup step after retrieval.

Derived data needs the same treatment. OCR text, embeddings, summaries, previews, and cached snippets are still tenant data.

Background jobs need explicit tenant context

Asynchronous processing is another common source of bugs.

Suppose a user uploads a legal document. The system creates jobs for virus scanning, OCR, embedding generation, indexing, and preview creation.

Each job should carry tenant context explicitly:

{
  "tenant_id": "tenant_456",
  "matter_id": "matter_789",
  "document_id": "doc_123",
  "requested_by": "user_999"
}

The system should validate permissions when the job is enqueued and again when it runs. That second check matters because permissions can change while a job is waiting.

Derived artifacts should be written back into tenant-scoped stores. Queue names, routing keys, and worker pools may also be partitioned or rate-limited by tenant.

Encryption helps, but it does not fix bad authorization

Encryption belongs in the design:

TLS for data in transit
Storage encryption for data at rest
Optional per-tenant keys through AWS KMS, GCP KMS, or HashiCorp Vault

Per-tenant envelope encryption can support tenant-specific key rotation or deletion. It also adds latency, key-management paths, and new failure modes.

The interview mistake is to over-index on encryption. Encryption protects against storage compromise. It does not stop an authenticated user from reading the wrong matter if authorization is broken.

Access-control correctness is the bigger application-layer risk.

Audit logs should answer who did what

Enterprise systems need audit trails for security and compliance.

Log events such as:

Login
SSO group sync
Permission changes
Document upload
Document download
Search
Export
Admin impersonation
Failed authorization

A useful audit event includes:

{
  "actor_id": "user_999",
  "tenant_id": "tenant_456",
  "resource_id": "doc_123",
  "action": "document.download",
  "decision": "allowed",
  "ip": "203.0.113.10",
  "user_agent": "Mozilla/5.0",
  "timestamp": "2026-01-15T12:00:00Z"
}

The audit log should avoid document contents, prompts, secrets, and access tokens.

There is also a design tradeoff. Synchronous audit writes give stronger confidence but add latency and failure coupling. Asynchronous audit writes improve availability but need durable queues and retries. A strong answer proposes a hybrid: block on authorization, emit audit events to a durable append-only stream, and monitor for delayed or missing audit records.

Protect tenants from noisy neighbors

Security includes availability.

One tenant's large import should not exhaust all background workers or saturate shared database IOPS for everyone else.

Use:

Per-tenant rate limits
Quotas
Queue partitioning
Worker-pool isolation
Query timeouts
Resource monitoring by tenant

This is where shared infrastructure needs careful guardrails. Tenant isolation includes performance failure boundaries, not just data leakage.

A strong interview answer structure

If asked to design a secure multitenant document management system, structure the answer like this:

Clarify requirements

Ask whether tenants are companies or law firms, whether users can belong to multiple tenants, whether documents are scoped to matters, and whether the system needs SSO, audit logs, data residency, or dedicated infrastructure.

State assumptions

Use shared application services, shared Postgres for metadata, object storage for files, and strict logical isolation by tenant_id and matter_id.

Cover identity and access

Use OIDC or SAML, map groups to roles, combine RBAC and ABAC, and call authorize(actor, action, resource) across all access paths.

Cover data isolation

Put tenant_id on tenant-owned tables, use scoped indexes, enable RLS on sensitive tables, namespace object keys, and generate signed URLs only after authorization.

Cover operations

Add audit logs, per-tenant rate limits, encrypted storage, key management, queue partitioning, and guardrails for admin access.

Call out tradeoffs

Shared database is simpler and cheaper for most tenants. Dedicated databases or buckets may be needed for large or regulated customers.

If you want more interview prompts around this style of system design, PracHub has a broader set of technical interview questions that pair well with this topic.

Common mistakes to avoid

The biggest mistake is treating tenant_id like a UI filter. It is a security boundary.

Another mistake is checking authorization only at the route layer. Secondary paths often cause leaks: exports, previews, search snippets, OCR jobs, embeddings, cached responses, webhook retries, and support tooling.

A third mistake is using encryption as a substitute for authorization. You need both, but they solve different problems.

If you can explain those risks clearly, your answer will sound much closer to production engineering than checklist security. For a compact version of the concept, use the PracHub guide to secure multitenant SaaS architecture as a review sheet before practicing the full system design.

LinkedIn Data Scientist Interview Cheatsheet 2026

Feng Zhang — Wed, 26 Aug 2026 14:26:39 +0000

LinkedIn data scientist interviews usually test whether you can move between product thinking, SQL/Python, experimentation, and machine learning judgment. The bar is less about memorizing obscure algorithms and more about taking an ambiguous business question, defining the metric, checking the data, and defending your read.

This is a rewrite of the PracHub LinkedIn Data Scientist interview prep cheatsheet, focused on the patterns you are likely to see in a 2026-style interview.

1. SQL and Python: get the grain right first

Most technical screens start with relational data manipulation. You may get event logs, job metadata, user tables, article categories, or country mappings, then be asked to compute a metric.

The interviewer is checking whether you can:

Join event logs to dimension tables
Filter on the right timestamp or action type
Deduplicate at the right grain
Aggregate without double-counting
Use window functions for ranking or top-k problems
Translate the same logic into pandas if needed

A practical checklist:

What is one row in each table?
What is the metric grain, user, job, country, post, session, or day?
Should missing metadata drop the row or stay as NULL?
Do repeated events count, or do we need uniqueness?
Is the date filter on the event, the entity, or the metadata?

For SQL joins, be explicit:

SELECT
  j.country,
  COUNT(DISTINCT a.member_id) AS unique_applicants,
  COUNT(*) AS total_applications
FROM applications a
JOIN jobs j
  ON a.job_id = j.job_id
WHERE a.apply_date >= DATE '2026-01-01'
GROUP BY j.country;

If the prompt asks for the top country per continent, use ROW_NUMBER() when exactly one row should be returned:

WITH country_apps AS (
  SELECT
    continent,
    country,
    COUNT(*) AS applications
  FROM job_applications
  GROUP BY continent, country
),
ranked AS (
  SELECT
    *,
    ROW_NUMBER() OVER (
      PARTITION BY continent
      ORDER BY applications DESC, country ASC
    ) AS rn
  FROM country_apps
)
SELECT continent, country, applications
FROM ranked
WHERE rn = 1;

RANK() can return ties. That is fine only if the prompt allows multiple winners.

In pandas, most variants map to a small set of tools: merge, boolean filters, groupby().agg(), nunique(), drop_duplicates(), rank(method="first"), and value_counts().

The common failure mode is aggregating after a many-to-many join without checking row explosion. If a job has multiple categories and a user has multiple views, joining first can inflate counts unless you dedupe at the metric grain.

2. Sampling algorithms: correctness beats cleverness

LinkedIn data scientist interviews can include randomized sampling questions. These are coding problems, but the evaluation is about bias, efficiency, and whether the sample supports valid modeling or metrics later.

Know these patterns:

Reservoir sampling

Use this when the stream length is unknown and you need a uniform sample of size k.

Conceptually:

Keep the first k items
For the ith item after that, draw a random integer from 0 to i
If the index is less than k, replace that slot

Each item should end with probability k / n of being included.

Weighted sampling

For a weighted die or weighted category draw:

Build cumulative weights
Draw u uniformly from [0, total_weight)
Use binary search to find the bucket

This avoids expanding a list by weight, which breaks for large or non-integer weights.

For repeated weighted draws, know the alias method at a high level: preprocess probabilities into tables, then sample in constant time after setup.

Stratified sampling

For imbalanced labels, sample within each class or segment. Then reweight metrics or losses using production prevalence. The trap is treating an oversampled training set as if it mirrors production.

For imbalanced model evaluation, accuracy is often weak. Be ready to discuss PR-AUC, recall@k, calibration, and cost-weighted loss.

3. Job application funnel cases

A common LinkedIn onsite case is: "Applications dropped. Diagnose why."

Do not jump to one explanation. Start by defining the metric:

Total submitted applications?
Unique applicants?
Applications per active job seeker?
Qualified applications?
A specific geography, platform, or time period?

Then decompose the funnel:

job_impressions
→ job_clicks
→ apply_starts
→ apply_submits
→ recruiter_responses

Track both counts and conditional rates:

CTR = job_clicks / job_impressions
apply_start_rate = apply_starts / job_clicks
submit_rate = apply_submits / apply_starts

A useful identity is:

applications =
active_job_seekers
× jobs_seen_per_seeker
× view_rate
× apply_start_rate
× submit_rate

This keeps your answer grounded. A drop in total applications could come from fewer active seekers, fewer jobs shown, ranking changes, UX friction, expired job supply, logging changes, or seasonality.

Segment with a hypothesis, not a giant list. Strong cuts for LinkedIn-style jobs cases include:

Country
Device
Job function
Seniority
Industry
New versus returning job seekers
Paid versus organic jobs
Remote versus onsite roles
Recommended versus search traffic

Cohorts matter too. Compare members active before the decline, newly active job seekers, and jobs posted in the same week. If only new cohorts are worse, onboarding, acquisition source, or fresh job supply may be the issue.

Seasonality is a real confounder for hiring metrics. Compare year-over-year, same weekday, holiday-adjusted trends, and country-specific recruiting cycles.

A good answer also checks instrumentation. Did apply_submit logging change? Are external apply redirects missing? Are duplicates being counted differently?

The quality tradeoff matters. More applications are not automatically better. If a recommender drives low-fit applications, recruiters may respond less and members may lose trust. Include downstream metrics like qualified applications, recruiter saves, messages, interviews, or negative feedback.

4. Evaluating a jobs recommender

A related prompt is: "How would you evaluate Jobs You May Be Interested In?"

Start with the outcome. The recommender should create value for members and employers. Online metrics might include:

Job clicks per member
Apply starts per member
Apply submits per member
Qualified applications
Recruiter response rate

Offline ranking metrics can include precision@k, recall@k, NDCG, and calibration by job category.

The main trap is optimizing clicks. A model can increase clicks by surfacing broadly appealing jobs while reducing completed applications if those jobs are poor fits. Tie recommender evaluation back to the funnel and guard against marketplace harm.

5. Product metrics and diagnostic analytics

LinkedIn product cases often ask you to define success for a feed, profile, video, or B2B product. The interviewer wants to see whether you can build a metric framework and diagnose movement without relying on anecdotes.

A useful structure:

Define the product goal
Choose a primary metric
Add guardrails
Build a metric tree
Validate instrumentation
Segment based on plausible mechanisms
Pick an experiment or causal design

For a homepage feed, a metric tree might break engagement into:

eligible users
× visit rate
× feed impressions per session
× engagement rate
× downstream quality

Guardrails might include hides, spam reports, connection removals, latency, and creator concentration. A single engagement metric can be gamed by low-quality viral content, so quality checks are part of the answer.

For profile completion, define the funnel precisely:

viewed prompt
→ clicked edit
→ added field
→ saved field
→ reached completion threshold

Use the right denominator. If the question is about prompt performance, use eligible exposed members. If the question is population impact, use the broader member base.

For B2B products, the unit of analysis may be account, seat, admin, or buyer. Average usage can hide that a few large accounts dominate totals, so inspect account-level adoption, seat activation, retention curves, and percentiles.

If you want targeted drills for these patterns, the PracHub interview questions library has practice prompts across SQL, product analytics, experimentation, ML, and coding.

6. Experimentation and causal reasoning

For A/B tests, name the randomization unit. Member-level randomization works for many feed or profile changes. Account-level randomization may be better for B2B products because users inside the same account can influence each other.

Use primary and guardrail metrics. Report effect size and confidence intervals, not just statistical significance. A tiny lift in clicks with a drop in submits is a bad trade if the goal is completed applications.

If randomized evidence is unavailable, frame the causal question carefully. For a ranking launch, compare exposed versus unexposed users, pre/post trends, holdouts if available, or similar unaffected surfaces. Difference-in-differences is often a clean framing:

effect =
(treated_post - treated_pre)
-
(control_post - control_pre)

Also watch for multiple comparisons during segmentation. If you inspect 100 segments, some will move by chance. Treat exploratory cuts as hypotheses that need validation.

Final prep advice

For LinkedIn data scientist interviews, your answer should usually sound like this:

"First, I'd clarify the metric and time window."
"Then I'd validate logging and denominator changes."
"Next, I'd decompose the metric into a funnel or metric tree."
"I'd segment based on plausible mechanisms and contribution to the total change."
"Then I'd use experiment logs, holdouts, or quasi-experimental comparisons to test the leading hypotheses."
"I'd include guardrails so we do not optimize short-term activity at the cost of long-term marketplace quality."

That structure works across SQL, funnel diagnosis, recommender evaluation, product metrics, and experimentation. For the full version with the original practice-card structure, use the PracHub LinkedIn Data Scientist interview prep cheatsheet.

Product Diagnostics And Root Cause Analysis Explained — Tech Interview Concept (2026)

Feng Zhang — Wed, 12 Aug 2026 14:28:02 +0000

Product diagnostics interview questions often sound simple:

"Ads revenue dropped 5%. How would you investigate?"

A weak answer turns into a checklist: check seasonality, segment by country, look at app version, maybe inspect experiments. A strong answer has an order. Clarify the metric, rule out measurement failure, break down the movement, find the biggest contributors, then decide what evidence would prove or disprove each cause.

This is a common Meta-style data science and product analytics interview pattern. PracHub covers this in more detail in its Product Diagnostics and Root Cause Analysis concept guide, but this post focuses on the interview version of the mental model.

What the interviewer is really testing

The interviewer wants to know if you can debug a product metric when the prompt is vague.

You need to separate a few possibilities:

A broken metric or logging pipeline
A real user behavior change
A business or marketplace change outside the product itself

They are not looking for a memorized list of slices. They want to see if you understand metric definitions, logging systems, experiments, user identity, funnels, and business mechanics like ads auctions or retention cohorts.

A good answer also separates speed from certainty. Some checks belong in the first hour. Some need a day of analysis. Some need a rollback, holdout, or quasi-experiment before you can call them causal.

Start with the metric definition

Before diagnosing anything, pin down what moved.

"Actives dropped 5%" is incomplete. You need to ask:

Is this DAU, WAU, sessions, logged-in users, device-level users, or a rolling 7-day active metric?
Is the 5% drop absolute or relative?
What is the comparison baseline?
Is it statistically meaningful compared with historical variance?
What is the grain: user, account, device, session, event, or cohort?
Is the metric computed from raw logs, curated tables, billing systems, or experiment dashboards?

Small definition changes can completely alter the diagnosis. A user-level active metric can fall while device-level activity stays flat if identity resolution changes. A rate can move because the denominator changed, even if the numerator is stable.

Rule out instrumentation before product theories

Do not start with "users dislike the new feature." First, check whether the data is trustworthy.

Look at:

Raw event volume
Null rates
Schema changes
Client-side versus server-side logging
ETL delays
Backfills
Bot filtering
Deduplication logic
Timezone boundaries
Event time versus ingestion time
App version or SDK logging changes

A useful pattern is to compare raw facts with derived aggregates. If raw logs look stable but a dashboard metric moved, the issue may be pipeline logic. If both raw events and aggregates moved together, a real product or user behavior change is more likely.

For SQL validation, start close to the source:

SELECT
  DATE_TRUNC('hour', event_time) AS hour,
  event_name,
  platform,
  app_version,
  country,
  COUNT(*) AS events,
  COUNT(DISTINCT user_id) AS users
FROM raw_events
WHERE event_time >= CURRENT_DATE - INTERVAL '3 days'
GROUP BY 1, 2, 3, 4, 5;

At very large scale, exact COUNT(DISTINCT) may be too expensive. Approximate sketches such as HyperLogLog can be acceptable when you need a directional answer quickly.

Decompose the metric

After basic data checks, break the metric into mechanical drivers.

For ads revenue, a simple decomposition is:

$$
\text{Revenue} =
\text{Users}
\times
\text{Sessions/User}
\times
\text{Ad Impressions/Session}
\times
\text{Fill Rate}
\times
\text{CPM}/1000
$$

Revenue can fall because fewer users visited, users had fewer sessions, ad opportunities dropped, fill rate fell, CPM dropped, advertiser budgets changed, or auction quality shifted.

For retention, the definition may be:

$$
D7 = P(\text{return on day 7} \mid \text{new user on day 0})
$$

That points you toward cohort entry, return event definition, delayed logging, acquisition mix, app quality, onboarding, and engagement.

This decomposition prevents random guessing. First identify which component drove the movement. Then investigate that component.

Segment by contribution, not just percent change

Segmentation matters, but many candidates do it poorly.

A tiny segment can drop 80% and explain almost none of the total decline. A huge segment can drop 2% and explain most of it.

For each segment, compute contribution:

$$
\frac{\Delta_i}{\Delta_{\text{total}}}
$$

or:

$$
\frac{\Delta_i}{\sum_i \Delta_i}
$$

Useful slices often include:

Country
Platform
App version
Product surface
Acquisition source
New versus returning users
Experiment group
Device class
Advertiser vertical or campaign objective, for ads
Cohort date, for retention

Watch for Simpson's paradox. Aggregate trends can reverse when mix shifts across countries, platforms, or user types.

Use the right time-series baseline

A metric drop only matters relative to a baseline.

Compare against:

Same day of week
Recent historical variance
Holidays
Product launch calendars
Market events
Country-specific events
Prior seasonal patterns

For anomaly detection, avoid treating every dashboard wiggle like an incident. Depending on the metric, you can use confidence intervals, binomial approximations for rates, bootstrap intervals for non-normal metrics, or control limits such as:

$$
\mu \pm 3\sigma
$$

At Meta-scale volume, tiny differences can be statistically significant while still being practically small. Interviewers like candidates who say this out loud.

Localize through the funnel

A product metric is often the output of a user journey. Break the journey into steps:

exposure -> click/open -> load -> action -> success

For actives or account switching, inspect:

Login success
Session creation
Identity resolution
Account merge or split behavior
Logout rates
Cross-device activity
Shared-device patterns

A rise in account switching could mean product friction, fraud, shared device usage, or a measurement reclassification. Localization tells you where to look next. It does not prove the root cause by itself.

Check launches, experiments, and external factors

Once you know what moved and where, compare the break point against known changes.

Internal causes may include:

Experiment ramps
Feature flags
App releases
Ranking model pushes
Ads auction changes
Policy changes
Outages
Notification or email sends
Logging SDK updates

External causes may include:

Holidays
Competitor launches
Macro ad demand shifts
OS changes
Carrier outages
Country-specific regulation

Experiments need special handling. If the drop is isolated to treatment, inspect ramp timing, guardrails, exposure logging, and heterogeneous treatment effects. If treatment and control drop at the same time, suspect external factors, shared infrastructure, or logging. In social products, interference can complicate interpretation because one user's treatment can affect another user's experience.

If you want more practice with these interview pivots, PracHub has related data science and product analytics interview questions.

Worked example: diagnosing an ads revenue drop

Suppose the prompt is:

"Total ads revenue dropped yesterday. How would you diagnose it?"

Start with clarifying questions:

How large is the drop?
When did it start?
Is it global or limited to a surface?
Is "revenue" booked revenue, estimated revenue, or logged auction revenue?
What baseline are we comparing against?

Then state your plan:

Verify measurement
Decompose revenue
Localize the biggest contributors
Compare against launches, incidents, and external signals
Validate the most likely causes

For measurement, compare ad impression logs, auction logs, billing records, ETL freshness, currency conversion, and schema changes.

For decomposition, check users, sessions per user, ad impressions per session, fill rate, bid density, CPM, click quality, conversion quality, and advertiser budget behavior.

For segmentation, inspect country, platform, placement, advertiser vertical, campaign objective, new versus returning users, app version, and auction type.

For validation, align the break point with product launches, ads ranking changes, policy enforcement, outages, and seasonality. If unaffected geos or placements exist, use them as controls.

If the revenue drop aligns exactly with a ramped ads ranking launch, you might recommend a rollback during incident triage. But you should still quantify contribution and guard against confounding from weekends, holidays, or macro ad demand.

Second example: low retention for a lightweight app

Retention diagnostics are different because the metric is cohort-based.

First define:

Retention window, such as D1, D7, or D28
Cohort entry event
Return event
Whether users are new installs, reactivations, or first successful logins

Then decompose the funnel:

install -> open -> signup/login -> feed load -> meaningful interaction -> return

For a lightweight Android app in emerging markets, useful segments include device RAM, OS version, network quality, app version, country, language, acquisition channel, crash rate, and cold-start latency.

Retention analysis also needs care with right-censoring and delayed events. Recent cohorts may appear to have poor D7 retention simply because day 7 has not fully arrived or logs arrived late. Acquisition mix can also distort retention if a campaign brings in lower-intent users.

A common product decision is whether to use D1 retention as an early signal or wait for D7 or D28 to avoid reacting to noise.

Common mistakes to avoid

The first mistake is jumping to a favorite cause before checking instrumentation. A better answer explicitly rules out logging, pipelines, denominators, and event delays before discussing user sentiment.

The second mistake is listing segments without priority. Do not dump "country, platform, age, gender, app version" as a flat list. Explain your ordering: verify the metric, find the component that moved, segment the largest contributor, then test hypotheses against known changes.

The third mistake is treating localization as causation. "The drop is mostly Android in India" is a finding, not a root cause. The next question is what changed for that segment: app release adoption, crash spikes, network latency, ranking rollout, carrier outage, ad demand shock, or logging SDK version.

A simple interview structure to remember

Use this sequence:

Define the metric precisely.
Check data quality and instrumentation.
Decompose the metric into drivers.
Segment by contribution.
Compare against time-series baselines.
Map the movement to funnel steps.
Check launches, incidents, experiments, and external events.
Use causal methods or rollbacks when correlation is not enough.

That structure keeps your answer practical. It shows speed, but it also shows that you know when fast diagnosis is not the same as proof.

For a fuller version of this framework, including Meta-style prompts and edge cases, read the PracHub guide on Product Diagnostics and Root Cause Analysis.

TikTok Data Scientist Interview Cheatsheet 2026

Feng Zhang — Wed, 05 Aug 2026 14:27:01 +0000

TikTok Data Scientist interviews usually test product sense, causal reasoning, SQL, experiment design, and statistics. The tricky part is that the prompts can sound basic: calculate retention, analyze a funnel, design an A/B test, explain a metric tradeoff. Strong answers go past the query or formula and explain what decision the analysis supports.

This guide adapts PracHub's TikTok Data Scientist interview prep cheatsheet into a standalone study plan for developer-community readers.

What the interview is really testing

A TikTok-style Data Scientist interview is rarely about memorizing definitions. You are being tested on whether you can reason from messy event data to a product decision.

Expect questions across these areas:

SQL and Python data manipulation
Cohort, retention, funnel, and product metrics
A/B testing and experiment design
Power, diagnostics, and inference under noisy data
Causal inference methods like matching and difference-in-differences
Recommendation, ads ranking, and marketplace objectives
Classification thresholds and imbalanced learning
Communication with product and engineering partners

The onsite rounds often combine several of these. A question about DAU and ad revenue, for example, is also a question about metric decomposition, segmentation, causal inference, and launch tradeoffs.

Cohorts, retention, funnels, and product metrics

For product analytics questions, start by defining the unit and denominator. Many weak answers fail before the SQL starts because they count the wrong thing.

A cohort groups users by a shared starting point, such as signup date, first app open, first post, first purchase, or first experiment exposure. Always clarify which one applies.

A common cohort key is:

DATE(MIN(event_ts)) AS cohort_date

partitioned by user_id, but the meaning depends on the product question.

For day-N retention, the basic definition is:

day-N retention =
users active on cohort_date + N / users in cohort

You still need to define "active." It could mean opening the app, watching a video, posting, liking, purchasing, or some other qualifying event.

Also separate exact retention from rolling retention:

Day-7 exact retention: user was active exactly on day 7
7-day rolling retention: user was active at least once from day 1 through day 7

These answer different questions. Exact retention is closer to a habit signal. Rolling retention captures less frequent usage.

Funnels have the same issue. A funnel such as:

video_view -> profile_visit -> follow

can be measured at the user level, session level, or item level. The conversion rate can change a lot based on that choice.

Temporal order matters. If you count unordered events, you will overstate conversion. Require each step to happen after the previous one, often with window functions such as:

ROW_NUMBER() OVER (
  PARTITION BY user_id, product_id
  ORDER BY event_ts
)

That lets you deduplicate repeated actions and enforce the sequence.

The DAU vs ad revenue question

A common interview prompt is some version of: "DAU increased, but ad revenue decreased. How would you analyze it?"

Do not jump straight to "optimize for growth" or "optimize for revenue." Break the metric apart.

A useful decomposition is:

Revenue =
DAU
x sessions per user
x impressions per session
x fill rate
x eCPM

Now you can ask better questions:

Did traffic grow, but from lower-monetizing regions?
Did sessions per user fall?
Did ad impressions per session decrease?
Did auction pricing change?
Did fill rate drop?
Did new users retain worse than existing users?
Did ad load changes affect watch time or churn?

A strong answer includes both objective metrics and guardrails. Objective metrics might include DAU, ad revenue, ARPDAU, retention, watch time, and ad impressions per user. Guardrails might include day-7 retention, session length, ad fatigue signals, and creator-side metrics if the feature affects posting supply.

Segmentation is part of the core answer, not an optional add-on. Break results down by geography, acquisition source, user maturity, device, content vertical, and engagement level. A flat average can hide a traffic mix shift.

Also watch for censoring. If today is May 23, users who joined on May 20 cannot have day-7 retention yet. Exclude immature cohorts or mark them incomplete. Do not treat missing future activity as churn.

A/B testing: design before math

For experimentation questions, do not start with "randomize users 50/50." Start with the causal question.

A good structure is:

Objective
Hypothesis
Unit of randomization
Eligibility and exposure
Primary metric
Guardrail metrics
Power and minimum detectable effect
Validity risks
Analysis plan
Decision rule

The unit of randomization is a design choice. User-level randomization works when one user's treatment does not affect another user's outcome. That assumption can break in recommendation systems, creator ecosystems, and ad auctions.

If treatment affects shared inventory, creator exposure, feed composition, or advertiser competition, consider cluster, geo, advertiser-level, or switchback designs.

Eligibility and exposure rules also matter. For a For You feed experiment, assigned users are not the same as exposed users. A user may be assigned to treatment but never open the app or never see the new ranking behavior. Define both assignment and treatment exposure.

Your metric hierarchy should match the decision:

Recommendation experiments: watch time per user, retention, sessions, like rate, hide rate, content diversity
Monetization experiments: revenue per user, RPM, cost per conversion, advertiser ROAS
Guardrails: report rate, crash rate, latency, not-interested rate, retention, creator concentration

Power should be discussed before launch. A common two-sample approximation is:

n ≈ 2σ²(z(1-α/2) + z(1-β))² / δ²

where δ is the minimum detectable effect. If you want to detect an effect half as large, you need roughly four times the sample size.

Ratio metrics need care. Metrics like cost per conversion or watch time per session have random denominators. Look at numerator and denominator separately, or use methods like the delta method or bootstrap.

CUPED can reduce variance by adjusting for pre-experiment behavior:

Y_adj = Y - θ(X - X_bar)
θ = Cov(Y, X) / Var(X)

This works best when pre-period behavior predicts post-period outcomes, such as historical watch time predicting future watch time.

Interference, seasonality, and sequential peeking

TikTok-style experiments often have interference. One user's treatment may change what content creators make, how inventory is allocated, or what untreated users see. If that risk is present, say so directly.

Cluster randomization can reduce contamination, but it lowers power. The effective sample size depends on intra-cluster correlation. A common design effect is:

DE = 1 + (m - 1)ρ

where m is average cluster size and ρ is intra-cluster correlation.

Seasonality also needs a real plan. Run treatment and control concurrently, cover full weekly cycles, and account for region, day of week, time zone, device, and traffic source when those affect the baseline.

Sequential monitoring is another common trap. If you check results every day and stop as soon as p < 0.05, your false positive rate is higher than 5%. Use a pre-planned monitoring rule, alpha spending, group sequential tests, or mark interim reads as exploratory.

Statistics that come up often

For binary outcomes like conversion, activation, or retention, the standard difference-in-proportions test is common:

SE = sqrt(
  pT(1 - pT) / nT +
  pC(1 - pC) / nC
)

Then compare:

(pT - pC) / SE

against a normal approximation.

For one-sample proportion tests, compare an observed rate against a benchmark. For example, if a campaign must exceed 60% conversion, test the observed conversion rate against p0 = 0.60.

With clustered randomization, do not pretend millions of events are millions of independent observations. The unit of analysis should line up with the unit of randomization. You may need cluster-level aggregation or cluster-robust standard errors. With too few clusters, be cautious and consider small-sample corrections or randomization inference.

How to answer in the interview

For metric questions, use this pattern:

Clarify the product setup.
Define the unit, denominator, and time window.
Write the metric logic.
Segment the result.
Check causality and bias.
Discuss decision and guardrails.

For experiment questions, use this pattern:

Define the hypothesis.
Choose the randomization unit.
Define eligibility and exposure.
Pick primary and guardrail metrics.
Plan power and duration.
Call out interference and seasonality.
State the analysis and launch rule.

If you want more targeted prompts, PracHub has a bank of data science interview practice questions that pairs well with this study plan.

Final prep advice

The best TikTok Data Scientist answers are precise. Define the metric before calculating it. Be explicit about correlation versus causation. Talk through tradeoffs without hand-waving. A statistically significant lift can still be a bad launch if guardrails move the wrong way.

For the full version of the cheatsheet, including the original topic map and interview framing, use PracHub's TikTok Data Scientist interview prep guide.

Multi-Tenant Isolation And Sandboxing Explained — Tech Interview Concept (2026)

Feng Zhang — Wed, 29 Jul 2026 14:26:55 +0000

Multi-tenant sandboxing questions are about boundaries. Can you run code, jobs, sessions, or agents for many customers on shared infrastructure without data leaks, secret exposure, or one tenant eating all the capacity?

That is the core idea behind the original PracHub note on multi-tenant isolation and sandboxing. In interviews, this topic usually shows up as a system design prompt:

Design a cloud IDE
Design a CI/CD runner
Design a multi-tenant workspace app
Design a sandbox for user-submitted code
Design a tool execution layer for AI agents

A weak answer says, "Add tenant_id everywhere." A strong answer explains which boundary protects against which risk.

Start with the threat model

Before picking Kubernetes, Firecracker, or VMs, say what you are defending against.

For a cloud IDE or CI/CD platform, assume user code is hostile. It may try to:

Read files from another tenant
Escape the filesystem sandbox
Abuse CPU or memory for crypto-mining
Steal credentials from environment variables
Call cloud metadata endpoints such as 169.254.169.254
Scan internal services
Poison a shared dependency cache
Exploit a kernel or container runtime bug

For a normal SaaS workspace app, the threat model is different. You may care more about authorization bugs, stolen tokens, misconfigured admin access, and data leakage through logs or search indexes.

Do not treat those as the same problem. That leads to bad designs.

Tenant isolation has layers

Tenant isolation is not one control. It is a stack of controls across several layers:

Identity: who is the caller?
Authorization: what can the caller do?
Data: which rows, objects, indexes, and backups can be accessed?
Compute: where does code run?
Network: what can the runtime connect to?
Secrets: which credentials are available?
Observability: what appears in logs, traces, metrics, and audits?
Billing and quotas: who pays for the work, and who can consume capacity?

tenant_id filtering in Postgres helps with logical data isolation. It does not sandbox a build script. It does not stop SSRF. It does not cap CPU usage. It does not redact a secret from logs.

Good interview answers make that distinction clear.

Choose the right isolation primitive

Isolation primitives sit on a spectrum.

Processes are cheap and fast, but they are weak for untrusted code. Containers add Linux namespaces and cgroups. MicroVMs, such as Firecracker, reduce host kernel sharing compared with containers. Full VMs provide stronger separation, but startup time and memory overhead are higher.

A practical answer often compares them like this:

Primitive	Strength	Cost
Process	Low isolation	Very low overhead
Container	Namespaces, cgroups, image packaging	Fast startup, shared kernel
MicroVM	Stronger kernel boundary	More overhead than containers
Full VM	Strong separation	Higher startup and memory cost

For an interactive cloud IDE, containers may give better startup latency and density. For arbitrary public workloads, microVMs may be worth the extra overhead. For regulated or high-risk tenants, full VMs or separate cloud accounts may be justified.

Tie the primitive back to the product constraint. Think about latency, cost, workload duration, risk level, and tenant value.

Know what namespaces and cgroups do

If you mention containers, be ready to name the underlying controls.

Linux namespaces isolate what a process can see:

pid: process tree
net: network interfaces and routing
mnt: filesystem mounts
uts: hostname and domain name
ipc: interprocess communication
user: user and group IDs
cgroup: cgroup hierarchy

cgroups limit what a process can consume:

CPU shares
Memory
Process count
I/O bandwidth
Device access

A simple way to say it: namespaces hide resources, cgroups limit resources.

For sandboxed execution, add hardening:

Run as non-root
Drop Linux capabilities such as CAP_SYS_ADMIN
Use a deny-by-default seccomp profile
Apply AppArmor or SELinux
Mount filesystems read-only where possible
Reject privileged containers
Avoid host mounts unless there is a very specific reason

Saying "each job runs in a pod" is not enough. Pods share the host kernel, and unsafe pod settings can break your isolation model.

Resource fairness needs admission control

Multi-tenant systems can fail even without an attacker. One tenant can start too many builds or keep too many IDE sessions open.

You need admission control before scheduling work. A simple capacity model is:

concurrent_jobs <= floor(total_safe_capacity / per_job_reservation)

Then add:

Per-tenant quotas
Global queues
Priority classes
Burst limits
Timeouts and TTLs
Eviction rules for idle sessions

CI/CD systems care heavily about queue fairness. Cloud IDEs care about interactive latency and idle cleanup. Both need limits, or one tenant can become a noisy neighbor.

Data isolation is physical, logical, or hybrid

There are three common data tenancy models.

Separate databases per tenant reduce blast radius and can simplify deletion or export. The tradeoff is operational overhead.

Shared tables with tenant_id are easier to operate at scale, but every query and authorization path must be correct. Use composite indexes such as (tenant_id, object_id), and consider Postgres row-level security as defense in depth.

A hybrid model may put large or high-risk tenants in dedicated storage while smaller tenants share tables.

The interview signal is not that one model is always best. The signal is that you can explain the tradeoff and add safeguards.

Authorization should fail closed

Never trust a client-supplied tenant_id.

Derive tenant context from one of these:

Session data
Token claims
Server-side membership lookup

Then check permissions centrally. Examples:

workspace:read
workspace:write
runner:execute
artifact:download
admin:invite_user

Every request should carry an authenticated principal and tenant context. If the system cannot determine either one, deny the request.

Cross-tenant authorization bugs are common because teams scatter permission checks across handlers. A central authorization layer reduces that risk.

Use ephemeral runtimes for code execution

Mutable shared workers are dangerous for CI/CD and cloud IDE workloads.

A safer lifecycle looks like this:

Create a fresh runtime from a known image
Attach only the credentials needed for this job or session
Run the workload
Stream logs and terminal output
Persist declared artifacts or workspace changes
Tear down the sandbox

Warm pools can reduce startup time, but they must be scrubbed carefully before reuse. If you cannot prove cleanup is correct, prefer fresh environments.

A useful state machine is:

Queued -> Provisioning -> Running -> Stopping -> Persisting -> Terminated

Add retries and cleanup for every transition. Orphaned sandboxes cost money and create risk, so use heartbeats, leases, TTLs, and a janitor process.

Secrets are often the breach path

Many sandbox escapes start with boring credential leakage.

Do not bake secrets into images, dependency caches, or shared volumes. Inject short-lived credentials at runtime from Vault, a cloud IAM system, or a secret manager.

Scope credentials as tightly as possible:

Tenant
Repository
Branch
Job
Environment

Redact secrets in logs. Treat terminal output, build logs, traces, and error reports as possible exfiltration channels.

Network isolation needs egress control

A sandbox should not have broad network access by default.

Use per-sandbox network namespaces, Kubernetes network policy, security groups, service mesh policy, or egress proxies. Block access to:

Cloud metadata endpoints such as 169.254.169.254
Internal admin services
Other tenants' private networks
Control plane APIs unless explicitly allowed

Ingress matters too, but egress is where many sandbox designs fail. If arbitrary code can reach internal services, SSRF becomes a real incident path.

Cache carefully

Caches are great for build speed and infrastructure cost. They are also a common isolation footgun.

Key dependency caches and Docker layer caches by:

Tenant
Repository
Lockfile hash
Architecture
Trust level

Cross-tenant read-only public caches can be acceptable. Writable shared caches are risky because one tenant may poison dependencies or artifacts used by another.

For CI/CD platforms, artifact integrity should be part of the design. Signed artifacts and strict cache keys are stronger than "we have a shared cache directory."

A strong cloud IDE answer

For "Design a sandboxed cloud IDE," start with clarifying questions:

Are users running arbitrary code?
Do sessions need internet access?
Which languages must be supported?
Is the home directory persistent?
What startup latency target matters, such as p95 < 5s?

Then structure the design:

Control plane: authenticates users, maps users to tenants and workspaces, schedules sessions, stores metadata in Postgres
Execution plane: runs containers or microVMs on isolated node pools with cgroups, seccomp, non-root users, per-session networking, and TTL cleanup
Persistence and streaming: stores workspace files on per-tenant volumes or object storage snapshots, streams terminal I/O through WebSocket or server-sent events
Operations: quotas, warm pools, autoscaling, audit logs, metrics, and janitor jobs

Call out the container versus microVM tradeoff. Containers are faster and denser. MicroVMs reduce kernel-sharing risk for arbitrary code. A tiered model is often the cleanest answer.

A strong CI/CD answer

For "Design a multi-tenant CI/CD platform," the same principles apply, but the workload is batch-oriented.

Focus on:

Ephemeral runners
Per-job credentials
Tenant-scoped queues
Fair scheduling
Cache keys tied to lockfiles and trust boundaries
Signed artifacts
Strict teardown after each pipeline step

The risks are malicious build scripts, dependency cache poisoning, secret exfiltration, and queue starvation.

If you want more prompts in this area, PracHub has related software engineering interview questions that pair well with this topic.

Common mistakes

The biggest mistake is treating tenant_id as the full isolation story. It only covers part of data access.

The second mistake is jumping to Kubernetes without naming the real security boundary. A pod is not automatically safe.

The third mistake is choosing maximum isolation without product context. A full VM per request may be too slow or expensive for an IDE. A shared container may be too weak for hostile public code.

A good answer layers controls and explains tradeoffs. Start with the threat model, pick the isolation primitive, lock down data and secrets, add quotas, restrict networking, and design cleanup as part of the system.

For a more interview-focused version of this breakdown, see the original PracHub guide to multi-tenant isolation and sandboxing.

DoorDash Data Scientist Interview Cheatsheet 2026

Feng Zhang — Wed, 22 Jul 2026 14:26:03 +0000

DoorDash Data Scientist interviews usually test two things at the same time: can you write clean analytical code, and can you reason about a messy three-sided marketplace without acting like the data is cleaner than it is.

If you are preparing for the 2026 cycle, the full DoorDash Data Scientist interview prep cheatsheet on PracHub is a useful reference. This post condenses the main patterns into a standalone guide you can use while studying.

The core areas are:

SQL and Python data manipulation
Window functions
A/B testing
Causal inference
Marketplace metric design
Delivery quality diagnostics
Switchback experiments
Unit economics, pricing, and power analysis

The main theme across all of them: DoorDash questions are rarely pure syntax questions. They are business analytics questions where the hard part is often defining the metric correctly.

SQL: treat business definitions as part of the problem

DoorDash SQL questions usually involve orders, customers, restaurants, Dashers, events, cities, and time. You may be asked to calculate monthly spend, identify top restaurants, compare customer behavior across periods, or derive delivery-quality metrics.

The interviewer is checking whether you can turn vague business language into correct query logic.

Before writing code, clarify:

What counts as a completed order?
Which timestamp should be used: created, confirmed, picked up, delivered, canceled?
What timezone should reporting use?
Are canceled or refunded orders included?
Is the metric order-level, customer-level, restaurant-level, or market-level?

Common SQL patterns include:

DATE_TRUNC('month', created_at)

for monthly metrics,

SUM(CASE WHEN condition THEN 1 ELSE 0 END) * 1.0 / COUNT(*)

for rates, and ROW_NUMBER, RANK, or DENSE_RANK for top-N queries.

The mistake I see most often is row inflation after joins. If you join an order table to item-level or event-level data, COUNT(*) may no longer mean number of orders. Use COUNT(DISTINCT order_id) when the grain requires it.

Also be careful with LEFT JOIN. A filter in the WHERE clause on the right-side table can turn it into an inner join and remove customers, restaurants, or cities with zero activity.

Window functions: know the grain before ranking or comparing

Window functions come up often because marketplace data is sequential. Customers reorder, Dashers receive dispatches, orders move through statuses, and restaurants have performance trends over time.

You should be comfortable with:

LAG(value) OVER (
  PARTITION BY customer_id
  ORDER BY order_ts
)

for prior-order comparisons,

LEAD(status) OVER (...)

for what happened after an event, and

ROW_NUMBER() OVER (
  PARTITION BY city_id
  ORDER BY orders DESC, restaurant_id
)

for deterministic top-N logic.

A good answer explains tie behavior. If the interviewer asks for one top restaurant per city, RANK() may return multiple rows. ROW_NUMBER() with a stable tie-breaker is safer.

For rolling or cumulative metrics, distinguish row-based windows from calendar-based windows. A "7-day rolling order count" is not the same as "last 7 rows." If the table has missing days, that difference matters.

A reliable workflow is:

Aggregate to the right grain first, such as restaurant-day or customer-month.
Apply window functions after that.
Filter top-N results in an outer query or CTE.

That prevents mixing raw order rows with grouped metrics, which can duplicate revenue or distort rates.

A/B testing: user-level randomization is often wrong

Many DoorDash experimentation questions are traps for people who default to "split users 50/50 and compare conversion."

That can work for independent consumer UI changes. It can fail badly for marketplace interventions.

If a change affects dispatch, batching, fees, delivery radius, Dasher incentives, or restaurant availability, one treated unit can affect untreated units. A treated order can change Dasher supply, merchant wait time, ETA accuracy, and customer experience nearby.

That is interference, and it violates the usual assumption that one unit's treatment does not affect another unit's outcome.

For marketplace changes, consider:

Geo-level randomization
Market-level randomization
Zone-level randomization
Time-block randomization
Geo-time switchback experiments

A switchback design might randomize treatment by zone × time_block, such as 2-hour or 4-hour blocks. This is useful when market conditions differ across cities or zones, but the policy can alternate over time.

A common analysis equation is:

$$Y_{g,t}=\alpha_g+\gamma_t+\beta T_{g,t}+\epsilon_{g,t}$$

where geography fixed effects control for persistent market differences, time fixed effects control for common time shocks, and treatment estimates the policy effect.

Use clustered standard errors at the assignment level. If treatment was assigned by zone-hour, raw order count alone does not tell you the true amount of independent evidence.

Power: millions of orders can still be underpowered

Clustered experiments reduce effective sample size. If you randomize across 10 markets, you do not magically have millions of independent experimental units just because millions of orders occurred.

A simple design effect is:

$$DE = 1 + (m-1)\rho$$

where m is cluster size and ρ is intra-cluster correlation.

That means power depends on the number of independent clusters and the variance at that level. For switchbacks, use historical variance at the market-time or zone-time level.

For a two-sample mean comparison, a rough sample size formula is:

$$n \approx \frac{2\sigma^2(z_{1-\alpha/2}+z_{1-\beta})^2}{\delta^2}$$

For proportions, replace variance with p(1-p).

In an interview, you do not need to compute every value perfectly. You do need to say what minimum detectable effect matters, what variance estimate you would use, and how clustering changes the calculation.

Metrics: pick one decision metric and guardrails

DoorDash experiments often involve tradeoffs. A batching algorithm may raise orders per Dasher hour but hurt food quality. A promotion may improve D7 retention but increase refunds. A dispatch change may reduce delivery time while lowering Dasher earnings.

A strong metric setup has:

One primary decision metric
Guardrail metrics
Diagnostic metrics
Pre-planned segments

For logistics changes, primary metrics might include delivery time, on-time rate, or contribution profit per order. Guardrails might include cancellation rate, merchant wait time, Dasher idle time, customer rating, refund rate, or reorder rate.

Segments matter because effects can differ by market density, peak versus off-peak, new versus existing customers, restaurant category, distance band, Dasher mode, and supply-demand balance.

Do not claim success from an aggregate lift if suburban zones degrade while dense urban zones improve. That is exactly the kind of marketplace reasoning interviewers expect.

Causal inference: start with the estimand

Causal inference questions usually start with a metric change or a proposed rollout: late deliveries increased, a merchant variety launch changed retention, a new incentive changed Dasher behavior.

Do not jump straight to a model. Start by defining the causal question.

Are you estimating:

Average treatment effect?
Treatment effect on treated?
Segment-specific effect?
Local effect for compliers?

Then choose the method.

Randomized experiments are best when feasible. If not, DoorDash-style questions often point toward difference-in-differences, matched controls, synthetic control, or staggered rollout analysis.

For difference-in-differences:

$$\hat{\tau} = (Y_{treated,post} - Y_{treated,pre}) - (Y_{control,post} - Y_{control,pre})$$

The key assumption is parallel trends. You should say you would check pre-period trends, run placebo tests, and compare against matched markets.

Regression adjustment can improve precision, but it does not remove bias by itself. Use pre-treatment covariates only. Controlling for post-treatment variables, such as actual delivery time, can block part of the treatment effect you are trying to measure.

Example: diagnosing late deliveries

A good answer starts with definitions.

"Late" could mean late relative to quoted ETA, promised delivery window, or food-ready time. The business may care about order-level lateness, customer perception, merchant SLA, or retention.

Then decompose total delivery time:

Merchant prep time
Dasher assignment latency
Travel to merchant
Pickup wait
Travel to customer
Batching delay

Compare affected and unaffected markets, dayparts, merchant types, weather conditions, and distance bands. Once you have a leading hypothesis, choose the design.

If prep-time estimates look wrong, test merchant-facing prep prompts or adjusted buffers. If Dasher supply is the issue, a zone-hour switchback test of incentives may fit better than customer-level randomization.

The final recommendation should tie back to launch criteria: reduce late rate without hurting Dasher earnings, merchant wait, cancellations, refunds, or contribution margin.

What to practice

For SQL, practice joins, conditional aggregation, date grouping, ranking, rolling metrics, and percentiles. For experimentation, practice explaining why user-level randomization may fail and how switchbacks work. For causal inference, practice turning a vague metric movement into a clear estimand, method, and decision.

You can find related DoorDash-style and marketplace analytics prompts in the PracHub interview questions library.

If you want the full structured version with topic-by-topic practice cards, use the DoorDash Data Scientist interview prep cheatsheet as your study checklist.

Supervised ML Fundamentals, Evaluation And Feature Engineering Explained — Tech Interview Concept (2026)

Feng Zhang — Wed, 15 Jul 2026 14:25:45 +0000

Supervised ML interview questions usually are not about reciting definitions. The better signal is whether you can pick a model, design the evaluation, explain tradeoffs, and tie the choice to business cost.

If you want the original interview-focused version, PracHub has a concise concept page on supervised ML fundamentals, evaluation, and feature engineering. This post rewrites the same ideas as a practical guide for developer and data science readers.

Start with the decision context

Before comparing algorithms, ask what the model output is used for.

Are you optimizing:

Probability accuracy?
Ranking quality?
Forecast accuracy?
A hard business action, such as block, approve, alert, or reorder?
Interpretability for product, operations, or compliance teams?
Low-latency scoring?

That question changes the model and the evaluation.

A fraud model with a rare positive class should not be judged by raw accuracy. A demand forecast should not use random cross-validation if time order matters. A conversion model used for bidding may need calibrated probabilities, while a search relevance model may care more about ranking metrics.

A good interview answer often starts with: "I would first clarify whether we need calibrated probabilities, ranking quality, forecast accuracy, or an action threshold tied to business cost."

Linear and logistic regression are still worth knowing well

Linear regression estimates coefficients by minimizing squared error:

$$
\min_\beta \sum_i (y_i - x_i^\top\beta)^2
$$

The classic assumptions are linearity, independent errors, homoscedasticity, no perfect multicollinearity, and exogeneity:

$$
E[\epsilon \mid X]=0
$$

Breaking these assumptions does not automatically make predictions useless. It does affect inference, confidence intervals, and how much you should trust coefficient interpretation.

Logistic regression models class probability as:

$$
P(y=1 \mid x)=\sigma(x^\top\beta)
$$

It minimizes log loss, not squared error. In tabular classification, logistic regression is often a strong baseline, especially with sparse high-dimensional features. It is also easier to explain and often better calibrated than many complex models out of the box.

Do not skip the baseline. If a boosted tree barely beats regularized logistic regression but is harder to explain, slower to score, and poorly calibrated, the simpler model may be the better production choice.

Regularization is about controlling variance

Regularization penalizes model complexity to reduce overfitting.

Common forms:

L2 regularization adds $\lambda|\beta|_2^2$. It shrinks coefficients smoothly and works well with correlated predictors.
L1 regularization adds $\lambda|\beta|_1$. It can set coefficients to zero, which makes it useful for sparse feature selection.
Elastic Net combines L1 and L2. It is useful when groups of correlated predictors are present.
L0 regularization counts nonzero coefficients, $|\beta|_0$. It directly targets subset selection, but exact optimization is usually combinatorial.
L∞ regularization constrains the maximum absolute coefficient. It is less common in applied interviews, but it tests whether you understand norm geometry and constraints.

Feature scaling matters here. If one feature is measured in cents and another in years, a regularization penalty treats their coefficients differently unless you scale the inputs. Scaling is also needed for distance-based models and many gradient-based linear models.

Tree models such as Random Forests, Gradient Boosted Trees, XGBoost, and LightGBM are mostly invariant to monotonic scaling. Transformations can still help with outliers or skewed distributions.

Random Forests vs Gradient Boosting

This is a common interview comparison because both are tree ensembles, but they behave differently.

Random Forests reduce variance through bagging. They train many decorrelated trees on bootstrap samples and random subsets of predictors. They are stable, parallelizable, and less sensitive to hyperparameter settings. They are often a safe first model when labels are noisy or you need a benchmark that does not take much tuning.

Gradient Boosting trains trees sequentially. Each new tree fits residuals or gradients from the current model. This tends to reduce bias and often works very well on structured tabular data. XGBoost and LightGBM are common examples.

The tradeoff is tuning. Boosted trees need careful control of:

Learning rate
Number of trees
Max depth
Subsampling
Column sampling
Early stopping

If trees are too deep or boosting rounds run too long, boosted models can overfit label noise.

A solid answer sounds like this:

"Random Forests mainly reduce variance through bagging, while Gradient Boosted Trees reduce bias through sequential additive learning. I would compare them based on predictive performance, sensitivity to noisy data, tuning cost, calibration, and the business metric. Boosted trees may win on PR-AUC or lift, but Random Forests may be easier to tune and less brittle."

That answer is much better than "Gradient Boosting is more accurate" or "Random Forests avoid overfitting."

Class imbalance changes the metric

Accuracy is a trap when positives are rare.

If the positive class rate is 0.5%, a classifier that always predicts negative gets 99.5% accuracy. That number is useless.

For imbalanced classification, consider:

precision
recall
F1
PR-AUC
Top-k lift
Recall at fixed precision
Cost-weighted metrics

ROC-AUC can also mislead when positives are extremely rare. A model can have a strong ROC-AUC while precision is too low for production use.

Sampling and class weights can help training, but they do not replace a good evaluation plan. You still need to choose a decision threshold based on cost.

For example, a fraud model might optimize:

$$
EV(t)=TP(t)\cdot B - FP(t)\cdot C - FN(t)\cdot L
$$

Here, $t$ is the threshold, $B$ is the benefit of catching fraud, $C$ is the cost of a false positive, and $L$ is the loss from a false negative.

The model produces scores or probabilities. The threshold is a business policy layered on top.

Calibration matters when probabilities drive decisions

Ranking quality and probability accuracy are different.

A model can rank cases well but produce poorly calibrated probabilities. That may be fine for a top-k review queue. It is a problem if probabilities feed expected-value calculations, capacity planning, pricing, or downstream decision systems.

Logistic regression is often reasonably calibrated. Boosted trees may need Platt scaling or isotonic regression.

Useful calibration checks include:

Calibration curves
Brier score
Observed vs predicted rates by score bucket

If a bucket of users predicted at 20% conversion actually converts at 8%, that model may still rank users well, but its probabilities are not reliable.

Time-series forecasting needs temporal validation

Forecasting has a different data-generating process from ordinary tabular classification.

Random train/test splits leak future information. They can make a weak model look strong, especially when seasonality, promotions, customer behavior shifts, or inventory effects are present.

Use temporal validation, such as:

A simple holdout from a later time period
Rolling-origin evaluation
Backtesting across several forecast windows

Before using complex models, compare against simple baselines:

Seasonal naive
Moving average
Simple exponential smoothing

Then test models such as ARIMA, Prophet, tree models with lagged variables, or sequence models if the problem calls for them.

Metrics should match the operational decision. For demand forecasting, common choices include WAPE, sMAPE, pinball loss, or a service-level cost tied to stockouts and overstock.

Feature engineering without leakage

Feature engineering should encode signal available at prediction time. That last phrase matters.

Common tabular features include:

Lagged demand
Rolling means
Customer tenure
Frequency counts
Recency
Price bands
Target encodings for categoricals
Missingness indicators
Log-transformed monetary values

The risk is leakage. If you compute a rolling average using data after the prediction timestamp, you have leaked future information. If you use target encoding without proper out-of-fold or time-aware computation, the model may learn the answer indirectly.

For repeated entities, grouped splits may be needed. For time-dependent data, temporal holdouts are safer than random splits. Segment-level error checks can also reveal that a model works overall but fails for a product category, region, or customer group.

How to answer this in an interview

A strong structure is:

Clarify the target and decision use.
Describe the data conditions: size, sparsity, label noise, missingness, class balance, time dependence.
Pick baselines first.
Compare model families conditionally.
Choose metrics tied to business cost.
Discuss calibration, thresholds, and validation design.
Name leakage risks.

For example:

"I would start with regularized logistic regression as a baseline because it is interpretable and often well calibrated. I would compare Random Forests and Gradient Boosted Trees using a temporally held-out set if time matters. Since positives are rare, I would use PR-AUC, recall at fixed precision, and expected cost rather than accuracy. If probabilities drive actions, I would check calibration and apply Platt scaling or isotonic regression if needed."

That answer shows model knowledge, evaluation judgment, and production awareness.

For more interview prompts around these topics, PracHub has a set of technical interview practice questions you can use to test your reasoning under pressure.

Common mistakes to avoid

Using accuracy by default.

Accuracy is often the wrong metric for imbalanced classification.

Comparing models without conditions.

"XGBoost is better" is not enough. Better for what data, what metric, what latency limit, and what decision?

Ignoring validation design.

Random splits can leak information in time-series and repeated-entity problems.

Forgetting calibration.

A high-ranking model may still produce bad probabilities.

Treating feature engineering as harmless.

Rolling features, target encodings, and aggregations can leak future or label information if computed incorrectly.

If you want the original concept-card version with the compact interview framing, see PracHub's post on supervised ML fundamentals, evaluation, and feature engineering.

Amazon Data Scientist Interview Cheatsheet 2026

Feng Zhang — Wed, 08 Jul 2026 14:25:57 +0000

Amazon Data Scientist interviews test whether you can turn messy data into a product decision you can defend. You need SQL or pandas fluency, experiment design, metric judgment, ML fundamentals, and clear communication when the prompt is underspecified.

This post is a condensed, blog-friendly version of the PracHub Amazon Data Scientist interview cheatsheet, focused on the parts that tend to separate candidates who have done real analysis from candidates who only know textbook definitions.

What Amazon is usually testing

The interview loop can cover several areas:

Data manipulation with SQL and Python
Product analytics and root-cause analysis
A/B testing and statistical inference
Machine learning fundamentals and evaluation
Applied ML system thinking, including RAG
Behavioral answers mapped to Amazon Leadership Principles

The bar is not "can you recite a formula?" It is closer to: can you define the right metric, compute it correctly, explain your assumptions, catch validity problems, and recommend an action?

Python and pandas: show that your metrics are trustworthy

For pandas questions, interviewers want analysis-grade data manipulation. Expect messy inputs, duplicate rows, mixed date formats, joins across tables, missing values, and business logic hidden in the prompt.

Common pattern:

df.groupby(keys).agg(
    revenue=("revenue", "sum"),
    orders=("order_id", "nunique"),
    customers=("customer_id", "nunique")
)

That code is easy. The interview is about whether the aggregation is valid.

Before grouping, ask:

What is the row grain?
Are there duplicate events or repeated order lines?
Are timestamps in the same timezone?
Are we joining many-to-one, one-to-many, or many-to-many?
Do we need currency normalization before summing revenue?
How should ties be handled in rankings?

A good answer sounds like this:

"I would first validate the grain. If this table is order-line level, I should not count rows as orders. I would count distinct order IDs, normalize currency through the exchange-rate table, then aggregate by customer and month."

That shows you know metric code can be syntactically correct and still wrong.

Useful pandas tools to have ready:

pd.to_datetime() for date cleanup
.dt.date, .dt.to_period("M") for time buckets
merge() for lookup joins
drop_duplicates() for business-key dedupe
rank(), sort_values(), cumcount() for within-group ranking
np.where(), pd.cut(), boolean masks for segments

The biggest mistake is aggregating before fixing grain. Once duplicate rows flow into your metric table, every chart and model downstream inherits the error.

A/B testing: do not jump straight to p-values

Amazon-style experimentation questions usually ask you to design or analyze an online controlled experiment. The interviewer is testing causal reasoning, metric design, statistical mechanics, and judgment.

Start with clarification:

What is the randomization unit: user, session, product, request?
What is the primary metric?
What are the guardrails?
Is the assignment stable?
Is the analysis window long enough for delayed outcomes?
Are users counted once or multiple times?

For a binary metric, such as conversion, you may compute:

Control rate: x_c / n_c
Treatment rate: x_t / n_t
Absolute lift: p_t - p_c
Relative lift: (p_t - p_c) / p_c
Confidence interval for the difference
Two-proportion z-test, if sample size assumptions are reasonable

But a better interview answer does not stop there.

Before inference, check validity:

Sample ratio mismatch
Exposure logging gaps
Duplicate users
Bot or internal traffic
Pre-period balance
Metric denominator consistency
Unit mismatch between randomization and analysis

A weak answer is:

"Treatment conversion is higher and p < 0.05, so launch."

A better answer is:

"I would first verify the planned traffic split and user-level assignment. Then I would estimate absolute and relative lift with a confidence interval. I would launch only if the lift is statistically and practically meaningful, guardrails such as latency and refund rate are neutral, and the result is stable across major pre-specified cohorts."

That last part matters. At Amazon scale, a tiny lift can be statistically significant. It still may not be worth shipping if it harms customer trust, latency, complaints, or downstream outcomes.

For sample size questions, ask for:

Baseline conversion rate
Minimum detectable effect
Alpha
Desired power
Number of variants
Metric type: binary, continuous, ratio-based, clustered

Then define the decision rule before the data arrives. For example:

"Ship if the 95% confidence interval excludes zero, the lower bound is above the practical threshold, and guardrail metrics stay within agreed limits."

Product metrics and root-cause analysis: build the metric tree

Product analytics questions often start with a vague movement:

"Revenue dropped."
"CTR is down."
"Search conversion changed."
"A dashboard metric spiked."

Do not start with random theories. Start by defining the metric and decomposing it.

For revenue, a simple tree might be:

Revenue = Traffic × Conversion Rate × Average Order Value

Then break each branch down:

Traffic:
- visits
- unique customers
- channel mix
- device mix

Conversion:
- product views
- add-to-cart rate
- checkout start rate
- order completion rate

Average Order Value:
- item price
- units per order
- discounts
- shipping or fees

Good root-cause analysis usually follows this flow:

Confirm the metric definition.
Check data quality and pipeline changes.
Compare time windows correctly.
Segment by product, geography, device, customer type, traffic source, or cohort.
Separate correlation from causal claims.
Use visualizations that match the question.

Dashboard tooling can mislead if joins, filters, and aggregation grain are wrong. If a Tableau chart says revenue dropped, you still need to know whether it uses order date or shipment date, whether canceled orders are included, and whether currency conversion happened before or after aggregation.

RAG questions: treat it as an ML system, not "add a vector database"

Retrieval-augmented generation is now fair game for Data Scientist interviews. The DS angle is less about serving infrastructure and more about evaluation, tradeoffs, and risk.

A typical RAG pipeline has:

Document selection
Chunking
Embeddings
Vector retrieval
Optional lexical retrieval such as BM25
Reranking
Prompt construction
Generation
Post-generation validation

If asked to design or evaluate a RAG system, frame the use case first:

"What corpus are we answering from? How fresh is it? What is the cost of a wrong answer? Do we need citations? Are out-of-scope questions common?"

Then split evaluation into retrieval quality and answer quality.

Retrieval metrics:

Recall@k
Precision@k
MRR
nDCG@k

Answer metrics:

Correctness
Faithfulness to retrieved context
Citation accuracy
Coverage
Refusal quality
Helpfulness
Latency and cost per query

A key distinction: an answer can be true but unsupported by the retrieved context. For factual systems, that is still a failure.

Know the RAG vs fine-tuning tradeoff:

Use RAG when facts change often, citations matter, or the corpus is large.
Use fine-tuning for tone, output format, intent classification, or consistent task behavior.
A strong system may use RAG for grounding and fine-tuning for behavior.

For Amazon-like catalogs, policies, seller docs, and support content, hybrid retrieval often makes sense. Dense retrieval handles semantic similarity. BM25 helps with exact product IDs, policy names, rare entities, and error codes. A reranker can improve the final passage list, though it adds latency and cost.

Behavioral answers still matter

For Amazon, technical strength is not enough. Prepare STAR stories tied to Leadership Principles. Your stories should be specific: what you owned, what tradeoff you made, what data you used, what changed because of your work.

Avoid generic claims like "I am customer obsessed." Show the decision.

For example:

"We had a metric discrepancy between two dashboards. I traced it to different order-date logic, aligned the definition with finance, backfilled the metric table, and added validation checks so the issue would not recur."

That kind of story connects ownership, data quality, and business impact.

How to practice

Use timed practice. For each question, force yourself to produce:

Clarifying questions
Assumptions
A clean solution path
Edge cases
A recommendation or decision rule

You can find related prompts in the PracHub interview question bank.

If you want the full topic map, examples, and practice cards for this role, use the Amazon Data Scientist interview cheatsheet on PracHub as your prep checklist.

Product Metric Design And Diagnostic Deep Dives Explained — Tech Interview Concept (2026)

Feng Zhang — Wed, 01 Jul 2026 14:25:38 +0000

A product metric design interview is usually a test of judgment, not memorization. You get an ambiguous product or integrity problem, then you need to turn it into a measurement plan a real team could act on.

The interviewer is checking whether you can keep these separate:

What the product should optimize
What the data can reliably observe
What might be biased, gamed, or misleading

This article adapts the main ideas from PracHub's guide to product metric design and diagnostic investigations, with a focus on how to structure your answer in a Data Scientist interview.

Start with the product goal, not the metric

A weak answer starts with a list:

DAU
posts
clicks
retention
reports

That sounds busy, but it does not explain what success means.

A stronger answer starts by clarifying how the product is supposed to work. For example, if the prompt is "Define success metrics for a Circles feature," you might say:

"I will treat Circles as a community product meant to deepen meaningful interaction among smaller groups. Success should be sustained, high-quality engagement without safety issues or notification fatigue."

That short framing does a lot of work. It tells the interviewer you will not blindly optimize raw activity. A feature can create more posts and still make the product worse if those posts are low quality, spammy, or annoying.

Pick a north-star metric that maps to durable value

A north-star metric should capture product value, not surface activity.

For a community product like Circles, raw joins or raw posts are easy to inflate. Users may join once and never return. Creators may post low-effort content. Spam accounts may create noisy groups.

A better primary metric could be:

weekly active circle members with meaningful two-sided interactions

Then normalize it:

meaningful interactions / eligible circle members

or:

meaningful interactions / eligible impressions

The denominator matters because each version answers a different question.

Per-member metrics ask whether members are getting value. Per-impression metrics ask whether exposed content creates useful engagement. Per-session metrics ask whether Circles changes behavior during active use. Raw counts hide these differences.

For a B2B chat product, the north-star metric might be qualified conversation starts, not total messages. A qualified conversation could require both parties to participate, or require that the conversation passes a basic quality threshold.

Define the unit of value before you define the count.

Build a metric tree

A metric tree helps you avoid treating metric design as a bag of unrelated numbers.

A useful structure is:

Outcome metric
Input metrics
Diagnostic metrics
Guardrails

For B2B chat, that might look like:

Category	Example metrics
Outcome	Qualified conversation starts
Inputs	Response rate, time-to-first-response
Diagnostics	Exposure rate, click-through rate, reply depth
Guardrails	Blocks, spam reports, opt-outs

This structure lets you explain why a metric moved.

If qualified conversations dropped, maybe fewer users saw the entry point. Maybe users clicked but did not send messages. Maybe messages were sent, but businesses stopped responding. Each diagnosis points to a different product issue.

Use guardrails to block bad launches

A positive primary metric does not mean the launch is safe.

Guardrail metrics protect user experience, integrity, and ecosystem health. Common guardrails include:

hide rate
report rate
block rate
unfollow rate
session length
notification opt-outs
harmful-content prevalence
advertiser complaints
support contacts

For Circles, guardrails might include mute rate, leave rate, reports, blocks, notification opt-outs, and displacement from broader feed engagement.

That last one is easy to miss. A feature may increase activity inside Circles while reducing healthy engagement elsewhere. If the new product fragments the social graph or pushes spammy invites, the top-line metric may look good while the broader product gets worse.

Cohort before you trust the average

Averages can hide the real story.

Cut the results by:

new vs existing users
market
device class
language
creator size
business type
group size
spam-risk tier
prior engagement

In a Meta-style interview, you should ask whether gains are broad-based or concentrated in a small segment. For example, Circles may help highly connected users while doing little for new users. A B2B chat change may help large businesses but hurt smaller ones that cannot respond quickly.

This is also where fairness and integrity concerns enter the answer. A harmful-content system that reduces measured prevalence overall may still perform poorly for a language group with weaker labels or lower reviewer coverage.

Match attribution windows to the product mechanism

The time window should match how value appears.

A chat product may need same-day response metrics and 7-day retention. A community product may need 14-day or 28-day return behavior. Harmful-content outcomes may need delayed labels because review, appeals, and classifier updates take time.

A window that is too short misses downstream value. A window that is too long adds noise and confounding.

Say this explicitly in the interview. It shows that you understand measurement as a product decision, not just a query.

Choose the right randomization unit

Experiment design starts with the unit of randomization.

User-level randomization works when the experience is isolated. Networked products are harder. For communities, pages, advertisers, threads, or circles, users interact with each other. One user's treatment can affect another user's experience.

That means you may need community-level, page-level, advertiser-level, or thread-level randomization.

You should also define the estimand:

direct effect
spillover effect
total ecosystem effect

For example, if some Circle members receive a new invite flow and others do not, their behavior may interact. A user-level A/B test may underestimate or distort the effect if treated and control users are in the same groups.

If randomization is not possible, you can propose a retrospective cohort design with matching or difference-in-differences. Keep the caveat clear: observational methods need stronger assumptions about confounding.

Think about power, especially for rare events

Rare events are hard to measure. Spam exposure, harmful-content reports, severe abuse, and appeals may have very low base rates.

A rough minimum detectable effect relationship is:

MDE ≈ (z_alpha/2 + z_beta) * sqrt(2 * sigma^2 / n)

The takeaway is that smaller effects, noisier metrics, and rare events need more data.

For low base-rate outcomes, you can consider:

aggregated exposure units
longer test duration
stratification
higher-signal proxy labels

Do not promise that a short test can detect rare harm reliably. That is exactly the kind of overconfidence interviewers watch for.

Treat proxy metrics with suspicion

Proxy metrics are useful because they are often fast and available. They are also dangerous.

For harmful content, user reports are visible and timely. But reports are biased by user awareness, culture, language, and reporting propensity. More reports could mean more harm, better reporting UX, higher user awareness, or more total usage.

Reports are not ground truth.

A stronger harmful-content evaluation combines:

user reports
human review labels
classifier scores
prevalence estimates
severity-weighted harm metrics

Severity matters. Counting all violations equally treats mild spam and severe abuse as the same kind of event.

A better metric is:

severity-weighted prevalence =
sum(exposures_i * severity_i) / total eligible exposures

The severity buckets should be transparent, and calibration checks should verify that labels are consistent enough to support decisions.

Use a diagnostic funnel for investigations

When a metric moves, avoid guessing. Use a funnel:

exposure -> action -> quality -> retention -> harm

If a product metric drops, ask:

Did fewer users become eligible?
Did fewer users see the surface?
Did fewer users act after exposure?
Did the quality of actions change?
Did retention move?
Did harm or negative feedback move?

This keeps the answer analytical. It also mirrors how real product teams debug launches.

Before interpreting a movement, check measurement validity:

logging coverage
denominator definitions
duplicate events
bot or spam filtering
experiment balance
sample-ratio mismatch
missing labels
metric backfills

You do not need to design the ingestion system in a product metric interview. You do need to know when the measurement is untrustworthy.

A compact answer pattern for interviews

For a metric design prompt, use this flow:

Clarify the product goal.
State assumptions.
Define the primary metric.
Add supporting funnel metrics.
Add guardrails.
Discuss cohorts and denominators.
Explain experiment design.
Name likely diagnostics if the result moves.

For Circles, that might be:

"Success is weekly active circle members with meaningful two-sided interactions, normalized by eligible members. I would support that with circle creation, invite acceptance, posting, comment depth, repeat participation, and 7-day or 28-day retention. Guardrails would include mutes, leaves, reports, blocks, notification opt-outs, and displacement from broader feed engagement. I would run an A/B test if possible, with user-level or circle-level assignment depending on spillovers. I would cut by new users, highly connected users, small markets, and baseline sharing behavior."

That is a defensible answer because it ties metrics to the decision the team needs to make.

If you want more prompts to practice this style, PracHub has a set of data science and product interview questions. For the full concept breakdown, use the original PracHub guide on product metric design and diagnostic investigations.

Amazon Machine Learning Engineer Interview Cheatsheet 2026

Feng Zhang — Wed, 24 Jun 2026 14:26:21 +0000

If you are preparing for an Amazon Machine Learning Engineer interview, expect more than "I know the model." You need to explain how the model works, how you would implement it, what breaks in production, and how you would decide whether it is good enough to ship.

The longer PracHub Amazon Machine Learning Engineer interview prep guide breaks this down by interview stage. This article condenses the highest-signal areas into a study guide you can use before a technical screen or onsite.

What Amazon is likely testing

For an MLE role, Amazon interviewers usually care about four things:

Can you reason from ML theory to working code?
Can you design systems that train, evaluate, and serve models reliably?
Can you debug models using metrics, data, and experiments?
Can you explain tradeoffs around latency, cost, memory, and quality?

A good answer does not stop at "use a Transformer" or "train XGBoost." You should be able to talk through tensor shapes, masks, evaluation gaps, distributed training, sparse data, online metrics, and deployment risk.

Transformers: know the internals, not just the vocabulary

Transformers are one of the highest-yield topics for an Amazon MLE interview. Be ready to explain scaled dot-product attention:

Attention(Q, K, V) = softmax((QK^T / sqrt(d_k)) + M)V

Here, M is often an additive mask. Allowed positions get 0; blocked positions get -inf. The sqrt(d_k) scaling keeps attention logits from getting too large and saturating the softmax.

For implementation questions, shape reasoning matters. Given input X with shape B x T x d_model, multi-head attention projects it into Q, K, and V, then reshapes them into something like:

B x num_heads x T x head_dim

The attention score tensor then has shape:

B x num_heads x T x T

A common bug is reshaping after a transpose without handling non-contiguous tensors. In PyTorch, that means knowing when .view() can break and when .reshape() or .contiguous() is safer.

For decoder-only models, causal masking is mandatory. Token t can only attend to positions <= t. If you forget this, the model can leak future labels during training. The loss may look great, but generation will fail.

You should also know the standard GPT-style block:

x = x + attention(LayerNorm(x))
x = x + MLP(LayerNorm(x))

This pre-norm layout is common because it helps gradient flow in deeper models. Post-norm matches the original Transformer pattern, but can be harder to train at scale.

LayerNorm is another frequent follow-up. It normalizes across the hidden dimension for each token independently:

LN(x) = gamma * (x - mean) / sqrt(variance + epsilon) + beta

Unlike BatchNorm, LayerNorm does not depend on batch statistics. That helps with variable batch sizes, sequence models, and autoregressive inference.

LLMs: connect architecture to operations

For LLM questions, you need to move between model internals and production behavior.

A strong answer covers:

Decoder-only Transformer architecture
Tokenization with BPE, WordPiece, or SentencePiece
Pretraining with next-token prediction
Instruction tuning with prompt-response data
Preference alignment methods such as RLHF or DPO
Fine-tuning choices such as full fine-tuning, LoRA, QLoRA, prefix tuning, and prompt tuning
Evaluation beyond perplexity
Serving constraints such as KV cache memory, throughput, and p99 latency

Perplexity is useful, but it is not enough. It measures next-token likelihood, not whether the model follows instructions, refuses unsafe requests correctly, produces grounded answers, or gives useful task outputs.

For a validation-system design question, structure your answer around:

Evaluation data

Use golden prompts, task-specific benchmarks, adversarial sets, regression cases from past failures, and production-like prompts sampled in a privacy-safe way.
Metrics

Include exact match where it fits, rubric scores, human preference win rate, hallucination or groundedness for RAG, toxicity or safety rates, refusal correctness, latency p50/p95/p99, tokens per second, and cost per request.
System components

Mention a model registry, prompt/version registry, evaluation runner, deterministic inference harness, result store, dashboard, and deployment gates.
Online validation

Use shadow tests, canary rollout, alerts for regressions, drift checks, and rollback criteria.

If the system is RAG-based, model quality depends on more than weights. Retrieval, chunking, embedding quality, ranking, prompt assembly, citation grounding, and index freshness all matter. Good evaluation should include retrieval recall@k, answer faithfulness, source attribution, and latency budget split across retrieval and generation.

MoE: sparse compute has systems costs

Mixture-of-Experts models often replace dense MLP layers with multiple expert networks and a learned router. A token may be sent to the top-1 or top-2 experts.

The benefit is that the model can have more total parameters without activating all of them for every token. The cost is systems complexity.

In an interview, avoid saying "MoE is more efficient" without explaining the tradeoff. Good answers mention:

Load-balancing losses
Expert collapse risk
Capacity factors
Token dropping during overload
Distributed all-to-all communication
Harder batching because routing is data-dependent
Higher risk around p99 latency

Dense models are simpler to serve. MoE models can scale parameter count better relative to FLOPs, but routing and communication make training and serving harder.

XGBoost: understand why it is fast

Amazon MLE interviews may still test classic ML, especially for tabular problems. XGBoost is a common topic because it mixes algorithm knowledge with systems thinking.

Gradient boosting builds an additive model:

y_hat_i^(t) = y_hat_i^(t-1) + eta * f_t(x_i)

Each new tree fits the residual signal, often framed as the negative gradient of the loss. This means boosting rounds are sequential. Tree t depends on predictions from earlier trees.

The parallelism is inside each tree:

across candidate splits
across features
across data partitions
across histogram bins
across workers in distributed training

XGBoost uses second-order information. Split scoring uses gradients and Hessians, with regularization terms such as lambda and gamma. You do not need to derive every line from memory, but you should be able to explain that XGBoost uses both first and second derivatives to score split quality.

For large datasets, exact split search can be expensive. Histogram-based split finding buckets continuous values into quantile bins, often far fewer than the number of raw thresholds. Workers build local histograms of gradient and Hessian sums, then reduce them. This gives better cache behavior and lower memory use, with some loss in split precision.

Also know why sparse handling matters. XGBoost learns a default direction for missing values, which helps with sparse one-hot data and missing feature values.

PyTorch implementation questions: be concrete

For "Implement a decoder-only GPT-style Transformer," start by clarifying scope:

"Should I implement a minimal PyTorch module with embeddings, positional encoding, masked multi-head attention, MLP blocks, and logits, or should I include training and generation too?"

Then state assumptions:

Input token IDs have shape B x T
Vocabulary size is V
Embedding dimension is C
Number of heads divides C
Output logits have shape B x T x V

Talk through token embeddings, positional embeddings or RoPE, stacked pre-norm blocks, causal masking, output projection, and loss.

Call out edge cases:

T exceeds configured context length
mask broadcasting is wrong
train/eval dropout behavior differs
causal mask is missing
.view() is used on a non-contiguous tensor
generation lacks a KV cache

A good implementation answer includes unit tests for shape, causal leakage, and a tiny overfit test to verify the model can learn.

Behavioral answers still need metrics

The source guide groups behavioral preparation under leadership principles, ownership, and measurable impact. For Amazon, that phrasing matters.

Do not give vague stories like "I improved model performance." Give the situation, your decision, the tradeoff, the result, and the metric. For an MLE, strong stories often include model quality, latency, cost, reliability, data quality, rollback decisions, or experiment design.

For example, a better answer sounds like:

"We had a relevance regression after a feature pipeline change. I traced the issue to offline/online feature mismatch, added validation checks before promotion, and reduced bad launches in that area."

The exact numbers depend on your experience, but the structure should make your ownership clear.

Final prep checklist

Before the interview, make sure you can answer these without notes:

Derive and explain scaled dot-product attention
Trace Transformer tensor shapes through multi-head attention
Explain causal masking and label leakage
Compare LayerNorm and BatchNorm
Discuss KV cache memory and autoregressive latency
Explain why perplexity is not enough for LLM evaluation
Design an LLM validation system with offline and online gates
Explain MoE routing and serving tradeoffs
Explain XGBoost histogram split finding and boosting-round dependency
Write a minimal PyTorch Transformer block
Tie every model choice to quality, latency, cost, or reliability

If you want to drill with targeted prompts, the PracHub interview questions library has practice questions across ML theory, system design, coding, and behavioral topics.

For the full role-specific breakdown, use the Amazon Machine Learning Engineer interview prep guide on PracHub as your main checklist.

Notifications And Lifecycle Engagement Explained — Tech Interview Concept (2026)

Feng Zhang — Wed, 17 Jun 2026 14:26:03 +0000

Notifications are easy to measure badly.

If a push campaign gets more clicks, did it create real engagement, or did it interrupt people who were already likely to open the app? If a ranking model lifts CTR, did it improve relevance, or did it learn to send curiosity bait? If dormant users come back today, do they stick around next month, or do they disable notifications?

That is what interviewers are getting at when they ask about notification and lifecycle engagement metrics. The original PracHub concept post on Notifications and Lifecycle Engagement covers the concept, but this article focuses on the answer pattern you can use in a data science or product analytics interview.

What interviewers are really testing

A weak answer sounds like this:

"I would track CTR, opens, DAU, and retention."

That is a metric list, not an evaluation plan.

A stronger answer explains:

What product decision the metric supports
What the primary outcome is
Which metrics are drivers
Which metrics are guardrails
How the experiment estimates incremental impact
How you handle fatigue, delayed outcomes, and selection bias

For a company like Meta, notifications can bring users back and help build habits. They can also annoy users, increase opt-outs, and reduce long-term trust. The interview is testing whether you can separate short-term movement from durable product value.

Start with the product goal

Before naming metrics, clarify the goal.

A notification system may be trying to:

Reactivate dormant users
Improve relevance of pushes
Increase marketplace actions
Reduce notification fatigue
Test a new ranking or sending policy
Personalize volume caps

The right metric depends on the goal. A reactivation system may care about D7_retained_active_users. A marketplace notification may care about listing_detail_views, saves, or seller_messages. A fatigue-reduction project may use disable_push_rate or mute_rate as the primary outcome.

This step matters because it ties measurement to an actual product decision.

Build a metric hierarchy

For notification experiments, organize metrics into three layers.

1. Primary metric

This is the metric you would use to make the launch decision.

Good candidates include:

D7_retained_active_users
D28_retained_active_users
Incremental sessions_per_user
meaningful_sessions
Downstream actions such as messages, purchases, comments, or listing views

The primary metric should capture user or business value, not raw notification volume.

2. Driver metrics

These explain why the primary metric moved.

Common driver metrics:

notification_open_rate
notification_click_through_rate
session_starts_from_notification
notification-attributed_sessions
downstream_conversion

CTR is useful here, but it should rarely be the launch metric.

The formula is simple:

$$CTR = \frac{\text{notification clicks}}{\text{notifications delivered}}$$

The problem is what CTR rewards. It can favor clickbait, curiosity, or over-targeting users who were already active. A notification that gets many clicks may still reduce retention if users feel spammed.

3. Guardrail metrics

Guardrails protect user trust and long-term health.

Use metrics such as:

disable_push_rate
mute_rate
uninstall_rate
hide_notification_rate
negative_feedback_rate
notifications_sent_per_user
complaints
Quality metrics like meaningful_interactions_per_session

A treatment that lifts DAU but also raises push disables may be a bad trade.

Design the experiment around assignment, not clicks

For most notification policies, randomize at the user level.

Control users get the existing policy. Treatment users are eligible for the new notification policy, ranking model, or sending rule.

The treatment should not be defined as "clicked a notification" or "received a notification." Those are post-treatment events. If you analyze only users who clicked, you introduce selection bias because the treatment itself affects who receives, sees, and clicks notifications.

Use intent-to-treat analysis as the primary estimate:

$$ITT = E[Y \mid Z=1] - E[Y \mid Z=0]$$

Here, Z is assignment to treatment.

This estimates the effect of being assigned to the new policy. Some assigned users may never receive a notification during the experiment. That is fine. ITT matches the product decision: should we launch this policy to eligible users?

You can report treatment-on-treated as a secondary diagnostic, but be careful. If exposure is affected by the treatment, exposed-user analysis can be misleading. If needed, use exposure rates or instrumental variables, with clear caveats.

Watch for interference

User-level randomization works well for many notification systems, but social notifications can create spillovers.

Examples:

"Your friend commented"
"Someone tagged you"
"A creator you follow posted"
Marketplace messages tied to listings

One user's treatment can generate messages or activity that affects another user. That violates SUTVA, the assumption that one unit's treatment does not affect another unit's outcome.

In those cases, consider cluster randomization. The cluster could be a conversation, household, creator-follower graph component, marketplace listing neighborhood, or another unit that captures likely spillovers.

Cluster experiments need more sample size because observations inside a cluster are correlated. The design effect is:

$$DE = 1 + (m-1)\rho$$

Here, m is cluster size and rho is the intra-cluster correlation.

Plan for small effects

Retention and opt-out effects can be small, so power matters.

For a two-sample comparison of means, a rough sample size formula is:

$$n \approx \frac{2\sigma^2(z_{1-\alpha/2}+z_{1-\beta})^2}{\delta^2}$$

Here, delta is the minimum detectable effect. For binary metrics, use p(1-p) as the variance.

If you have strong pre-period behavior, use CUPED or regression adjustment to reduce variance. Good covariates include pre-experiment:

sessions_per_user
notification_clicks
active_days

The covariates must be measured before assignment. This improves sensitivity without changing the estimand.

Segment by lifecycle stage

Notification impact is rarely uniform.

Analyze cohorts such as:

New users
Dormant users
Power users
Notification-heavy users
Low-intent users
Users with prior disables or mutes

A policy may help dormant users come back while annoying already-active users. A broad average can hide that pattern.

This is especially relevant for lifecycle engagement. The same push can feel helpful to one user and spammy to another. Segment analysis can support personalization, caps, or targeted rollout instead of a full launch.

Measure beyond the first click

Notifications often have delayed costs.

Common patterns:

CTR rises, but disable_push_rate rises later
DAU increases, but D28_retention falls
Sessions increase, but session quality drops
Short-term reactivation fades after users habituate

Use a window that matches the product goal. If the goal is reactivation, D1 may be too short. D7 or D28 can show whether users came back again. For long-term fatigue, use longer experiments, staggered rollouts, or holdouts.

Control multiple testing

Notification systems have many surfaces, cohorts, and outcomes. If you slice enough, some result will look significant by chance.

A clean answer says you would predefine:

Primary metric
Main guardrails
Evaluation window
High-risk cohorts

For many exploratory slices, use false discovery control such as Benjamini-Hochberg. For guardrails where false positives or false negatives are costly, Bonferroni correction may be more appropriate.

If you want more practice with these interview-style pivots, PracHub has related data science and product interview questions that cover experimentation, metrics, ranking, and causal inference.

Worked example: general notification policy

Suppose the prompt is:

"Define metrics and design experiments for notifications."

A strong answer could sound like this:

First, clarify the goal. Assume we are testing a new push notification ranking policy for a social app. The goal is to increase meaningful engagement and retention without increasing fatigue.

Primary metric:

D7_retained_active_users or incremental sessions_per_user

Driver metrics:

notification_open_rate
notification-attributed_sessions
downstream_actions, such as comments, messages, or shares

Guardrails:

disable_push_rate
mute_rate
uninstall_rate
notifications_sent_per_user
negative_feedback_rate
meaningful_interactions_per_session

Experiment design:

Randomize eligible users into control and treatment
Control keeps the current policy
Treatment is eligible for the new ranking or sending policy
Analyze by assignment using ITT
Avoid conditioning on users who clicked or received a notification
Use cluster randomization if social spillovers are strong

Decision rule:

Ship only if the primary metric improves and guardrails do not show statistically or practically meaningful harm. If the lift is concentrated in dormant users but guardrail harm appears among power users, consider personalization or volume caps instead of a full rollout.

Worked example: similar-listing notifications

Now suppose the prompt is:

"How would you evaluate a similar-listing notification feature?"

The product goal is narrower. You want to know whether notifying users about similar marketplace listings helps them find relevant items without feeling spammed.

Primary metrics could include:

Incremental listing_detail_views
saves
seller_messages
Purchase-intent actions

Guardrails:

notification_disable_rate
hide_rate
Lower engagement with future marketplace notifications

Randomize eligible users who viewed or saved a listing. Do not randomize only people who receive the notification, because eligibility is part of the treatment.

Use an evaluation window that includes delayed actions. A user may click today but message a seller two days later. Segment by intent strength too. Recent searchers may benefit, while casual browsers may find the same push irrelevant.

The common traps

Avoid these mistakes in an interview:

Optimizing only for CTR
Analyzing only users who opened the notification
Listing metrics without a launch rule
Ignoring opt-outs, mutes, and uninstalls
Treating all lifecycle cohorts the same
Missing network spillovers in social notifications
Reading too much into short-term DAU lift

A good interview answer is causal, decision-oriented, and honest about tradeoffs. You are not trying to prove notifications work. You are trying to estimate whether a specific policy creates incremental value without damaging retention or trust.

For a more compact interview-prep version of this framework, use the PracHub write-up on Notifications and Lifecycle Engagement as a reference before practicing mock answers.

Uber Data Scientist Interview Cheatsheet 2026

Feng Zhang — Wed, 10 Jun 2026 14:25:36 +0000

If you're preparing for an Uber Data Scientist interview, the hard part is not memorizing formulas. It is knowing how Uber frames data science problems: marketplace effects, experiment validity, ETA quality, and metric definitions that do not fall apart under edge cases.

This post is a condensed rewrite of PracHub's Uber Data Scientist interview prep guide, focused on the themes that come up in technical screens and onsite rounds.

What Uber is really testing

Across SQL, product analytics, experimentation, and stats, interviewers want to see whether you can:

define the metric correctly
choose the right unit of analysis
avoid leakage and bad denominators
reason about interference in a two-sided marketplace
separate model quality from business impact

That last one matters a lot. Lower prediction error does not automatically mean a better rider experience. A statistically significant A/B test result does not automatically mean "launch."

1) SQL: can you build defensible metrics from messy event data?

Uber SQL questions often look simple at first. Then they turn into deduping events, picking the correct grain, and handling time windows without leaking future information.

Topics that come up often:

Window functions you should be comfortable with

Last or first event per entity

Use ROW_NUMBER() with a deterministic sort:

ROW_NUMBER() OVER (
  PARTITION BY user_id
  ORDER BY event_ts DESC, event_id DESC
)

This is the standard pattern for "latest trip per rider" or "first exposure per user."

Rolling metrics

For time-series summaries, know how to write rolling averages by partition:

AVG(metric) OVER (
  PARTITION BY city
  ORDER BY dt
  ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
)

Top-N logic

You should know when to use RANK, DENSE_RANK, and ROW_NUMBER, and be able to explain tie behavior clearly.

Cohort conversion and CTR

A common failure mode is inflated CTR after joining impressions to clicks. If one impression maps to multiple clicks, COUNT(*) breaks the metric. You need to define the denominator once, dedupe at the right grain, and use explicit attribution windows like click_ts <= impression_ts + interval '48 hours'.

Date spine joins

These matter for rolling averages and anomaly detection. Generate all dates first, then left join events, and fill missing counts with zero.

Timezone-aware aggregation

If you analyze market-level data, local time matters. San Francisco metrics in January should not be cut on raw UTC day boundaries.

Common SQL mistakes

counting rows after a one-to-many join
using future rows in a rolling metric
treating RANK and ROW_NUMBER as interchangeable
skipping timezone conversion before DATE_TRUNC

If you want realistic drills for this style of question, PracHub has a set of data science interview practice questions that match the patterns above.

2) ETA questions: accuracy is only part of the problem

ETA is one of the clearest examples of how Uber expects product sense and statistical judgment to work together.

An interviewer is not looking for "we reduced MAE, so the model is better." They want you to think through:

what the ETA label is
how to evaluate prediction quality
whether the prediction is calibrated
how uncertainty should be measured
what user behavior changes after ETA changes
how interference breaks naive A/B testing

Start with label definition

You need to ask what ETA means in the question.

Is it:

request-to-pickup time?
pickup-to-dropoff time?
total trip duration?

The target has to match the user-facing promise. Cancellations, reassignment, batching, and no-shows all affect the label definition.

Know the evaluation metrics and what they miss

Uber cares about more than one error metric:

MAE is easy to interpret in minutes
RMSE penalizes large misses
median absolute error is more stable with outliers like airports or events
bias tells you whether the model is systematically optimistic or pessimistic

You should also say you would segment results by city, time of day, weather, airport, and trip type.

Calibration matters

If the app says 5 minutes and riders usually wait 7, the model is underestimating. That can increase conversion in the short run and hurt trust later.

Reliability curves by ETA bucket are often more useful than one aggregate accuracy score.

Uncertainty matters too

For dispatch and UX decisions, intervals can matter as much as point estimates. A 90% prediction interval should contain the actual arrival time about 90% of the time. Coverage and interval width are both relevant.

Connect ETA to business outcomes

A good answer separates model metrics from business metrics.

Examples of business outcomes:

request conversion
cancellation rate
completed trips
pickup delay
rider satisfaction

Guardrails might include:

driver idle time
acceptance rate
surge exposure
support contacts

3) Uber experiments are often not standard A/B tests

This is where many candidates get too generic.

For consumer apps, user-level randomization is often fine. At Uber, treatment can affect shared supply. One rider's treatment can change another rider's outcome. That means SUTVA may fail.

When interference matters

If treatment changes dispatch, pricing, ETA display, or demand, untreated users may still be affected.

Examples:

a rider-facing ETA change shifts demand in a neighborhood
a driver incentive changes driver supply for everyone nearby
a marketplace ranking change affects matching outcomes across groups

If you ignore that, your experiment readout may look precise and still be wrong.

Know when to propose switchback experiments

For marketplace changes, Uber often needs geo-time randomization instead of user-level assignment.

A strong answer for an ETA or dispatch experiment usually includes:

the estimand
the randomization design
primary metrics and guardrails
the inference plan

A reasonable design is a switchback experiment with city-zone-hour cells. You randomize treatment by market and time block, then analyze results with cluster-robust standard errors or a regression with time and geography fixed effects.

Do not use naive row-level standard errors if the design is clustered.

Power is different under clustering

For clustered experiments, you need to account for design effect:

DEFF = 1 + (m - 1)rho

where m is cluster size and rho is intra-cluster correlation.

That means more events inside the same cluster do not help as much as people expect. More independent clusters or time blocks usually matter more.

4) A/B testing answers need a decision framework

A lot of candidates list metrics and stop there. Uber wants a launch recommendation, not a metrics dump.

A solid structure is:

1. Define the objective

Example: Does a promo targeting change increase completed trips or gross bookings at an acceptable promo cost and contribution margin?

2. Pick the right randomization unit

rider_id for rider promos
driver_id for driver incentives
geo or switchback for marketplace changes with spillovers

3. Choose one primary metric

Possible primary metrics:

completed trips per user
conversion rate
gross bookings
variable contribution

Then add a short list of guardrails:

cancellation rate
ETA
surge rate
driver utilization
support contact rate

4. Check validity before interpretation

You should mention:

sample ratio mismatch
exposure correctness
pre-treatment balance
logging completeness
novelty or day-of-week effects

5. Make the recommendation based on practical value

Do not say "p < 0.05, ship it."

A result can be statistically significant and still be a bad launch if contribution drops, promo spend gets out of control, or marketplace health gets worse.

Final prep advice

If you're studying for this interview, spend less time on abstract ML talk and more time on clean definitions, marketplace-aware experiment design, and SQL execution details. That is where many answers get weak.

The full Uber Data Scientist interview prep guide on PracHub goes deeper on ETA evaluation, A/B testing, SQL patterns, and practice prompts. If you want to pressure-test yourself, work through timed practice questions here and say your answer out loud like you're already in the interview.