DEV Community: Feng Zhang

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.

CTR And Engagement Metrics Explained — Tech Interview Concept (2026)

Feng Zhang — Wed, 27 May 2026 14:24:49 +0000

CTR questions look simple in interviews until you realize the interviewer is not asking for a formula. They want to know whether you can define exposure correctly, separate shallow clicks from useful engagement, and decide what to do when metrics move in opposite directions.

This post is adapted from PracHub's original breakdown of CTR and engagement metrics, but rewritten as a standalone guide for data science and product analytics interviews.

What interviewers are really testing

On ranking-heavy products like a home feed, carousel, Shopping surface, fresh content module, or video feed, small product changes can move several metrics at once:

CTR goes up
saves stay flat
reports rise
retention drops
impressions per user jump because the UI exposes more content

Your job is to reason through that mess without jumping to the wrong conclusion.

Interviewers want to hear that you can:

define metrics precisely
explain what changed causally, not just descriptively
separate product impact from logging issues or mix shifts
make a launch recommendation under uncertainty

If your answer stays at "CTR is clicks divided by impressions," it is too shallow.

Start with the metric definition

Yes, CTR is usually:

$$CTR = \frac{\text{clicks}}{\text{impressions}}$$

But the grain matters a lot.

You might be talking about:

item-level CTR
user-level average CTR
session-level CTR
surface-level CTR

These are different metrics with different interpretations. In experiment analysis, user-level aggregation is often the safer choice because heavy users can otherwise dominate the estimate.

That is one of the easiest points to miss in an interview. If the surface is personalized, the user is usually the right unit for inference.

CTR alone is not the goal

A strong answer treats CTR as an intermediate metric, not the business objective.

For Pinterest-style surfaces, engagement quality can include:

pin clicks
saves
closeups
outbound clicks
follows
board adds
video starts
video completes
Shopping product clicks
return visits

A +3% CTR result does not mean the launch is good. If saves are flat and hide or report rates get worse, you may have made the feed more clickbaity rather than more useful.

That is why you need a metric hierarchy.

Build a metric hierarchy before you interpret anything

A clean interview answer usually has three layers:

1. Primary success metric

Pick the metric closest to user value for that surface.

Examples:

saves per user
engaged sessions per user
shopping-engaged sessions
product detail clicks per user

2. Diagnostic metrics

These tell you where movement came from.

Examples:

impressions per user
module visibility
viewport rate
click position
downstream save rate

3. Guardrails

These stop you from shipping a bad tradeoff.

Examples:

hides
reports
session exits
latency perception
creator or content diversity
overall home feed engagement
retention

If you list ten metrics without saying which one decides the launch, your answer will sound scattered.

Exposure definition is where a lot of people fail

In ranking systems, "impression" is often the hardest metric to define correctly.

An impression should mean the user had a reasonable chance to see the item. It should not mean "the server ranked it."

For a carousel, you should distinguish between:

module rendered
module in viewport
item impression
click
post-click engagement

That distinction matters because a ranking or UI change can alter the denominator mechanically. If more items count as impressions because users scroll farther or because the module renders differently, CTR can fall even if the product got better.

Watch for denominator effects

This is one of the best points you can bring into an interview.

Suppose a recommendation launch shows more content lower in the feed. You may get:

more impressions per user
more clicks per user
more saves per user
lower raw CTR

That is not contradictory. The denominator grew faster than the numerator.

So when CTR drops, do not stop there. Look at both rates and volumes:

CTR
clicks per user
impressions per user
saves per user
save rate

A strong candidate says, "I want to know whether user value fell, or whether the exposure mix changed."

How to talk about experiment design

For personalized feeds, randomize at the user level.

Why? Because recommendation exposure and engagement history are correlated across sessions. Item-level randomization can create an inconsistent user experience and can contaminate training signals.

You should also mention experiment validity checks:

randomization balance
ramp timing
sample ratio mismatch
pre-period comparability

If the assignment is broken, the metric read is not trustworthy.

For surfaces with social or marketplace effects, spillovers can matter. In those cases, you may need to think beyond pure user-level analysis and discuss creator-level or geo-level effects.

Match the stats method to the metric

Interviewers like this because it separates people who know product metrics from people who know how to analyze them.

Binary click outcomes can use proportion-style tests. But engagement per user is often:

heavy-tailed
zero-inflated
noisy

Common approaches include:

user-level means with robust standard errors
bootstrap
winsorization sensitivity checks
delta method for ratios

One important warning: do not treat clicks and impressions as independent row-level observations when you analyze ratio metrics. That usually gives false confidence.

You should also mention power and minimum detectable effect. Tiny CTR lifts can be statistically significant on high-traffic surfaces and still be too small to matter for the business.

The sample size framing from the source is:

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

where $\Delta$ is the minimum detectable effect.

The right follow-up is, "What effect size would change a launch decision?"

CUPED is worth bringing up

If the interviewer asks how to improve experiment sensitivity, CUPED is a solid answer.

The adjustment is:

$$Y_{adj}=Y-\theta(X-\bar{X}),\quad \theta=\frac{Cov(Y,X)}{Var(X)}$$

Use it when pre-period behavior predicts post-period behavior and treatment cannot affect that pre-period covariate. It is especially useful for noisy user-level metrics like saves per user or Shopping clicks.

You do not need a long derivation. Just show that you know when it helps.

A good framework for "CTR dropped after a recommendation launch"

This is the kind of case question you might get directly.

A solid structure has four parts:

1. Validate the metric path

Ask how impressions and clicks are defined.

Check:

ranked impression vs viewport impression
deduping rules
whether the new system changed logging or counting logic

2. Validate the experiment

Ask whether it was an A/B test or full rollout.

Check:

randomization balance
sample ratio mismatch
pre-period similarity
ramp timing

3. Decompose the funnel

Since:

$$CTR = \frac{\text{clicks}}{\text{impressions}}$$

ask:

Did clicks fall?
Did impressions rise?
Did position mix shift toward lower slots?
Did visibility or viewport rates change?

4. Segment for diagnosis

After checking the overall result, cut by:

new vs returning users
heavy vs light users
platform
country
content type
fresh vs evergreen content
video vs static
shopping-intent users
position or session intent

The key judgment call is this: lower CTR may be acceptable if deeper value improves. If saves per user, long-clicks, Shopping conversions, or retention go up while low-quality clicks go down, "CTR dropped" is not enough reason to roll back.

The Shopping version of this question

For a Shopping launch, CTR is even less likely to be the final metric that matters.

Primary metrics may shift toward:

product detail clicks per user
merchant outbound clicks
add-to-cart proxies
shopping-engaged sessions

And your guardrails still matter:

overall home feed engagement
user trust
retention
cannibalization of organic pin engagement

You should also mention heterogeneity. Users with shopping intent may benefit, while casual browsers may see irrelevant commerce content. That changes how you think about targeting and interpretation.

Common mistakes

Treating CTR as the business goal

It is usually a diagnostic or intermediate metric.

Ignoring exposure changes

A CTR drop can come from more low-intent impressions, different positions, or a new UI module.

Listing metrics without a decision rule

Say what is primary, what is a guardrail, and what tradeoff is acceptable.

A much better interview line is:

"Launch if saves per user or shopping-engaged sessions improve without meaningful degradation in retention, home feed engagement, or negative feedback."

Final takeaway

If you get a CTR question in an interview, do not answer it like a spreadsheet exercise. Define exposure carefully. Use user-level reasoning. Check denominator effects. Separate shallow clicks from meaningful engagement. Then make a decision with guardrails, not with one ratio.

If you want the original concept note, formulas, and interview framing, read the full PracHub post on CTR and engagement metrics. If you want more practice in this style, PracHub also has a set of interview questions on metrics, experimentation, and product data science.

Meta Data Scientist Interview Cheatsheet 2026

Feng Zhang — Sun, 24 May 2026 04:01:10 +0000

If you're preparing for Meta data scientist interviews, one pattern shows up fast: the bar is not "can you compute a metric?" It is "can you define the right metric, design a clean experiment, and explain tradeoffs like an owner?"

This article pulls together the most interview-relevant parts of PracHub's Meta Data Scientist interview prep guide, with a focus on areas candidates often get pressed on: notification analytics, A/B testing, cluster randomization, and SQL event logs.

What Meta interviewers are usually testing

Across technical screens and onsites, the questions often sound broad:

"How would you evaluate similar-listing notifications?"
"Design an experiment for a new ads ranking model"
"Write SQL to compute engagement or call metrics"
"What would you do if there is interference between users?"

The underlying skill is the same. You need to move from raw events or product ideas to a decision-ready analysis. That means:

defining eligibility
choosing a randomization unit
picking a primary metric
adding guardrails
checking whether the observed impact is actually incremental

If your answer stays at the dashboard level, it will usually feel weak.

Notification analytics is a causal question, not a CTR question

A common interview prompt is some variation of push notifications or similar-listing alerts. The mistake many candidates make is optimizing for click-through rate.

That is too shallow.

For notification products, Meta cares about whether the notification creates net value or just interrupts people enough to get clicks. A strong answer breaks the system into a funnel:

eligibility
send
delivery
impression or open
click
landing-page engagement
downstream action
longer-term retention

For a marketplace notification, downstream actions matter more than raw clicks. Examples from the source include:

listing_view
save
seller_message
offer_sent
purchase_intent
transaction_proxy

If the product goal is better buyer discovery, then a better primary metric than notification_click_rate might be:

incremental qualified_listing_views_per_user
buyer_seller_message_threads_per_eligible_user

That framing shows you understand the product mechanism.

Guardrails matter more for notifications than people think

Notifications impose an attention cost. Your answer should include guardrails such as:

push_opt_out_rate
notification_disable_rate
app_uninstall_rate
hide_report_rate
negative_feedback_rate
session_depth
7d_retention
total notification volume per user

If you ignore fatigue, your experiment design looks incomplete.

Be precise about eligibility and exposure

Another common failure mode is saying, "compare users who got notifications with users who didn't."

That comparison is biased. Users who receive notifications are often already more active, have permissions enabled, or have more relevant inventory available.

A better answer starts with a fixed eligible population, for example users who:

viewed or saved a marketplace item in the last 7 days
have push permissions enabled
have at least one similar listing available

Then analyze intent-to-treat on randomized eligible users. You can inspect treatment-on-treated later, but only with the right causal caveats.

Watch for cannibalization and spillovers

A similar-listing notification can shift behavior from search, organic feed, saved items, or other notification channels rather than create new demand. So you should measure total marketplace engagement, not only attributed notification clicks.

If the product has social, household, or marketplace spillovers, say that directly. That is often when an interviewer pushes into cluster randomization.

A/B testing answers need an estimand, not just a p-value

Meta interviewers want to hear that you can design an experiment before data exists, not just analyze one afterward.

Start with the decision and the causal quantity. In plain terms: what launch decision does this test inform, and for whom?

For many interview prompts, your structure can be:

Define the product change and eligible population
Choose a randomization unit
Name the primary metric
Add guardrails
Discuss power, variance, and diagnostics
Explain how you'd interpret null or mixed results

Choose the randomization unit based on interference risk

User-level randomization is often fine for isolated product changes. It is not automatically correct.

If one user's treatment can affect another user's outcome, then SUTVA may fail. In Meta-style products, that comes up in:

social feeds
messaging
ads auctions
marketplaces
creator ecosystems

In those cases, you may need cluster, geo, advertiser, page, or marketplace-level randomization.

If you say, "I'd use user-level randomization if interference is low, otherwise I'd consider cluster or geo designs," that is already much stronger than forcing every problem into a 50/50 user RCT.

Power should be discussed at the right level

For repeated notifications or clustered experiments, observations are correlated. You should talk about power at the user or cluster level, not at the event level.

The source also calls out the design effect for clustered experiments:

DE = 1 + (m - 1)rho

where m is average cluster size and rho is intracluster correlation.

That matters because a huge row count can still translate into a much smaller effective sample size.

CUPED is worth mentioning if the prompt invites depth

For noisy product metrics, pre-experiment covariates can reduce variance. The source mentions CUPED, which adjusts outcomes using pre-period behavior. You do not need to derive it in every answer, but mentioning it in a Meta interview often signals practical experiment experience.

Use it when the pre-period metric strongly predicts the post-period metric, such as engagement, spend, or retention.

How to answer a "similar-listing notifications" question

A solid answer could sound like this:

First, clarify the product goal. Are you trying to increase discovery, transactions, or re-engagement among users with shopping intent?

Next, define the eligible population: users who recently viewed or saved an item, have push permissions on, and have relevant similar inventory available.

Then propose user-level randomization if interference is limited. Treatment users receive similar-listing pushes, control users stay on the current notification policy.

Pick a primary metric tied to downstream value, like incremental qualified_listing_views_per_eligible_user or buyer_seller_message_threads_per_user.

Use secondary metrics like:

notification_open_rate
save_rate
return_sessions

Add guardrails:

push_opt_out_rate
notification_settings_disable_rate
hide_report_rate
notifications received per user
7d_retention

Then say you'd analyze ITT first, check whether gains are incremental versus cannibalized from existing surfaces, and look at heterogeneous effects by intent, notification sensitivity, and inventory density.

That answer is much closer to what interviewers want than "I'd compare CTR between treatment and control."

SQL event log questions are mostly about grain and joins

The SQL side of the interview is less about syntax tricks and more about getting metric definitions right.

The source's advice is simple and useful:

1) Decide the grain first

Know what one row means before you write code:

user-day
call-day
impression-day
country-day

A lot of mistakes come from skipping this step.

2) Be careful with time windows

Use bounded windows like:

event_ts >= start
event_ts < end

That avoids double counting midnight events.

3) Aggregate before joining when needed

Joining raw event tables too early can multiply rows and inflate clicks, responses, revenue, or duration.

4) Protect ratio calculations

Use safe denominators and be explicit about what happens when the denominator is zero.

5) Clarify deduplication rules

If the metric requires one valid event per entity or one response per user, say how you would dedupe, often with ROW_NUMBER().

These are basic ideas, but they come up constantly in product analytics interviews.

What candidates most often miss

From the source, the recurring weak spots are:

optimizing for CTR alone
being vague about eligibility or exposure
ignoring interference and repeated treatment
assuming every experiment should be user-level 50/50
treating a null result as proof of no effect
skipping diagnostics like sample ratio mismatch, logging sanity, or pre-period balance

If you avoid those, your answers already sound more senior.

A better way to use a cheatsheet

Don't memorize lines. Practice turning these patterns into spoken answers.

Take a prompt like notifications, ads ranking, or call metrics, and force yourself to answer in this order:

goal
population
unit of randomization
primary metric
guardrails
power and inference risks
interpretation

If you want more realistic drills, PracHub also has interview practice questions here.

And if you're preparing specifically for Meta, the full Meta Data Scientist interview prep guide on PracHub is the better reference because it keeps these topics in one place and ties them to actual interview-style prompts.

System Design 101

Feng Zhang — Tue, 05 May 2026 03:44:03 +0000

System design is one of those skills people try to speedrun, then realize that it just does not work that way.

This article is adapted from a PracHub post on System Design 101, and the point is simple: if you want to get good at system design, real work matters more than polished tutorials.

A lot of interview prep material makes system design look like a set of reusable templates. Some patterns do repeat, but strong interview performance usually comes from having seen real systems, real constraints, and real tradeoffs.

Real system design experience beats tutorial knowledge

The fastest way to build system design judgment is through work:

building systems yourself
reading designs from other teams
seeing what failed in production
understanding why one approach beat another

That is very different from memorizing a "design Twitter" or "design Uber" walkthrough.

The source article makes a good point here. The author had led several designs that later showed up as classic interview questions. The value was not that they had seen the question before. It was that they had already gone through the parts most prep content skips:

implementation details
tradeoffs between candidate solutions
hardware assumptions
load test results
production pitfalls

That is why experienced engineers often sound more convincing in system design interviews. They are not reciting. They are talking about work they have done.

Breadth vs depth depends on your level

One useful part of the original post is the distinction between mid-level and senior interviews.

If you are mid-level

System design interviews usually test breadth more than depth.

You can pass without knowing every technology in detail. You do need to propose a reasonable solution, explain your choices, and avoid obvious mistakes. Interviewers are usually looking for sane architecture, good data flow, and awareness of tradeoffs.

If you are senior or above

Breadth alone is not enough.

You need depth too. You should be able to support decisions with experience, data, and a clear explanation of failure modes. If there is a gap in an area that matters to the problem, it can hurt a lot more at senior level than it would at mid-level.

That also changes how you should grow your career.

How to build system design skill through your job

The advice here is practical.

Early in your career, moving across teams or projects can help you build breadth. You see different architectures, constraints, and patterns. Later, staying longer in a domain helps you build depth. That is where you start to understand the details that separate an okay design from one that holds up under load.

Over time, a lot of concepts connect:

data modeling affects scaling choices
workload shape affects storage design
consistency requirements affect architecture
cost and capacity affect almost every decision

If your current role gives you none of that, it is fair to ask whether it is the right place for your growth.

What to study first

The source recommends a small set of resources and is honest about their limits.

1. Designing Data-Intensive Applications

DDIA is the foundation.

People often call it the bible of system design, but a better way to put it is that it is a starter book for distributed data systems. That is still very valuable. Most system design interviews are really about data:

what data exists
how much of it there is
how it is accessed
how it is stored
what integrity guarantees matter

DDIA helps you build that mental model.

It will not hand you interview answers. It is weaker on batch and stream processing, so you may need other material if you want more depth there.

2. System Design Primer

The System Design Primer is useful for beginners.

The warning from the source is fair: because it is crowd-sourced, some content has errors. Read it critically. Use it to learn concepts, not as something to memorize word for word.

3. Classic distributed systems papers

The source specifically calls out:

GFS
MapReduce
Bigtable
DynamoDB

If you have never read these, they are worth your time. They shaped a lot of what later systems and interview discussions borrow from.

4. Other books

The source also mentions "Designing Distributed Systems" and books focused on Kafka, Flink, or real-time analytics. The take is measured. They can help fill gaps, but DDIA and classic papers give you the stronger base.

Learn from real production cases

One of the best suggestions in the source is to study production systems from large companies.

If you work at a company with mature infrastructure, read internal design docs from other teams. If you do not, company engineering blogs and conference talks are the next best thing.

Good sources include:

company tech blogs from firms like Uber and Dropbox
InfoQ talks
architecture talks from companies like Google, Meta, and Amazon

You will not always get full schema details. Companies are careful about that. Still, these materials are closer to how systems are actually built than many interview prep articles.

Be selective with popular prep resources

The original post has opinions here, and they are useful.

Grokking is okay for basic concepts and the ID generator example, but the rest is not worth much.
Alex Xu's first book is too shallow.
The second book has more content, but quality is uneven.
The "System Design Interview" YouTube channel has a good rate limiter video, but at least one Top K solution is described as outdated enough to fail interviews.

That may sound harsh, but it matches what many engineers eventually learn: a lot of system design content is polished, simple, and incomplete.

What interviews usually care about

Most system design interviews revolve around data.

A clean way to think about the discussion is:

What are the requirements?
What data do you need to support them?
What are the size and access patterns of that data?
How will you store, retrieve, and protect it?

That is why so many weak system design answers feel off. They jump straight to components like Kafka, Redis, or sharding without first getting the data model and access patterns right.

A good interview answer should show:

reasonable infrastructure choices
correct data flow
a clear thought process

Pattern recognition matters, but only after understanding the problem

You will start to notice that many interview questions share structure.

The source gives one example: group chat and multiplayer card games can have similar data handling patterns. That is a useful observation. Still, pattern matching only helps if you actually understand the data and requirements. Otherwise you end up forcing the wrong template onto the problem.

Capacity estimation: interviews vs real work

This distinction is useful.

At work, capacity planning should be precise enough to support scaling and cost decisions. In interviews, order-of-magnitude estimates are often enough:

GB or TB?
thousands or millions of QPS?

Those estimates shape your technical choices.

If you are interviewing for senior roles, being able to do more exact back-of-the-envelope math and tie it to infrastructure choices and cost is a strong signal.

Case studies worth reviewing

The source recommends examples that do not skip schema design, which is a good filter. If the data model is vague, the rest of the architecture is often weak too.

Examples called out in the post:

Rate limiter, especially the well-known YouTube walkthrough
Chat application case study
Job scheduling system case study

The rate limiter example is considered solid for interviews, but the source notes a few missing angles, like local rate limiters as safeguards and deeper thinking around CPU or memory-based limits.

The chat and job scheduling writeups are described as good enough for entry-level interviews, with some flaws but stronger than many articles written by people with more authority and less substance.

If you want prompts to practice with after reading, PracHub also has a set of interview questions here.

The takeaway

System design skill comes from accumulated exposure to real systems.

Books help. Papers help. Interview case studies help. But the biggest jump happens when you build something, operate it, measure it, and learn what broke.

That is also the standard you should use in interviews. Your answer should sound like something you would actually build at work, not a guess assembled from buzzwords.

If you want the original version of these ideas, the source post on PracHub is here: System Design 101.

Most Common Amazon Interview Questions by Role (2026)

Feng Zhang — Tue, 05 May 2026 03:42:03 +0000

Amazon runs a different interview loop than most big tech companies. The technical bar matters, but the behavioral bar is unusually high. Every round, including coding and design, checks for Leadership Principles.

If you are preparing for Amazon, this role-by-role breakdown from PracHub is a good starting point: Most Common Amazon Interview Questions by Role (2026).

What the Amazon interview process looks like

The structure is fairly consistent across roles:

Online Assessment (OA)
For SDE roles, this is usually 1-2 coding problems. For data roles, expect SQL and analytics-style questions. It is timed, often around 90 minutes.
Phone screen
Usually one technical question and 1-2 behavioral questions tied to Leadership Principles.
Onsite, usually a virtual loop
Expect 4-5 rounds, each around 45-60 minutes. Every round includes at least one behavioral question. One interviewer is the Bar Raiser, a trained interviewer from another team who can veto the hire.

That last point matters. Amazon does not treat behavioral as a warm-up. It is part of the decision in every round.

SDE interviews: coding first, behavior in every round

For Software Development Engineer roles, the process is coding-heavy, but behavioral prep is mandatory.

What shows up most often in coding rounds

PracHub has 160 Amazon coding questions in its dataset, and the common topics are pretty predictable:

Arrays and strings
Two pointers
Sliding window
Trees and graphs
BFS and DFS
Lowest common ancestor
Dynamic programming, usually medium difficulty
Data structure implementation, such as LRU cache

One thing that catches people off guard is the framing. Amazon often wraps standard problems in practical business scenarios like:

warehouse optimization
delivery routing
inventory management

The underlying problem may still be a graph traversal or a sliding window question, but the prompt sounds like an operations problem.

System design for SDEs

PracHub lists 48 Amazon system design questions. The recurring themes are very Amazon-shaped:

Design an order management system
Design a product recommendation engine
Design a delivery tracking system
Design a pricing system with real-time updates

These are not abstract whiteboard exercises. You need to connect technical choices to scale, reliability, latency, and business impact.

Behavioral topics that come up again and again

PracHub tracks 122 Amazon behavioral questions, and some Leadership Principles show up far more often than others:

Customer Obsession
Ownership
Dive Deep
Bias for Action
Deliver Results

Interviewers explicitly map your answers to these principles. They take notes on what you demonstrated, then compare impressions across the loop. If your examples are vague, you will feel that quickly.

Data Scientist interviews: SQL, experiments, and product metrics

Amazon Data Scientist interviews have a different balance. You still need strong behavioral answers, but the technical side leans toward analytics, experimentation, and applied ML.

PracHub's Amazon set includes 65 SQL questions and 71 ML questions. Common examples include:

"Write a query to calculate customer lifetime value"
"Design an experiment to test a new recommendation algorithm"
"How would you detect fraudulent seller accounts?"
retention analysis
funnel analysis
cohort analysis

What Amazon tends to care about in ML rounds

The ML areas called out in the source are tightly tied to Amazon's product and marketplace model:

recommendation systems
fraud detection
demand forecasting
NLP for review analysis
search ranking

This is useful because it tells you where to focus. If your prep is centered on generic model trivia, you may miss what Amazon actually asks, applied questions tied to user behavior, marketplace integrity, or retail operations.

Product sense matters more than many candidates expect

Amazon DS interviews put real weight on product metrics. You need to explain how success is measured and how you would test changes. That means being comfortable with experiment design, tradeoffs in metrics, and the business meaning behind your analysis.

If you answer with technical detail but cannot define the right success metric, that is a problem.

Data Engineer interviews: heavy SQL and reliable pipelines

Data Engineer interviews at Amazon are very SQL-heavy. The source is direct about that, and it lines up with what candidates usually report.

Expect questions around:

complex SQL on large datasets
query optimization
data modeling, such as star schema for e-commerce data

The design side focuses on data systems, not general backend design.

Common pipeline design themes

Typical prompts include:

Design an ETL pipeline for order data
Handle late-arriving data
Design a data quality monitoring system
Migrate from batch to real-time processing

Amazon cares about scale and reliability here. A clean architecture diagram is not enough. You need to explain what happens when jobs fail, when data arrives late, when retries create duplicates, or when upstream quality drops.

If you skip failure modes, your answer is incomplete.

What applies to every Amazon role

Some prep advice is role-specific. Some is universal.

1. Prepare 12-15 STAR stories

This is the biggest pattern in Amazon prep. You need a bank of stories mapped to Leadership Principles.

The source is blunt on this point. It is not optional.

A lot of candidates prepare hard for coding or SQL, then improvise behaviorals. That is a bad tradeoff for Amazon. Since every round includes behavioral questions, weak stories can sink an otherwise strong loop.

2. Be precise with metrics

Amazon is data-driven, and interviewers expect specifics. "We improved performance" is weak. "We cut latency by 28%" is useful.

The same applies to product work, incident response, project delivery, and system design. Use numbers whenever you can. If your example has no measurable result, it will sound unfinished.

3. Think in terms of the flywheel

This comes up most often in system design and product discussions. Amazon likes reasoning that connects technical choices to business outcomes through reinforcing loops.

If your design improves delivery speed, does that improve customer trust, which drives more usage and increases operational efficiency? That style of thinking tends to land well in Amazon interviews.

4. Understand what the Bar Raiser is doing

The Bar Raiser is not there to fill a seat for one team. This person is judging whether you meet Amazon's hiring standard overall.

That usually means close attention to Leadership Principles, quality of judgment, and consistency across rounds. If one round says you show strong Ownership and another suggests the opposite, that will come up in the final discussion.

How I would prep, based on this breakdown

If I were targeting Amazon, I would split prep like this:

Build a Leadership Principles story bank first
Practice role-specific technical questions second
Rehearse answers with numbers, tradeoffs, and clear outcomes
For design rounds, tie the system back to customer impact and business metrics

I would not prep from random lists alone. Amazon patterns are role-dependent. SDE, DS, and DE loops overlap on behaviorals, but the technical expectations are clearly different.

If you want to practice against a large role-specific set, PracHub has Amazon questions across coding, behavioral, ML, SQL, and system design here: interview questions on PracHub.

The useful part is the distribution: 160 coding, 122 behavioral, 71 ML, 65 SQL, and 48 system design questions from Amazon. That makes it easier to focus on what your target role is likely to test instead of studying everything equally.

For the full role-by-role breakdown, go back to the original PracHub post: Most Common Amazon Interview Questions by Role (2026).

Machine Learning Interview Questions: Complete 2026 Guide

Feng Zhang — Tue, 05 May 2026 03:40:02 +0000

ML interviews are more practical than they were a couple of years ago.

You still need to know the classic topics, bias-variance tradeoff, regularization, cross-validation, evaluation metrics. But many interview loops now spend more time on applied questions: how you would build a model for a real product, what features you would choose, how you would evaluate it after launch, and what you would do when offline metrics do not match production behavior.

This article is adapted from PracHub's Machine Learning Interview Questions: Complete 2026 Guide, which is based on a large set of ML interview questions collected by company and role.

What ML interviews actually cover

Based on 583 ML questions on PracHub, the distribution looks roughly like this:

Fundamentals, 30-40%

This is still the largest bucket. If your basics are shaky, it shows fast.

Topics include:

Bias-variance tradeoff
Overfitting and regularization, especially L1 vs L2
Cross-validation strategies
Evaluation metrics like precision, recall, F1, and AUC-ROC
Gradient descent and optimization

Interviewers usually do not stop at definitions. If you say "bias is underfitting and variance is overfitting," expect follow-ups. How would you detect each from training and validation behavior? What changes would you try? Why would regularization help?

Applied ML, 25-30%

This part is where many interviews now feel more like product work than classroom theory.

Common themes:

Feature engineering for a specific problem
Model selection, and when to use one class of models over another
Handling imbalanced data
Missing data strategies
A/B testing ML models

You might get a prompt like: "Build a churn model for this subscription product." From there, the interviewer wants your full thought process. What is the target? What counts as churn? What data would you collect? Which features are likely to be predictive? What metrics matter to the business?

ML system design, 15-20%

This section is hard to avoid for many ML roles.

Typical prompts:

Design a recommendation system
Design a fraud detection pipeline
Design a search ranking system
Design an ad click prediction system
Explain model serving and monitoring

This is not the same as backend system design, though there is overlap. You need to think through the ML pipeline end to end: data ingestion, feature generation, training, model registry, deployment, serving, monitoring, and retraining.

Coding, 10-15%

For most ML interviews, coding is not algorithm-heavy.

Expect:

Implementing a simple model from scratch, such as logistic regression or k-means
Data manipulation with pandas or numpy
Writing a training loop
Feature processing code

If you only practice LeetCode, this round can still catch you off guard. A lot of candidates are weaker in the kind of code they actually write on the job.

Deep learning, 10-15%

This depends on the role, but deep learning questions are common enough that you should prepare.

Topics include:

Transformers and attention
CNNs vs RNNs vs Transformers
Transfer learning and fine-tuning
LLM-related questions, which are becoming more common in 2026

For deep learning roles, expect more depth. For general ML roles, interviewers often want a clean explanation of why these architectures differ and where each one fits.

Company-specific patterns

The mix changes a lot by company.

Amazon

PracHub has 71 ML questions from Amazon, and the pattern is pretty clear. Amazon is heavy on applied ML.

You may be asked how to:

Build a recommendation system for product pages
Detect fraudulent reviews
Optimize delivery routing

The style is practical and business-oriented. You need to connect the model to the user problem and the company metric.

Google

Google has 36 ML questions on PracHub, and the interviews tend to be more theoretical than Amazon or Meta.

That usually means:

Derivations
Why an algorithm works
Mathematical foundations
ML infrastructure and model serving

You still need applied thinking, but the bar for explaining the underlying mechanics is usually higher.

Questions that keep coming up

Some questions appear across multiple companies with only minor changes in wording.

These are worth practicing until your explanation feels natural:

Explain the bias-variance tradeoff. How do you diagnose which one your model suffers from?
When would you use logistic regression over a random forest?
Your model has high AUC-ROC but low precision. What is going on? What do you do?
How would you handle a dataset where 1% of examples are positive?
Design a recommendation system for a specific product. Walk through the full pipeline.
How do you decide which features to include in your model?
Explain L1 vs L2 regularization. When would you use each?
Your model performs well offline but poorly in production. What could cause this?
How do you A/B test a machine learning model?
Explain how a transformer works. Why has it replaced RNNs for most NLP tasks?

If you look at that list, the pattern is obvious. Interviewers are checking a few things:

Do you understand the foundations?
Can you reason through messy real-world modeling decisions?
Can you think beyond training accuracy and talk about production behavior?

How to prepare without wasting time

1. Get sharp on fundamentals

You need to explain core concepts in your own words.

That means more than memorizing definitions. If someone asks about regularization, you should be able to explain what problem it addresses, how L1 and L2 differ, and what changes you would expect in model behavior. Same for metrics. If an interviewer asks why precision matters more than accuracy in a certain problem, your answer should come quickly.

A good test is whether you can survive a couple of follow-up questions after your first answer.

2. Practice applied case studies

This is where practical experience shows up.

Take a business problem and walk through it step by step:

Problem formulation
Data collection
Feature engineering
Model selection
Evaluation
Deployment
Monitoring

Do not jump straight to "I would use XGBoost" or "I would fine-tune a transformer." Start with the problem definition and constraints. A weaker candidate talks tools first. A stronger one frames the task properly.

3. Treat ML system design as its own topic

A lot of candidates prepare for theory and forget the pipeline.

For ML system design, make sure you can talk through:

Data ingestion
Feature store
Training pipeline
Model registry
Serving infrastructure
Monitoring
Retraining

You should be able to draw this on a whiteboard or explain it verbally without getting lost. The best answers are structured and realistic.

4. Practice the coding you actually use in ML work

You probably will not get a LeetCode-hard graph problem.

You are more likely to get:

pandas and numpy work
Basic model implementation
Training loop logic
Feature transformation code

That means your prep should include notebook-style coding, not just algorithm drills.

A better way to use question banks

Grinding random questions is not that useful unless you know what pattern each question is testing.

A better approach is to group your prep by category:

Fundamentals
Applied ML
System design
Coding
Deep learning

Then practice answering out loud. For system design and applied ML prompts, force yourself to give complete end-to-end answers.

If you want a large set of company-tagged practice material, PracHub has a collection of ML interview questions organized by role, company, and difficulty. The same source guide also notes that PracHub has 225 ML system design questions, which is useful because that category is harder to find in one place.

Final takeaway

The main shift in ML interviews is that you need both theory and judgment.

You still have to know the standard concepts. But that is only the baseline. Strong performance now depends on whether you can connect those concepts to product decisions, production constraints, and model behavior after deployment.

If you want the original breakdown and source data, read PracHub's full Machine Learning Interview Questions: Complete 2026 Guide.

How to Answer "What is Your Greatest Weakness?" in a Tech Interview

Feng Zhang — Tue, 05 May 2026 03:38:02 +0000

Most candidates still treat "What is your greatest weakness?" like a trap. In tech interviews, it usually isn't. It's a check for self-awareness and humility. Interviewers want to see whether you can name a real weakness, explain how it affects your work, and show that you manage it with a repeatable process.

The original PracHub guide gets this right: a good answer has three parts, and the last one matters most.

If you answer with "I'm a perfectionist" or "I work too hard," you'll sound rehearsed. If you name a weakness that makes you unqualified for the role, you'll hurt yourself. The sweet spot is a genuine, non-critical weakness plus a concrete system that keeps it from hurting your team.

What interviewers are actually testing

At companies with structured interview loops, including FAANG-style processes, this question usually comes down to three things:

Self-awareness
Intellectual humility
Your ability to respond to feedback

Every engineer has blind spots. The interviewer knows that. What they want to learn is whether you can talk about yours without getting defensive or turning the answer into a humblebrag.

That means your answer should sound honest, specific, and current. You are not confessing failure for drama points. You are showing that you understand how you work.

A simple framework that works

A strong answer is usually 60 to 90 seconds. Longer than that, and you risk rambling.

Use this three-step structure.

1. State the weakness directly

Say what the weakness is in plain language.

A good opening is:

"In the past, I have struggled with [specific weakness]."

Keep it clean. Do not apologize. Do not instantly spin it into a strength.

2. Explain how it showed up in your work

Next, tie the weakness to real engineering work. This is the part many people skip, and that's what makes the answer sound fake.

Use a pattern like:

"When I'm working on [type of task], I tend to [negative action], which causes [negative impact]."

This shows that you understand the cost of the weakness, not just the label.

3. Spend most of the answer on your mitigation system

This is the part interviewers care about most.

Do not say, "I'm working on it." Say what you actually do.

A useful pattern is:

"To mitigate this, I now [specific system or action]. Since I started doing that, [positive result]."

The key word here is system. A calendar rule. A design-doc habit. A review process. A communication trigger. A debugging cutoff. Something concrete.

Three examples for software engineers

These examples work because they are believable and process-driven.

Junior engineer: getting stuck too long before asking for help

If you are early in your career, a common weakness is trying to solve every bug alone.

A solid answer sounds like this:

"My biggest weakness has been staying stuck on a bug for too long before asking for help. Early in my current role, I would spend two or even three days debugging a pipeline issue because I did not want to interrupt senior engineers. I realized that was slowing down the sprint and making the problem more expensive than it needed to be. To fix that, I use a 'One Hour Rule.' If I am blocked for more than an hour, I write down what I tried and post it in Slack with context. That way I am not asking vague questions, but I am also not failing silently. It has improved how quickly I close tickets."

Why it works: it is honest, not fatal, and the mitigation is specific.

Mid-level engineer: over-engineering simple solutions

This one is common for engineers who care a lot about design.

Example:

"In the past, I have had a tendency to over-engineer. On some projects, I would build a more abstract or scalable solution than the requirements justified. That added complexity and slowed delivery on a project where a simpler CRUD implementation would have been enough. To manage that, I now use YAGNI as a hard check before I start coding. I write a short design doc that limits the scope to current business needs, and I ask a peer reviewer to call out any unnecessary abstraction. That has kept my designs more practical without lowering quality."

Why it works: the weakness is real, but it does not suggest incompetence.

Senior or Staff engineer: weak delegation on architecture work

At higher levels, your weaknesses are often about team growth and how work gets distributed.

Example:

"As I moved into a Staff-level role, one weakness I noticed was that I held onto critical architecture work instead of delegating it. I could move fast on those tasks myself, but it created a bottleneck and reduced growth opportunities for mid-level engineers on the team. I changed my process so that I no longer write the first draft of major design docs by default. I assign that draft to another engineer and review it instead. It can take a little longer upfront, but it spreads architectural ownership and removes me as the bottleneck."

Why it works: it shows maturity, not ego.

Four answers that usually fail

Some weaknesses are bad because they sound fake. Others are bad because they raise direct concerns about your ability to do the job.

Avoid these.

1. The humblebrag

Examples:

"I work too hard"
"I'm a perfectionist"

These are transparent. They signal dishonesty or weak self-awareness.

2. The fatal flaw

Examples:

"I hate writing tests"
"I struggle with basic algorithms"

If the weakness cuts into core job skills, it can sink your interview.

3. The blame answer

Example:

"I get frustrated when teammates write bad code"

This tells the interviewer you may be hard to work with. It suggests low empathy and weak collaboration.

4. The fixed-trait answer

Example:

"I'm just naturally disorganized"

This fails because it sounds permanent. The interviewer wants to hear a manageable work habit, not a personality verdict with no plan attached.

How to find a real weakness to use

If you are not sure what to say, look at past feedback.

Your performance reviews, 1:1 notes, or manager feedback are usually the best source. Focus on constructive feedback you have actually received, then convert it into the three-part framework.

For example:

"You need to communicate more during incidents"
"You should spend more time on documentation"
"You sometimes go too deep before aligning on scope"

Those are useful because they are real and specific. Once you add context and a mitigation system, they become strong interview material.

That is also why generic interview prep often falls flat. You do not need a clever answer. You need an honest one with some process behind it. If you want more prompts to practice this kind of response, PracHub has a useful list of tech interview questions here.

Does STAR work here?

You can force this answer into STAR, but it is usually awkward.

STAR is good for behavioral stories with a clear scenario and outcome. "Greatest weakness" is different. It is about an ongoing pattern in how you work. That is why the simpler structure, confession, context, mitigation, works better.

It keeps you focused on the present-day system, which is what the interviewer actually wants to hear.

A good answer has one job

Your answer does not need to impress anyone with drama or polish. It needs to show that you know your weak spots and that you do not leave them unmanaged.

That is what makes an answer credible:

The weakness is real
It is not disqualifying
You can explain its effect on your work
You have a concrete process that keeps it under control

If you want the original version with the sample answers and breakdown, read the full PracHub post here.

How to Answer 'Tell Me About a Time You Failed' in a Tech Interview

Feng Zhang — Tue, 05 May 2026 03:36:01 +0000

Most candidates overthink "Tell me about a time you failed." They assume the safest move is to soften the story, pick a harmless mistake, or package a "failure" that is secretly a strength.

That usually backfires.

In software interviews, especially for experienced engineers, a real failure is often better than a polished non-answer. Hiring managers are trying to figure out whether you can own mistakes, respond well under pressure, and put systems in place so the same issue does not happen twice. The best way to answer is like a blameless post-mortem, turned into a clear interview story.

This article is adapted from PracHub's guide on how to answer "Tell me about a time you failed" in a tech interview, but rewritten for a developer audience here.

What interviewers are actually looking for

This question is less about the failure itself and more about your judgment after it.

They want to know:

Can you admit a real mistake?
Did you act quickly when things started going wrong?
Did you hide, deflect, or blame other people?
Did you learn something specific?
Did you add a process or safeguard so the same class of mistake does not repeat?

If you say you have never failed, that is a red flag. If you give a fake answer like "I cared too much" or "I worked too hard," that is also a red flag. It suggests low self-awareness, low honesty, or not much experience with meaningful responsibility.

For senior engineers, real failures are normal. Production issues, bad estimates, wrong technical choices, delayed escalation, that all happens in real engineering work.

Use the blameless post-mortem structure

A strong answer is short, direct, and focused mostly on the lesson and the system change. You should usually keep it under three minutes.

A simple structure:

1. Transparent confession

Start with the mistake. Be plain about it.

Say what happened, what your role was, and what you got wrong. Use "I," not "we," if it was your error.

Good phrasing sounds like this:

"I made a mistake in a production deployment..."
"I failed to estimate the integration work correctly..."
"I chose the wrong technical direction for that service..."

Do not spend a minute building context before you admit the failure. Lead with it.

2. Immediate response

Next, explain what you did when the problem became obvious.

This tells the interviewer whether you are reliable under pressure. The main question is whether you protected users and the team before protecting your ego.

That can mean:

rolling back fast
escalating early
joining incident response
resetting expectations with stakeholders
admitting the estimate was wrong

Keep this part short. The point is that you responded directly and did not hide the issue.

3. Systemic fix

This is the part that matters most.

A weak answer ends after the incident is resolved. A strong answer explains how you fixed the system that allowed the mistake in the first place.

That system change might be:

a new automated test
a CI/CD check
a staging improvement
a design review rule
a proof-of-concept step before estimation
a decision framework for architecture

This is what makes your answer sound like engineering instead of apology.

Three strong examples

Here are three examples from common software engineering situations.

Production outage

A backend engineer could say:

"Two years ago, I caused a 15-minute partial outage on our checkout service. I deployed what I thought was a backwards-compatible database schema change, but I missed that an older microservice still depended on strict column ordering. That broke right after deployment.

As soon as I saw the 500 rate spike in Datadog, I triggered an automated rollback instead of trying to debug it live. I posted in the incident channel that I had caused the issue and focused on restoring service first.

The bigger problem was that our integration tests were using a mocked database instead of a real schema replica. After the post-mortem, I built a containerized test pipeline that validates schema changes against a production-like clone. Since then, we have not had another deployment issue from that category. The lesson for me was simple: if staging does not match production closely enough, your deployment confidence is fake."

Why this works: the candidate owns the outage, responds fast, and spends most of the answer on the process fix.

Missed deadline

A full-stack engineer could say:

"I failed to deliver an OAuth integration for a new enterprise client on time. I estimated two weeks because I assumed their Active Directory setup was standard. It was not, and we missed the launch date by more than a month.

I realized about a week into the sprint that I was blocked, but I made it worse by trying to push through on my own instead of escalating. Once it was clear I would miss the date, I told my manager and the client's solutions architect that my estimate had been wrong and that we needed to reset expectations.

The lesson was that I was estimating third-party integration work based on documentation, not proof. Since then, I do a short tracer-bullet spike before I commit to a delivery estimate. I use that time to prove the handshake works and the docs are accurate. That small step has made my integration estimates much more reliable."

Why this works: it shows ownership, admits bad judgment, and ends with a specific mechanism that changed future behavior.

Wrong technical choice

A senior engineer could say:

"I made the wrong foundational choice for a notification service I was leading. I picked MongoDB because write speed mattered most at the time. About a year later, the product needed relational analytics across notification history, and that database choice became expensive technical debt.

Once the problem was clear, I wrote a technical brief for the engineering director explaining that my original decision no longer fit the business need. I proposed a migration path to PostgreSQL and led the migration work so the rest of the team would not absorb all the disruption.

What I changed after that was our design process. For architecture decisions that are hard to reverse, like a primary datastore, I now require a "two-way door" analysis in the design doc. If the choice is hard to unwind, it has to be defended against a longer product horizon, not just the immediate sprint."

Why this works: it shows strategic judgment, not just incident handling.

Mistakes that will sink your answer

There are three common ways candidates ruin this question.

Shadow blame

Example: "I missed the deadline because QA was slow."

Even if other people were involved, the interview is about your judgment. Talk about what you could have done differently.

Fake failure

Example: "My biggest failure was working too hard."

Nobody believes this. Pick a real mistake with real consequences.

No root-cause fix

If your story ends with "then we fixed production," it is incomplete. The interviewer wants the mechanism you added so the same thing does not happen again.

That is why the post-mortem framing works so well. It moves the answer from confession to engineering judgment.

How much time to spend on each part

A good rule is this:

20 to 30 percent on the failure
20 to 30 percent on the immediate response
40 to 60 percent on the systemic fix and lesson

Do not turn this into a five-minute architecture walkthrough. Keep enough detail for the interviewer to understand the stakes, then get to the lesson.

What makes a good failure story

A good story is real, professional, and recoverable. It should show that you had enough responsibility to make a meaningful mistake.

Strong examples include:

a deployment that caused a minor outage
a project you estimated badly
a blocker you escalated too late
a technical decision that aged badly

The failure does not need to be dramatic. It does need to be honest.

Final advice

Before the interview, write out one story using this format:

What exactly failed?
What did you do right away?
What system did you change after the post-mortem?

Then practice saying it out loud until it sounds calm and direct.

If you want more examples and the original breakdown, PracHub's full post on answering "Tell me about a time you failed" is worth reading. You can also browse related interview questions on PracHub to practice other behavioral prompts in the same style.

Googleyness: What It Is and How to Pass the Google Behavioral Interview (2026)

Feng Zhang — Tue, 05 May 2026 03:34:00 +0000

Google's behavioral round has real veto power. You can do well in coding and system design, then still get rejected if your interview stories raise behavioral red flags.

The company calls this "Googleyness", and despite the goofy name, it is a pretty specific rubric. If you want the full original breakdown, the PracHub guide is here: Googleyness: What It Is and How to Pass the Google Behavioral Interview.

What matters most is this: Googleyness is not about being charismatic, quirky, or extra social. It is about how you work when things are unclear, how you react to feedback, whether you improve broken systems, and whether you protect the user when there is pressure to cut corners.

The 4 things Google is actually testing

In a Google interview loop, there is often a full 45-minute round dedicated to this area, usually called "Leadership and Rapport" or the Googleyness interview.

These are the four pillars behind it.

1. You can handle ambiguity

Google wants evidence that you can work through vague problems without waiting for perfect requirements.

A weak answer sounds like someone who got stuck because nobody told them exactly what to do.

A strong answer shows that you:

asked clarifying questions
found the right stakeholders
gathered missing data
created a structure for the problem
moved forward in iterations
stayed calm when scope changed

If your story is basically "the requirements were bad," that hurts you. If your story is "the requirements were unclear, so I created a plan and reduced uncertainty," that helps.

2. You value feedback and have intellectual humility

This one matters a lot. Google's engineering culture is heavy on review and debate. If you get defensive when your code or design gets challenged, that is a bad sign.

Interviewers want to hear that you can separate your identity from your output. If someone finds a flaw in your design, your instinct should be curiosity, not ego.

Good signals here include:

you asked for feedback before it was forced on you
you changed your approach after criticism
you can describe a mistake plainly
you can explain what you learned and what changed after it

Bad signals include blaming others, minimizing your role in a failure, or turning a mistake story into a fake humblebrag.

3. You challenge the status quo

Google likes engineers who fix things that are obviously broken.

That does not mean being argumentative. It means noticing weak processes, technical debt, poor onboarding, messy tooling, or inefficient handoffs, then doing something about them.

A good story here usually has two parts:

you noticed a problem outside your immediate ticket list
you pushed for an improvement without being told to

The interviewers are looking for initiative and standards. They want to know if you raise the quality bar around you.

4. You do the right thing for the user

This is the pillar people often describe too vaguely. Google is looking for candidates who protect user trust, even when business pressure points the other way.

Strong stories here might involve:

pushing back on a launch because quality was not there
arguing for accessibility work
raising security concerns
rejecting a product decision that would hurt users long term

The key is not moral grandstanding. It is showing that you can weigh tradeoffs and still defend the user when it counts.

What interviewers hear as strong vs weak signals

Google uses a structured rubric, so your story is not judged only on whether it sounds polished. The substance matters.

Here are the patterns that usually help or hurt.

Collaboration

Strong candidates use "I" for their actions and "we" for team outcomes. They share credit and talk about teammates with respect.

Weak candidates sound like lone wolves. They blame peers, take all the credit, or describe collaboration as a blocker.

Problem solving

Strong candidates bring structure to messy situations and validate assumptions with data.

Weak candidates freeze in ambiguity or rely on instinct without evidence.

Response to failure

Strong candidates own mistakes and focus on root cause and prevention.

Weak candidates explain why the failure was really someone else's fault.

Communication

Strong candidates can explain technical decisions clearly to non-technical people.

Weak candidates hide behind jargon or sound annoyed that others did not "get it."

Use STAR-L, not just STAR

For Google behavioral questions, STAR is useful, but STAR-L is better:

Situation
Task
Action
Result
Learnings

That last part matters more than many candidates expect.

Your interviewer will spend most of the time probing your actions. If you say, "I convinced the PM to change the roadmap," expect follow-ups like:

"What data did you use?"
"What was the pushback?"
"What did you say?"
"What would you do differently now?"

A solid structure looks like this:

Situation/Task, keep it short

Give enough context so the story makes sense. Do not spend two minutes on org charts and project history.

Action, spend most of your time here

This is where your Googleyness shows up. Be concrete. What did you do? What tradeoffs did you make? How did you handle disagreement, uncertainty, or feedback?

Result, quantify it if you can

Business impact, latency reduction, fewer bugs, faster release cycles, better adoption, whatever fits the story.

Learnings, make them real

Say what changed in your behavior after this. Google wants people who learn, not people who only narrate events.

Five questions you should expect

These come up often because each one maps cleanly to one of the traits above.

"Tell me about a time you had to solve a problem with unclear requirements."

This tests ambiguity. Your answer should focus on how you created structure, not on how frustrating the situation was.

"Tell me about a time you made a significant mistake."

This tests humility and feedback response. Pick a real mistake. Then spend most of your answer on root cause, post-mortem, and the safeguards you put in place after.

"Describe a time you strongly disagreed with a tech lead or manager."

This tests whether you can challenge decisions without becoming difficult to work with. Use data. Be respectful. Show that once a decision was made, you supported execution.

"Tell me about a time you improved a process outside your scope."

This tests initiative and standards. Good examples include internal tools, test bottlenecks, poor docs, or onboarding issues.

"Describe a time you pushed back because a feature was not right for the user."

This tests user-first judgment. Show the tradeoff clearly and explain how you argued for long-term trust, quality, accessibility, or security.

If you want more prompts to practice with, PracHub has a useful bank of interview questions here.

Google also looks for leadership, even if you are an IC

A lot of engineers hear "leadership" and assume it only applies to managers. That is not how Google evaluates it.

The company looks for emergent leadership in individual contributors too. That means you step up when the team is stuck, under pressure, or split on direction.

You can show that through stories about:

mentoring junior engineers
connecting teams that were misaligned
helping resolve a technical deadlock
guiding a project through a messy change in direction

The common thread is that you improved the group's ability to move forward, even without formal authority.

How to prepare without wasting time

The best prep is not memorizing polished lines. It is building a small set of flexible stories, usually 6 to 8, that you can adapt across multiple prompts.

Each story should make at least one of the four pillars obvious. Ideally, more than one.

Then say them out loud. Time yourself. A good first pass is under three minutes before follow-up questions.

Record yourself if you can. Most people think their answers sound structured until they hear themselves ramble through context and skip the learning. If you want the original PracHub guide again, with the rubric and question breakdown in one place, use this: Googleyness: What It Is and How to Pass the Google Behavioral Interview.

If your stories show ownership, humility, judgment, and calm under ambiguity, you are speaking Google's language. If they sound defensive, vague, or self-congratulatory, the interviewer will hear that too.

GenAI & LLM System Design Interview Guide (2026)

Feng Zhang — Tue, 05 May 2026 03:32:00 +0000

GenAI system design interviews are a different category from classic backend design rounds. You are not diagramming a CRUD app with a load balancer, a cache, and a sharded database. You are designing a system built around probabilistic model outputs, expensive inference, and retrieval quality that can make or break the answer.

If you are preparing for these interviews, especially for AI-heavy teams, the core skill is being able to design a RAG pipeline and explain the trade-offs clearly. The original PracHub guide on this topic is a solid reference if you want the interview-focused version: GenAI & LLM System Design Interview Guide (2026).

What changes in a GenAI system design interview

Traditional system design interviews usually focus on consistency, throughput, database partitioning, and API design. GenAI interviews shift the focus.

You need to reason about:

vector databases instead of only relational databases
semantic retrieval instead of exact-match lookup
GPU and token-generation constraints instead of mostly database I/O
evals and groundedness checks instead of only deterministic unit tests

That shift matters because the failure modes are different. In a normal backend system, if the data path is correct, the output is usually predictable. In a GenAI system, you can build a technically sound pipeline and still get a bad answer because retrieval brought in weak context or the model drifted off prompt.

Interviewers want to see whether you understand that difference early, before you start drawing boxes.

The prompt you are likely to get

A common version is: "Design a conversational AI agent for our enterprise knowledge base."

That prompt usually expects a RAG architecture. If your answer jumps straight to "I'll call an LLM API," you are missing the point. The interview is usually about how the system retrieves the right information, controls cost, handles latency, and limits hallucinations.

A practical framework for answering with a RAG design

1) Document ingestion and chunking

Start with the source documents. Enterprise data is rarely clean. It may come from PDFs, slide decks, internal docs, or exported wiki pages.

You should explain two things:

Parsing strategy

How do you extract text from messy files? The interviewer wants to know you recognize ingestion is not trivial.

Chunking strategy

You need to split documents into chunks before embedding them.

A good answer is to compare:

fixed-size chunking, such as 500-token chunks
semantic chunking, where splits happen at logical boundaries like paragraphs or sections

The trade-off is straightforward. Semantic chunking usually preserves context better. It also costs more to process and is harder to build well. That is the kind of trade-off interviewers expect you to name out loud.

2) The embedding layer

After chunking, you convert text into embeddings.

This is where you should state what kind of embedding model you would use. The source guide gives examples such as OpenAI's text-embedding-3-large or an open-source option like BGE if cost pressure matters.

Then store the vectors in a vector database with metadata. The metadata matters because retrieval is rarely pure semantic similarity. In an enterprise setting, you may need filters like:

document date
author
access level

That gives you hybrid retrieval, semantic search plus keyword or metadata filtering.

If you skip metadata entirely, your design will sound thin.

3) Retrieval and re-ranking

This part separates average answers from strong ones.

At query time, the system embeds the user's question and runs vector search. A reasonable explanation is: retrieve the top 50 chunks by cosine similarity.

Then comes the move that signals maturity: re-ranking.

Raw vector search is often noisy. Some of the top candidates will be loosely related but not actually useful. So you add a cross-encoder reranker, such as Cohere Rerank, to score those 50 results more precisely and reduce them to the best 5 before passing them to the LLM.

That second stage matters because it directly affects both quality and cost. Better retrieval means fewer irrelevant tokens in the prompt and a lower chance the model answers from weak context.

If you want to practice how to explain these retrieval choices under pressure, the PracHub interview question set is useful because it is built around this style of questioning.

4) Generation and orchestration

Now you build the final prompt using the selected chunks and send it to the LLM.

You can mention an orchestration layer like LangChain, but do not hide behind it. If you say "I'll use LangChain," expect follow-up questions about what actually happens in the retrieval flow.

A better answer is:

use an orchestration layer, possibly LangChain or a custom service
construct prompts with retrieved context
call the LLM
stream tokens back to the client with Server-Sent Events

Streaming matters because users care a lot about time-to-first-token. Even if total generation takes 15 seconds, the app feels faster if text starts appearing quickly.

The trade-offs that usually decide the round

The final part of the interview often comes down to trade-off analysis. This is where senior candidates usually pull ahead.

Inference cost

LLM pricing is token-based. If your architecture sends large prompts for every request, cost rises fast.

One concrete optimization from the source guide is semantic caching. If a user asks a question that is mathematically identical, or very close, to one asked a few minutes ago, you can return a cached answer instead of calling the LLM again.

That is a clean interview answer because it shows you are thinking beyond correctness. You are thinking about operating cost.

Latency and time-to-first-token

Retrieval is usually quick compared with generation. The system can find documents fast, then spend much longer waiting on the model.

You should explain that difference directly, then say how the design deals with it:

keep retrieval efficient
limit context passed to the model
stream responses to improve perceived speed

The wording matters here. Do not say only "low latency." Say where the latency comes from and what you would do about it.

Hallucination mitigation and observability

This section is non-negotiable. If you do not address hallucinations, your answer will feel incomplete.

A good GenAI design answer includes a layered LLMOps view.

Guardrails

You need input and output checks. The source guide calls out scans for:

PII leakage
toxic content

Those checks run before the response reaches the user.

Traceability

You should also log the full orchestration path:

prompt
retrieval
rerank
generation

Tools like LangSmith can help with this. The point is not the tool name. The point is that if a user gives a thumbs-down, you need the exact trace to inspect what went wrong. Was the retrieved chunk irrelevant? Did reranking fail? Did the prompt template bias the answer?

That level of traceability is a strong senior signal because it shows you are designing for debugging, not just happy-path demos.

A few questions interviewers often probe

Should you mention LangChain?

Yes, but only if you can explain the mechanics underneath it. Framework knowledge alone is not enough.

What is the most important part of a RAG pipeline?

Chunking and retrieval. If retrieval is poor, the model gets weak context and the output gets worse no matter how strong the foundation model is.

Do you need to be an ML researcher to pass?

No. You do not need to know how to train frontier models from scratch. You do need to understand MLOps, API-based model usage, retrieval systems, orchestration, and production constraints around latency and cost.

What a strong answer sounds like

A strong answer is specific. You compare fixed-size vs semantic chunking. You choose an embedding model and explain why. You store metadata for hybrid retrieval. You retrieve, rerank, then generate. You explain token cost, semantic caching, streaming, guardrails, and tracing.

That is the shape of a good GenAI system design interview answer in 2026.

If you want the original interview-guide version with the same structure and framing, read it on PracHub here: GenAI & LLM System Design Interview Guide (2026).

Behavioral Interview Questions: STAR Method Guide with Examples (2026)

Feng Zhang — Tue, 05 May 2026 03:29:59 +0000

Behavioral interviews are the round a lot of engineers underprepare for. That usually shows up fast.

You can ace coding rounds and still lose the offer if your behavioral answers are weak. At Amazon, these questions carry as much weight as technical interviews. At Google and Meta, a poor behavioral round can sink an otherwise strong loop.

This post is a practical rewrite of PracHub's STAR method guide for behavioral interview questions, with the parts that matter most if you're getting ready for interviews now.

What behavioral interviews are actually testing

The interviewer is trying to answer one question: "What will you be like to work with?"

They are not looking for polished speeches. They want real examples from your past work. They want to know how you handle things like:

conflict
ambiguity
failure
collaboration

Vague answers hurt you. General statements about being a team player do not help much. Specific past behavior is the point.

If you say, "We aligned and moved forward," the interviewer still does not know what you did.

If you say, "I set up a 30-minute sync with the two engineers who owned the conflicting services, proposed a shared interface contract, and wrote the first draft," that is useful.

Use STAR as structure, not a script

STAR is a way to organize your answer:

Situation
Task
Action
Result

It is a framework, not something you recite mechanically.

Situation

Set the scene in 2 to 3 sentences.

Answer the basic context:

When did this happen?
What team were you on?
What was going on?

Keep it short. A long setup is one of the easiest ways to lose the interviewer.

Task

Explain your specific responsibility.

This part matters more than many candidates think. Do not describe only the team's goal. Say what you were personally accountable for.

A weak version:

"We needed to improve the rollout."

A better version:

"I owned the backend migration plan and had to coordinate with two service owners to avoid breaking downstream clients."

Action

This is the core of the answer. It should be the longest section.

The interviewer wants concrete steps, not summaries. "I communicated with stakeholders" is weak. What did you actually do? Who did you talk to? What decision did you make? What did you write, change, or push forward?

The source article puts this well: "I held a meeting" is vague. "I scheduled a 30-minute sync with the three engineers who owned the conflicting services, proposed a shared interface contract, and wrote the first draft myself" is concrete.

That level of detail is what makes an answer believable.

Result

Close with what happened.

Use numbers if you can:

shipped 2 weeks early
reduced customer complaints by 40%
cut incident volume
improved a metric
unblocked a deadline

If the outcome was mixed, say that clearly and explain what you learned. Failure answers are completely valid if they show judgment and self-awareness.

The behavioral questions you should expect

Some questions show up over and over across companies. If you prepare for these, you cover a lot of ground:

Tell me about a time you disagreed with your manager or a teammate.
Tell me about a project that failed. What did you learn?
Describe a time you had to make a decision with incomplete information.
Tell me about a time you went above and beyond.
Describe a situation where you had to influence someone without authority.
Tell me about a time you received tough feedback.
Describe a time you had to prioritize competing deadlines.
Tell me about a time you worked with a difficult colleague.
Describe a project you are most proud of.
Tell me about a time you identified a problem nobody else saw.

You do not need a unique story for every one of these. You probably should not prepare that way.

How many stories you actually need

You can cover most behavioral interviews with 8 to 10 well-prepared stories.

The trick is to choose versatile stories. One strong example about conflict can often work for:

disagreement
influence
feedback
prioritization

A good story usually has four parts:

a real challenge or conflict
your specific actions
a measurable outcome
a lesson learned

That first point matters. Stories where everything went smoothly are usually weak interview material. Good behavioral answers have tension. Something was unclear, blocked, risky, or going wrong, and you had to do something about it.

Amazon is especially heavy on behavioral interviews

Amazon takes behavioral interviewing more seriously than most companies. Every round, including technical ones, can include behavioral questions tied to its 16 Leadership Principles.

The principles that come up most often are:

Customer Obsession: Start with the customer and work backwards.
Ownership: Act on behalf of the whole company, not just your team.
Dive Deep: Know the details and operate at every level.
Bias for Action: Speed matters, and many decisions are reversible.
Disagree and Commit: Push back respectfully, then commit once a decision is made.
Deliver Results: Focus on the right inputs and get results with solid quality.

If you're interviewing at Amazon, generic STAR prep is not enough. You should map stories to principles.

The source recommends preparing at least 2 stories per principle. That is a good benchmark if Amazon is your target.

PracHub also has company-tagged interview questions you can practice with, including behavioral questions reported from Amazon, Meta, and Google.

Mistakes that cost people offers

1. Being too vague

This is the biggest one.

"We worked through it" does not tell the interviewer anything. They need to understand your role, your judgment, and your execution.

Use names of actions:

analyzed logs
wrote the draft
proposed the rollback plan
aligned with PM
escalated the risk
changed the scope

Specifics make your answer strong.

2. Only preparing success stories

A lot of candidates dodge failure questions because they think failure makes them look weak.

Usually the opposite happens. Avoiding failure stories can make you look defensive or lacking self-awareness.

Interviewers want to know whether you can admit mistakes, reflect honestly, and improve.

3. Spending too long on the setup

Your Situation should be short. Two sentences is often enough.

If you spend half the answer explaining org structure, roadmaps, and background context, the interviewer is still waiting for the actual point.

Get to the Action fast.

4. Winging it

Behavioral rounds are where rambling kills otherwise strong candidates.

You do not need memorized scripts. You do need prepared stories that you have practiced out loud. If you have never said the story aloud before the interview, you will usually feel that in the room.

A simple prep plan that works

If you want a practical way to prepare, do this:

pick 8 to 10 stories from real work
write each one in STAR format
trim the Situation to 2 to 3 sentences
expand the Action with concrete steps
add metrics to the Result where possible
note what each story can answer
practice saying each story out loud

That gets you much farther than collecting random interview tips.

If you want a stronger question bank to practice against, the original PracHub guide is here again: Behavioral Interview Questions: STAR Method Guide with Examples.

Behavioral interviews are predictable in one important way: the same patterns keep showing up. If you prepare real stories, keep them specific, and use STAR without sounding robotic, you give yourself a much better shot at getting through the loop.

DEV Community: Feng Zhang

Uber Data Scientist Interview Cheatsheet 2026

What Uber is really testing

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

Window functions you should be comfortable with

Common SQL mistakes

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

Start with label definition

Know the evaluation metrics and what they miss

Calibration matters

Uncertainty matters too

Connect ETA to business outcomes

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

When interference matters

Know when to propose switchback experiments

Power is different under clustering

4) A/B testing answers need a decision framework

1. Define the objective

2. Pick the right randomization unit

3. Choose one primary metric

4. Check validity before interpretation

5. Make the recommendation based on practical value

Final prep advice

CTR And Engagement Metrics Explained — Tech Interview Concept (2026)

What interviewers are really testing

Start with the metric definition

CTR alone is not the goal

Build a metric hierarchy before you interpret anything

1. Primary success metric

2. Diagnostic metrics

3. Guardrails

Exposure definition is where a lot of people fail

Watch for denominator effects

How to talk about experiment design

Match the stats method to the metric

CUPED is worth bringing up

A good framework for "CTR dropped after a recommendation launch"

1. Validate the metric path

2. Validate the experiment

3. Decompose the funnel

4. Segment for diagnosis

The Shopping version of this question

Common mistakes

Treating CTR as the business goal

Ignoring exposure changes

Listing metrics without a decision rule

Final takeaway

Meta Data Scientist Interview Cheatsheet 2026

What Meta interviewers are usually testing

Notification analytics is a causal question, not a CTR question

Guardrails matter more for notifications than people think

Be precise about eligibility and exposure

Watch for cannibalization and spillovers

A/B testing answers need an estimand, not just a p-value

Choose the randomization unit based on interference risk

Power should be discussed at the right level

CUPED is worth mentioning if the prompt invites depth

How to answer a "similar-listing notifications" question

SQL event log questions are mostly about grain and joins

1) Decide the grain first

2) Be careful with time windows

3) Aggregate before joining when needed

4) Protect ratio calculations

5) Clarify deduplication rules

What candidates most often miss

A better way to use a cheatsheet

Top 50 SQL Interview Questions with Answers (2026)

Start with joins and window functions

1) Joins: table stakes

2) Window functions: where difficulty jumps

3) CTEs and subqueries: can you break a hard problem into steps?

4) Aggregation: basic, but easy to get wrong

5) Data manipulation and optimization: more common in some roles, still fair game

How to use this list well

Practice on real interview-style questions

System Design 101

Real system design experience beats tutorial knowledge

Breadth vs depth depends on your level

If you are mid-level

If you are senior or above