At United Airlines, data is the fuel that powers one of the world’s largest aviation networks. A Data Scientist at United Airlines does not work in a vacuum; you are tasked with solving some of the most complex logistical, operational, and commercial challenges in the travel industry. From optimizing flight schedules and crew assignments to predicting maintenance needs and dynamic ticket pricing, your models directly impact millions of passengers and shape the strategic direction of the airline.
The role sits at the intersection of advanced machine learning, operations research, and business strategy. Whether you are embedded in Revenue Management, Network Planning, Operations, or Customer Experience, you will work with massive, real-time datasets that capture the volatility of global travel. The sheer scale of operations means that even a fractional percentage improvement in fuel efficiency, gate utilization, or pricing models translates to millions of dollars in business value and a significantly smoother travel experience for customers.
What makes this position uniquely compelling is the tangible nature of your impact. You will build and deploy models where the outputs are visible in physical operations—affecting which planes fly where, how crews are positioned globally, and how the airline navigates disruptions like severe weather. For a curious and driven, offers an intellectually rigorous playground of mathematical modeling, optimization, and predictive analytics.
Recruiter Screen
reportedA screening call is a matching exercise run by someone who will not evaluate your statistics. They are checking that the work described on your resume is work you personally did, and that its scope matches the level the role is written for. Logistics get settled in the same half hour so nobody spends an interviewer's afternoon on a mismatch. The answer that fails is the one narrated in the plural. If every sentence is 'we built' and 'the team decided', there is nothing specific to write down about you. Name the piece that was yours, the decision you made inside it, and what changed after.
What to demonstrate
- Whether the ownership implied by your resume survives one round of follow-up about who actually did which part
- Whether your described scope (data size, stakeholders, what shipped) matches the seniority the role is written at
- Whether timeline, location and compensation expectations make the rest of the loop worth scheduling
How to prepare
- Rewrite your top three resume bullets in the first person singular, each with the decision you made and what moved afterwards, then say them out loud once so the 'we' does not return under pressure
- Attach one number to each project: the baseline, the change, and the window it was measured over. Where impact was never measured, say that plainly rather than inventing a figure
- Settle your compensation range before the call and give it as a range with a reason behind it, such as current total comp or a competing timeline, instead of deflecting the question twice
Online Assessment
reportedMuch of what gets scored here happens out loud while you type. Nobody can see your reasoning inside a half-written query, so five silent minutes read as being stuck even when they are not. State the plan in plain language first: which tables, what grain you are aggregating to, and the one filter that defines the population. Then write it. The narration doubles as insurance, because a wrong plan gets caught early and cheaply while a wrong query gets caught at the end with no time left to redo it. A timed statistics section, where one exists, is a separate test with its own clock.
What to demonstrate
- Whether the query you write matches the plan you just described
- What you do with a hint, meaning whether the correction gets absorbed or the first approach gets defended
- Whether you can debug your own wrong output by reading the result set and naming which part of the query produced the anomaly
How to prepare
- Solve three problems while screen-sharing into a recording, then watch it back and mark every stretch longer than thirty seconds where you said nothing
- Practise compressing the plan into one sentence before typing, then check afterwards whether the finished query actually matched it
- Time yourself on statistics questions that carry a business reading, such as what a confidence interval does and does not claim, rather than re-reading notes without a clock
Take-Home Case Study
reportedYour submission is read asynchronously by someone who cannot ask you a clarifying question, and who will usually skim it before reading it properly. That changes what good looks like. The conclusion belongs near the top with the supporting analysis beneath it, and the code should run start to finish on a clean machine without a manual step you forgot to document. A reviewer forced to reconstruct your reasoning from the order of notebook cells is already discounting the work. The submissions that land are the ones where a busy reader gets the answer immediately and can verify it if they want to.
What to demonstrate
- Whether the answer arrives before the methodology, so a reader who stops after the first page still has the recommendation
- Whether the code runs end to end from the submitted files, with dependencies and data paths declared rather than assumed
- Whether each chart is legible on its own, carrying axis labels and units, and exists to support a claim made in the text
How to prepare
- Restructure a past analysis so the opening paragraph holds the recommendation and the number behind it, then check that nothing later in the document quietly contradicts it
- Copy your own submission into an empty directory, run it in a clean environment, and fix everything that breaks; hidden local state is caught here or by the reviewer
- For every chart, write the one sentence it is meant to prove, and delete the chart if you cannot write that sentence
Technical Interviews
reportedBefore anything else, this round is a reading test. You are given a small schema and a question phrased in business language, and most of the difficulty sits in the gap between them. Who counts as an active user, does a refunded order still count as an order, is that date column an event time or a load time. Weak answers start typing immediately and compute something precise about the wrong population. Strong ones pin the definition in one sentence, name the column that encodes it, then write the query. On a timed assessment with nobody to tell, write the definition in a comment anyway.
What to demonstrate
- Whether an ambiguous term becomes a specific column and filter before any computation happens
- Whether you read the schema for keys and cardinality rather than only for column names
- Whether the result answers the question at the grain it was asked at, per user or per session or per day
How to prepare
- Take three metrics you already use and write down the exact filter and exact grain behind each, then practise stating one of them in a single sentence out loud
- On a schema you have never seen, spend the first minute writing what one row of each table means and which key it is unique on, then predict which joins can duplicate rows
- Rehearse a version where the definition changes halfway through, and edit the query you have instead of starting over
Behavioral Panels
reportedBehavioural answers from data candidates get audited in a way that answers from other roles do not. When you say a model lifted retention, the next question is the denominator, the window, and how you knew the lift was not seasonal. So attach the measurement to each claim while you tell it: what the metric was before, over what period, and against what comparison. Numbers with no baseline read as rounded-up memory, and one unsupported figure tends to make the rest of the story sound rehearsed.
What to demonstrate
- Whether each impact number arrives with a baseline, a window and a comparison, or as a bare percentage
- Whether you can name the method that attributed the effect to your work (an experiment, a staged rollout, a seasonal control) or concede the link was correlational
- Whether the magnitudes stay internally consistent when the interviewer multiplies them against the scale you described earlier
How to prepare
- For each story, write the impact line as metric, value before, value after, window, and how attribution was established. Any line missing two of those five is a follow-up you will answer badly.
- Re-derive one headline number from the source table rather than the deck that reported it. Resume numbers drift upward across retellings.
- Decide in advance which figures you cannot share, and prepare the ratio or relative change you can give instead, so a confidentiality limit does not read as evasion.
Onsite Interview
reportedA loop is not scored one interview at a time. The people you meet compare notes afterwards, usually in a meeting you are not in, and the outcome turns on what each of them can say about you when asked. That rewards something other than survival: every room needs one specific thing worth repeating, and none of them can contradict another. The common way to lose is to tell the same project four times with different numbers in it, or to be uniformly fine in a way that leaves nobody with anything to argue for.
What to demonstrate
- Whether your account of a project survives being told twice, with the same scale, the same metric definition and the same numbers each time
- Whether each interviewer leaves with one concrete claim they could make on your behalf later, rather than an absence of complaints
- Whether a question you already answered in an earlier room gets the same answer at the same depth, without visible impatience
How to prepare
- Write a one-page fact sheet for your two or three main projects that fixes the numbers you will quote: rows of data, the metric as a single sentence, the effect you measured and how long the work took. Say them aloud from the sheet until they come out identical every time
- For each kind of room you expect, decide the one sentence you want that interviewer repeating in a debrief, then check during the mock that you said it outright instead of implying it
- Rehearse answering the same project question twice in one sitting, the second time as though you had not just answered it, because the thing that needs fixing is the flatness that creeps into a repeated story
PracHub editorial advice for the preparation topics above.
Attributing a blended rate change to behaviour when the mix moved underneath it
Occupancy, average daily rate, take rate and conversion are all ratios computed over a heterogeneous pool, and their blended values move whenever the composition of markets, property classes, lead times, party sizes or contract types changes, with nothing changing inside any segment. This is Simpson's paradox with a seasonal engine driving it: a shift toward short-lead leisure demand lowers blended ADR and raises blended conversion at the same time, and both movements are mix. Year-over-year comparison does not rescue you by itself, because the calendar does not repeat: day-of-week alignment drifts and moving holidays shift by weeks, so the same ISO week is not the same demand week. Decompose every rate change into a within-segment component and a mix component before writing a sentence about cause, and align year-over-year comparisons on the local market calendar using market_holiday_flag rather than on the date.
Fitting demand or price elasticity on observed bookings, when availability and restrictions censor the data
Bookings equal the minimum of demand and what was actually sellable, so a sold-out date records the capacity, not the demand behind it, and the censoring is worst precisely on the highest-demand dates. Meanwhile price is set from a forecast of that same demand, so high-demand dates carry high prices and the raw correlation between price and bookings is biased toward zero and frequently comes out positive, which reads as 'raising price increases demand'. Restrictions compound it: a minimum-length-of-stay rule or a closed-to-arrival flag suppresses bookings with no price movement at all, so the effect lands on the price coefficient if the restriction is not in the model. Join fct_rate_availability_snapshot at snapshot_date equal to the search or booking date, restrict the estimation sample to unit-dates that were genuinely open, carry the restriction flags as controls, and lean on an instrument or a deliberate price experiment before quoting an elasticity.
Answering a product-sense question with a list of features
Answer with a decision and the measurement that would settle it: the hypothesis, the primary metric, the guardrails, and the result that would make you not ship. A feature brainstorm cannot be wrong, which is exactly why it earns no points.
Averaging per-user rates to produce a population rate
Decide which quantity you want: the mean of per-user ratios and the ratio of summed numerator to summed denominator are different estimands, and heavy users dominate one but not the other. For a ratio metric, aggregate numerator and denominator separately and use the delta method for its variance.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
How do you construct a likelihood function, and how does Maximum A Pos…
How do you construct a likelihood function, and how does Maximum A Posteriori (MAP) estimation differ from Maximum Likelihood Estimation (MLE)?
Approach
- Sanity-check the answer against a simple bound or a simulated case.
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
- Write down the assumption the method needs before you use the method.
Follow-up
- How would you explain this result to someone who does not know statistics?
- What sample size would you need to detect an effect half this size?
Walk me through a hypothesis test. How do you determine the sample siz…
Walk me through a hypothesis test. How do you determine the sample size required to achieve a specific statistical power?
Approach
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
- Translate the result into the decision it informs, in one plain sentence.
- Sanity-check the answer against a simple bound or a simulated case.
Follow-up
- Which assumption here is most likely to be violated in practice?
- How would you explain this result to someone who does not know statistics?
What are the mathematical differences between bagging and boosting? Wh…
What are the mathematical differences between bagging and boosting? When would you prefer one over the other?
Approach
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
- Sanity-check the answer against a simple bound or a simulated case.
- Write down the assumption the method needs before you use the method.
Follow-up
- What sample size would you need to detect an effect half this size?
- Which assumption here is most likely to be violated in practice?
Write an efficient algorithm to identify duplicate passenger records a…
Write an efficient algorithm to identify duplicate passenger records across multiple reservation systems.
Approach
- Say how the offline result would be validated online before it is trusted.
- Set a baseline first, so any model has something honest to beat.
- Pick an evaluation metric that matches the cost of each error type, not a default.
Follow-up
- How would you choose the decision threshold, and who owns that choice?
- Where could label leakage enter this setup?
Describe a situation where you had to explain a complex machine learni…
Describe a situation where you had to explain a complex machine learning model to a non-technical business stakeholder. How did you adapt your communication style?
Approach
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- Pick an evaluation metric that matches the cost of each error type, not a default.
- Check what information would not exist at prediction time, and exclude it.
Follow-up
- What would you monitor after launch to know the model is still valid?
- How would you choose the decision threshold, and who owns that choice?
Decompose a blended ADR move into mix and rate
You have stayed-night data for two periods with destination_market_id, property_class, rate_plan, night count and unit_revenue_usd. Blended ADR fell 4.20 USD. Decompose that change into a within-segment rate component, a mix component and their interaction, so the three sum exactly to the blended delta. Segments exist in one period only, so an inner join is not acceptable. Return a per-segment table plus the three totals and the five segments with the largest absolute contribution. State the convention you use for a segment's missing base-period rate and what it does to the split.
Approach
- Write the identity before any code. Blended ADR is sum over segments of r_i * w_i where r_i is segment ADR and w_i is the segment share of stayed nights. Then ADR1 - ADR0 = sum of (delta r * w0) + sum of (r0 * delta w) + sum of (delta r * delta w), and that expands algebraically back to r1w1 - r0w0, so it is exact rather than approximate.
- Aggregate to the segment grain by re-summing revenue and night counts, then divide once. Averaging pre-computed per-night rates inside a segment reintroduces the same mean-of-ratios error the decomposition exists to expose.
- Outer-join the two periods so entering and exiting segments survive as missing values, then handle them deliberately: for an entering segment w0 is 0, so its within term is zero for any choice of r0, and the total is unaffected. The r0 convention only moves value between the mix and interaction terms. Setting r0 to the period-0 blended ADR reads as 'a new segment is average until proven otherwise', which puts its deviation from average in the interaction term.
- Assert the reconciliation to 1e-9 USD before reporting anything. If it fails, the cause is almost always a segment lost to an inner join or weights that do not sum to 1 within a period.
- Rank segments by the absolute sum of their three terms and report the top five with the terms shown separately, because a segment can have a large mix term and a near-zero rate term, and only the second of those is a pricing decision anyone made.
Worked solution 40 min
- Aggregate each period to (destination_market_id, property_class, rate_plan): total revenue, total stayed nights; r = revenue/nights, w = nights/period total nights.
- Outer-join period 0 and period 1 on the segment key; fill missing w with 0 and missing r with the corresponding period's blended ADR, recording which rows were filled.
- Compute within = (r1 - r0) * w0, mix = r0 * (w1 - w0), interaction = (r1 - r0) * (w1 - w0).
- Assert the three column sums add to blended ADR1 minus blended ADR0 within 1e-9, and that w0 and w1 each sum to 1.
- Rank by abs(within + mix + interaction), return the top five with all three terms shown, and write one sentence naming which component carries the move.
Follow-up
- The mix term dominates. Name two operational causes that would produce exactly that pattern, and the query you would run to tell them apart.
- Your comparison is the same ISO week a year apart. What breaks when a moving holiday falls inside one of them, and how do you align instead?
- How would you present this so the decision-maker does not walk away believing prices were cut?
Solve a string manipulation problem in Python (e.g., reversing words i…
Solve a string manipulation problem in Python (e.g., reversing words in a sentence while preserving whitespace or parsing complex flight codes).
Approach
- Say which table is the grain you start from, and join outward from it.
- State the window function and its partition and ordering out loud before writing it.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
Follow-up
- How does the query change if the join becomes one-to-many?
- How would you verify this result without re-running the same query?
Write a SQL query to find the second highest salary from an employee t…
Write a SQL query to find the second highest salary from an employee table using both a subquery and a window function.
Approach
- Say which table is the grain you start from, and join outward from it.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- State the window function and its partition and ordering out loud before writing it.
Follow-up
- What breaks if events arrive late or out of order?
- How would you verify this result without re-running the same query?
Rank market-weeks by qualified intents that never converted
Using the qualifying-intent definition over fct_search (trip_intent_key, searched_at_utc, destination_market_id, check_in_date, results_returned_count, is_bot_flagged) and fct_booking (trip_intent_key, booked_at_utc), produce a supply-acquisition list: the 20 (destination_market_id, ISO week of check_in_date) pairs with the most qualifying intents that never converted within seven days of their first search. Note that fct_booking.trip_intent_key is NULL for deep-link, offline and partner-channel bookings. Return market, check-in week, non-converting intents and total intents.
Approach
- Reuse the qualifying-intent set: non-bot, results_returned_count > 0, collapsed to one row per trip_intent_key carrying its first search timestamp and the check_in_date from that first search.
- Write the anti-join as NOT EXISTS, correlated on trip_intent_key with the seven-day window inside the subquery. NOT EXISTS is NULL-safe and lets the planner choose an anti-join.
- If you insist on NOT IN, add WHERE trip_intent_key IS NOT NULL to the inner query. Without it, one NULL in the subquery makes the predicate UNKNOWN for every outer row and the result set is empty.
- Group by destination_market_id and DATE_TRUNC('week', check_in_date), counting both non-converting and total intents so the reader sees volume and share together.
- Order by non-converting intents descending and limit to 20. Ordering by share alone promotes market-weeks with five intents and one miss.
Worked solution 25 min
- Run the inner subquery alone and count its NULLs; that count is the reason the NOT IN form fails and is worth stating out loud before fixing it.
- Build the qualifying-intent CTE and record its row count as the control total for the rest of the query.
- Write the NOT EXISTS anti-join and confirm that non-converting plus converting equals the control total exactly.
- Aggregate to market-week, order by volume, and limit.
Follow-up
- Which of these market-weeks are a supply shortage and which are a restriction or price problem? Which column separates them, and what join do you need?
- You run the query and get zero rows. Walk me through how you find out why, without changing the query at random.
- How would you exclude intents that did convert under a different trip_intent_key, such as the same traveller shifting their dates by a week?
Suppose you are dealing with a highly imbalanced dataset for predictin…
Suppose you are dealing with a highly imbalanced dataset for predicting flight delays. Which classification metrics would you prioritize, and why?
Approach
- Decompose the metric into the rates that drive it, and say which one you would check first.
- Fix the population and the time window before naming any metric.
- Name one primary metric, then the guardrail that stops it being gamed.
Follow-up
- How would you detect that the metric is being gamed rather than genuinely improving?
- What would you do if the primary metric and the guardrail moved in opposite directions?
Describe a heuristic approach you would use to solve a complex network…
Describe a heuristic approach you would use to solve a complex network routing problem when an exact solution is computationally infeasible.
Approach
- Work from the decision backwards to the evidence you would need.
- Say what you would check first and why it is the highest-information step.
- Clarify what is being asked and what a complete answer would contain.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Measure a loyalty threshold effect with regression discontinuity
Travellers reach the gold loyalty_tier in dim_traveller at 10 completed stay-nights within a rolling 12 months; the rule is deterministic and evaluated nightly. Leadership wants the causal effect of gold status on completed stay-nights in the following 90 days, and tier cannot be randomised. Specify the design, the running variable, the estimand you can actually identify, and the two validity checks that would kill it. Then say what you conclude if the density of travellers at exactly 10 nights is 2.3 times the density at 9.
Approach
- Set up a sharp RDD: assignment is a deterministic step function of completed nights in the rolling window, so identification comes from continuity of potential outcomes at the cutoff rather than from randomisation. Estimate with local linear regression on each side, a triangular kernel, a data-driven bandwidth, and bias-corrected robust confidence intervals rather than conventional ones.
- Name the estimand before quoting it: a local average treatment effect for travellers sitting at 9 to 10 nights. It says nothing about travellers at 3 nights or at 40, and the difference matters because the business question is usually about the latter.
- Handle the discreteness of the running variable. Nights are integers with most mass below 15, so the local window holds very few distinct values; use inference designed for a discrete running variable rather than treating it as continuous, and never cluster the standard errors on the running variable itself.
- Run the manipulation test (a density test at the cutoff) and read a 2.3x jump at 10 over 9 as a failed check on its face, since it is consistent with travellers adding a night to qualify, which is self-selection into treatment and breaks continuity.
- Distinguish deliberate manipulation from mechanical heaping before condemning the design: integer stay lengths pile at round totals whether or not a threshold exists, so compare the histogram against a period before the threshold existed or against a cohort on a different threshold. If the heaping predates the rule, it is mechanical; if it appeared with the rule, it is manipulation.
- Confirm nothing else changes at 10 nights. If a coupon, an email trigger or a cancellation-policy change fires at the same cutoff, the discontinuity identifies the bundle and not gold status, and that has to be stated in the headline rather than in a footnote.
Worked solution 45 min
- Define the running variable as completed nights in the rolling 12-month window at the nightly evaluation, and freeze the outcome window as the 90 days after that evaluation date.
- Fit local linear regressions either side with a triangular kernel and a data-driven bandwidth, and report the bias-corrected robust interval alongside the conventional one.
- Run the density test at the cutoff and record the 2.3x ratio, then compare the integer-nights histogram against a pre-threshold period to classify the heaping as mechanical or manipulated.
- Run placebo RDDs at 8 and at 12 nights and confirm both return estimates indistinguishable from zero.
- If the heaping is manipulation, re-estimate as a donut RDD excluding a symmetric window around the cutoff, report the precision cost, and state plainly if the design no longer identifies the effect.
Follow-up
- The threshold is evaluated nightly on a rolling 12-month window, so travellers cross and fall back repeatedly. What does that do to the design and to the running variable?
- The density test fails and manipulation is real. Name an instrument you would consider for tier status and state the exclusion restriction it needs.
- Leadership actually wants the effect at 40 nights. What design gives them that, and what would it cost?
Net revenue per sellable night fell six percent quarter over quarter
Net revenue per sellable night fell 6.1% quarter over quarter on the stay-date axis. Occupancy fell 4.6% and ADR fell 1.6%. Sellable nights rose 8%, and supply grew as planned. Using fct_stay_night, fct_rate_availability_snapshot and dim_supply_unit (property_class, listed_at_utc, listing_status, units_blocked), decompose the fall into rate and occupancy, then each of those into mix and within-segment, and determine how much is the mechanical effect of new supply entering the denominator before it sells. Deliverable: the decomposition with every term sized, and one recommendation.
Approach
- Verify the identity on your own row set before decomposing anything: revenue per sellable night equals ADR times occupancy exactly, because revenue/sellable = (revenue/stayed) times (stayed/sellable), and only when all three are computed over the same units and dates. Work in logs so the components add, and confirm that -1.6% and -4.6% reproduce -6.1%.
- Run shift-share on each component separately and on the same segmentation, market by property_class by lead-time bucket, using stayed nights as the weight base for ADR and sellable nights for occupancy. Each rate must be decomposed on the denominator it is actually built from, or the terms will not reconcile.
- Isolate the supply-cohort effect explicitly. Split units by listed_at_utc into those live in both quarters and those listed during the quarter, and recompute all three metrics on the stable cohort alone. New listings add sellable nights immediately and revenue only once they ramp, so the gap between the all-supply and stable-cohort figures is dilution, and dilution is not a performance problem.
- Check the denominator for the opposite artefact. A supplier blocking cheap dates raises this metric while shrinking supply, so confirm the sellable-night convention did not change between quarters, and report sellable nights as a level rather than only as a denominator.
- Assemble one table with within-segment rate, mix rate, within-segment occupancy, mix occupancy, new-supply dilution and residual, and either make the residual small enough to ignore or explain it.
- Recommend only after the table exists. If the fall is dilution plus mix, cutting price attacks the one term that was already healthy and makes the next quarter worse.
Follow-up
- New supply accounts for 70% of the fall. At what point does that stop being dilution and start being a ramp problem you should act on?
- How would you report this metric so that next quarter's supply growth does not make the number look good for the wrong reason?
- Which of these terms could a supplier-facing team actually move, and over what horizon?
For someone who has spent the last year in notebooks, dashboards or modelling work and has not written raw SQL under time pressure. The first four days rebuild query fluency against a fixture you control and can verify by hand; the last three attach that fluency to the rest of the loop.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Build a fixture you can check answers against
- Create a local Postgres or SQLite database with four tables (users, sessions, events, orders) holding roughly 200 rows you generated yourself, so you know the contents well enough to predict every result.
- Deliberately seed the cases that break queries: a user with no sessions, a session with no events, two orders sharing a timestamp, a NULL in one join key, and one duplicated user row.
- Before writing any SQL, hand-compute five answers on paper (how many users placed at least one order, median orders per ordering user, and three others) and save them as the ground truth for the week.
Deliverable: A one-command seed script plus a text file of five hand-computed answers to grade every later query against.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Joins, filters and NULL semantics
- Answer "which users have no orders" three ways (LEFT JOIN with IS NULL, NOT EXISTS, NOT IN) and confirm that the NOT IN version returns zero rows once the subquery contains a NULL, because the comparison is never TRUE.
- Reproduce the LEFT JOIN that silently collapses to an inner join by putting a right-table predicate in WHERE, then fix it by moving the predicate into the ON clause, and record both row counts.
- Create a fan-out bug on purpose by joining orders to order_items and summing the order total, then correct it with a pre-aggregated subquery and explain in one line which table changed the grain.
Deliverable: One annotated .sql file holding the three join traps, each with the wrong result and the corrected result side by side.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Window functions and frames
- Write three window queries against the fixture: a running order total per user, the rank of each order within its user by value, and the day gap to that user's previous order, then check each against the day-one ground truth.
- Run ROW_NUMBER, RANK and DENSE_RANK over a column containing ties, print all three side by side, and write one sentence on when each is the correct choice.
- Switch one query from the default frame (RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, which is what you get when ORDER BY is present and no frame is written) to ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, and explain why the output differs only when the ORDER BY column has duplicates.
Deliverable: Three verified window queries plus a short note explaining the RANGE versus ROWS difference in your own words.
Practice prompt ↗Practice prompt ↗04The four analytical query patterns
- Write a monthly retention grid: first order month per user, then months-since-first as the column, and verify that month zero equals the cohort size exactly.
- Sessionize the events table under a 30-minute inactivity rule using LAG plus a cumulative sum over a new-session flag.
- Build a four-step funnel that counts distinct users rather than events at each step, and state the rule you applied to a user who reaches step three without ever logging step two.
Deliverable: One file with the retention, sessionization and funnel patterns, each carrying a one-line note on the assumption it bakes in.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Write SQL the way you will have to write it live
- Set a 12-minute timer and solve three medium prompts in a plain editor with no execution and no autocomplete, then run them and tally syntax errors separately from logic errors.
- Narrate one solution aloud while writing it, stating the grain of each intermediate result (one row per user, one row per user-day) before you type its body.
- Rewrite your slowest solution as a CTE chain where every CTE name states its grain, and time yourself re-solving it from blank.
Deliverable: A recording of one narrated solution plus an error tally that separates syntax from logic.
Practice prompt ↗Practice prompt ↗06One day for everything that is not SQL
- Write the preconditions of the two-sample t-test from memory, then check them: independent observations, and a difference in means whose sampling distribution is approximately normal, which at large sample sizes follows from the central limit theorem rather than from normality of the raw values.
- Write the difference between an odds ratio from logistic regression and a relative risk, and state the condition under which the two are close (low outcome prevalence).
- Prepare a 90-second answer to "how would you know this model is any good" that names the metric, the baseline you would beat, and the cost of the errors you care about.
Deliverable: One page of notes covering test preconditions, the odds-ratio caveat and the model-quality answer.
Practice prompt ↗Practice prompt ↗07Full loop rehearsal
- Run a 45-minute mock with someone willing to interrupt: 20 minutes of SQL, 15 minutes defining a metric, 10 minutes on a past project.
- Re-solve from blank the two queries you were slowest on this week and compare the times against day five.
- Write a five-line answer to "walk me through a project" that puts a number in the first sentence and names the decision the work changed.
Deliverable: Mock feedback notes plus a timed project narrative you can deliver without reading it.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Saying no well is a senior skill and it is rarely rehearsed. Think of a time you told someone their analysis was not worth doing, or that the experiment could not answer their question at the sample size available. Explain what you offered instead. Refusal without an alternative reads as obstruction rather than judgement.
Tell me about a time you faced a significant challenge or roadblock du…
Tell me about a time you faced a significant challenge or roadblock during a team project. How did you handle it, and what was the outcome?
Approach
- State the situation in two sentences and spend the rest on your reasoning.
- Pick a story where you drove the decision, not one where you observed it.
- Close with what you would do differently, concretely.
Follow-up
- How did you know the outcome was caused by your change?
- What would you do differently if you ran that project again?
Defend a cancellation finding against the team it damages
A supplier-growth team moved one market's inventory from 'strict' to 'flexible' cancellation_policy in fct_rate_availability_snapshot. Their dashboard shows bookings up 14% over eight weeks. Your read on fct_stay_night shows stayed nights flat, and traveller-initiated cancellation up from 18% to 31% in the same lead-time bucket. Their quarterly goal is booked nights, and the lead has already sent the 14% to their director. You have ten minutes in their weekly review. Prepare what you open with, what you concede, and what you will not soften.
Approach
- Before the meeting, rebuild both periods as a hazard at a fixed age: share cancelled within k days of booked_at_utc, with k capped at the elapsed age of the youngest cohort. The flexible-policy cohort is younger, so a raw cancellation rate would be low for maturity reasons alone, and presenting that comparison hands the room a correct objection that kills the finding on its first sentence.
- Open by conceding the part that is true and theirs: bookings did rise 14%, the campaign did what it was designed to do on the booking axis. Naming their win first removes the reading that you are attacking the team rather than the metric.
- State the disagreement as an axis disagreement, not a competence one: booked nights is counted on booked_at_utc, stayed nights on stay_date, and the gap between them is exactly what a cancellation-policy change moves. Show the two series on one chart with both axes labelled.
- Quantify the delivered outcome in their own units so the tradeoff is arithmetic rather than opinion: stayed nights flat means the incremental bookings cancelled at roughly the rate that absorbs the whole 14%, and contribution margin per stayed night absorbed the servicing and payment-processing cost of the bookings that did not convert.
- Offer a route that keeps their goal intact: propose booked-nights-net-of-cancellation as the team's tracked number, or a stay-date readout held until the cohort matures, and say which you would commit to defending upward on their behalf.
Follow-up
- The lead says your cancellation cohort is not mature enough to compare. Walk me through the exact calculation that makes it comparable.
- Their director asks you directly whether the campaign should be rolled back. What do you say, and what would change your answer?
- How would you have set this up eight weeks ago so this conversation never happened?
Retract an occupancy comparison after the decision shipped
Three weeks ago you published a market occupancy comparison that led to marketing spend being moved out of one market. Reviewing the query, you find the two markets used different denominators: sellable nights from fct_rate_availability_snapshot (units_sold_to_date + units_available) for one, and capacity_units from dim_supply_unit for the other. The second market is mostly individual_host supply with large units_blocked, so its occupancy was understated. The spend move is already live. Prepare the correction: who you tell, in what order, and what the note says.
Approach
- Quantify the error before telling anyone, because the first question will be 'how wrong'. Recompute both markets on sellable nights, which excludes units_blocked, and report the corrected gap and its sign, not just that the original was wrong.
- Separate the numerical error from the decision error. The comparison was invalid, but the spend move may still have been right; establishing whether the decision would have flipped is a different analysis and it is the one the business needs.
- Tell the decision-maker directly and first, before it appears in a dashboard or a peer surfaces it. Order matters because being told by a third party converts a mistake into a credibility problem.
- Write the note with the correction, the size, the decision implication, and the reversal cost in that order. Three weeks of moved spend has a real cost to undo, and a correction that does not price the reversal forces the reader to do the work you skipped.
- Name the specific control that would have caught it and put it in place in the same note: an assertion in the query that both arms use the same denominator expression, and the denominator named in the chart title. A retraction without a mechanism reads as an apology rather than a fix.
Follow-up
- The corrected numbers still support the original decision. Do you still send the note, and does it read differently?
- Your manager suggests quietly fixing the dashboard and not raising it. How do you respond?
- What would you have had to do differently three weeks ago, in the query itself, rather than in your review habits?
- 01
Tell me about a time you faced a significant challenge or roadblock during a team project. How did you handle it, and what was the outcome?
- 02
A supplier-growth team moved one market's inventory from 'strict' to 'flexible' cancellation_policy in fct_rate_availability_snapshot. Their dashboard shows bookings up 14% over eight weeks. Your read on fct_stay_night shows stayed nights flat, and traveller-initiated cancellation up from 18% to 31% in the same lead-time bucket. Their quarterly goal is booked nights, and the lead has already sent the 14% to their director. You have ten minutes in their weekly review. Prepare what you open with, what you concede, and what you will not soften.
- 03
Three weeks ago you published a market occupancy comparison that led to marketing spend being moved out of one market. Reviewing the query, you find the two markets used different denominators: sellable nights from fct_rate_availability_snapshot (units_sold_to_date + units_available) for one, and capacity_units from dim_supply_unit for the other. The second market is mostly individual_host supply with large units_blocked, so its occupancy was understated. The spend move is already live. Prepare the correction: who you tell, in what order, and what the note says.
Is this an official United Airlines interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at United Airlines. Rounds and questions reflect what candidates have reported, not a process United Airlines has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How long does the hiring process typically take?
The process is thorough and can take anywhere from two to three months from application to a final decision. Candidates frequently report gaps of 3 to 4 weeks between interview rounds. It is highly recommended to stay in polite, regular contact with your recruiter to monitor your status.
PracHub interview research ↗Do all Data Scientist roles at United require Operations Research (OR) knowledge?
Not all, but a significant portion do. United Airlines relies heavily on OR for scheduling, network routing, and revenue management. Even if your role is primarily focused on predictive machine learning, having a basic understanding of linear programming and optimization constraints will give you a distinct advantage.
PracHub interview research ↗What is the format of the behavioral interview?
The behavioral interviews are structured around the STAR method. Interviewers expect you to discuss past projects in detail, focusing on how you solved technical challenges, handled team conflict, or communicated with difficult stakeholders. They highly appreciate candidates who weave technical details and business metrics into their answers.
PracHub interview research ↗Does United Airlines offer remote work for Data Scientists?
While some positions may offer hybrid flexibility, many core data science teams are located at the corporate headquarters in Chicago, IL or key international hubs like Gurgaon, India. Final-round candidates for US-based roles are often flown out to the Chicago headquarters to meet the team in person.
PracHub interview research ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
platform · Accessed 2026-09-22 - 02PracHub Data Scientist practice ↗
Cross-company practice questions for this role.
platform · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
platform · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Universal Orlando Resort Data Scientist Interview Questions & Guide 2026
Prepare for the data scientist interview at Universal Orlando Resort with original practice on experiment design, SQL, and metric reasoning, each exercise paired with a worked solution and the reasoning behind it.
The Travelers Companies Data Scientist Interview Questions & Guide 2026
A prep plan for The Travelers Companies data scientist candidates built on spaced review: write a full answer before opening any solution, keep a running list of the assumptions you failed to state, and repeat every missed exercise three da
Priceline Data Scientist Interview Questions & Guide 2026
Causal-inference exercises for Priceline data scientist prep: difference-in-differences, matching, instrumental variables, and knowing when observational data simply cannot answer the question asked.
PriceLabs Data Scientist Interview Questions & Guide 2026
Timed practice for PriceLabs data scientist candidates who freeze under a clock: short SQL and probability sets run end to end, then reviewed against a written rubric.