A Data Scientist at Qantas sits at the intersection of complex logistics, premium customer experience, and cutting-edge aviation technology. In this role, you are not just building models; you are optimizing the operations of one of the world's most iconic airlines. From predicting fuel consumption and optimizing flight paths to personalizing offers for millions of Qantas Frequent Flyer members, your work directly impacts the safety, sustainability, and commercial success of the Qantas Group.
The data landscape here is massive and multifaceted. You will work with diverse datasets ranging from real-time aircraft sensor data to complex customer behavioral patterns. The challenges are high-stakes and intellectually stimulating, requiring a balance of advanced mathematical modeling and a deep understanding of the aviation business. Whether you are improving the efficiency of the Mascot hub or enhancing the digital journey for international travelers, your contributions help keep Qantas at the forefront of the industry.
This position is critical because it transforms raw data into strategic intelligence. As Qantas continues to modernize its fleet and digital infrastructure, Data Scientists are the architects of the predictive engines that drive decision-making. You will be expected to navigate ambiguity, collaborate with cross-functional teams, and deliver scalable solutions that maintain the high standards of reliability and excellence associated with the Spirit of Australia.
Talent Acquisition Screen
reportedAn extra round usually exists because something is still open after the standard loop: a skill the earlier interviews did not sample, a level decision, or two interviewers who disagreed. It is rarely a rerun of what you already did well. Ask the recruiter who you are meeting, what function they sit in, and how long the session runs. That is an ordinary scheduling question, and the answer changes what you should prepare. What separates a strong candidate here is treating the round as a fresh evaluation with its own bar, rather than assuming earlier performance carries you through or sinks you.
What to demonstrate
- Whether you can answer well on ground the earlier rounds did not cover, without leaning on what you already said to someone else
- Consistency of the facts in your stories: the same sample size, timeframe, team size and scope of your own role as in earlier conversations
- How you handle an unfamiliar format live, including whether you ask what kind of answer is wanted before producing one
How to prepare
- Ask the recruiter for the interviewer's function, the length, and whether to expect a coding surface, a discussion, or a presentation. Preparing for a 30 minute conversation with a partner team is not the same work as preparing for a 60 minute technical block.
- Write out what each earlier round actually covered, then list the two or three areas nobody probed. That gap is the most likely subject of the extra round.
- Re-read the numbers in the project stories you have already told, so a second telling does not quietly contradict the first.
Technical Assessment
reportedThis round decides whether someone can hand you a schema and a question and trust the number that comes back. Correctness under a clock is the bar, not clever syntax. The habit that separates strong from weak answers is checking the grain: after every join, know how many rows you expect and whether the count moved. Most wrong answers in this format are not wrong logic, they are a fan-out from a key that turned out not to be unique, or a filter applied before an aggregate when it belonged after. Say what you expect before you run it.
What to demonstrate
- Whether your row counts survive each join, and whether you notice on your own when they do not
- Deliberate handling of rows that fail to match, including whether the question needs an inner join or a left join with the non-matches kept and counted
- Whether NULLs are treated on purpose, given that a NULL compares equal to nothing and that COUNT of a column skips it
- Reaching a defensible answer inside the window instead of a refined one after it
How to prepare
- Take a two-table schema, write a join that fans out on purpose, then fix it by collapsing the many-side to one row per key before joining. Repeat until the fix is reflex rather than recall.
- Write a funnel as one query and print the distinct user count at each stage, then confirm each stage is a subset of the one above it rather than assuming it
- Do a few timed runs in a plain text box with no autocomplete and no formatter, since assessment editors often have neither
Onsite Interviews
reportedA day of back-to-back interviews samples your floor, not your ceiling. Four hours in, the habits that carry a good answer are the first to go: restating the question before solving it, asking what the data would have to look like, checking a number before quoting it. What the day decides is whether the tired version of you is still someone to leave alone with an ambiguous problem. The round that sinks a candidate is usually not the hardest one. It is the one immediately after the round that went badly.
What to demonstrate
- Whether the late rounds get the same clarifying questions as the first one, or whether you start answering immediately to save effort
- Whether a weak answer stays in the room it happened in, instead of following you into the next conversation as apology or distraction
- Whether the quality of your questions holds up, since fatigue removes curiosity about the problem before it removes knowledge of the method
How to prepare
- Rehearse the length, not just the content: book four mock interviews of different types in one afternoon with short gaps, because the one you need to observe is the fourth
- Put the two or three questions you ask at the start of any problem on a card in front of you, so that under fatigue it is a habit you run rather than a decision you make
- Decide in advance what the gap between rooms is for: water, one line of notes on anything you promised to follow up, and an explicit close on the round that just ended so it does not travel
- Prepare a different closing question for each interviewer, so the end of a long day does not produce the same one four times
PracHub editorial advice for the preparation topics above.
Running per-user experiments on shared, finite inventory
Independence between units fails when they compete for the same rooms on the same dates: a unit booked by a treatment user is removed from the control users' result sets, so the control arm is degraded by the treatment and the measured lift is inflated, sometimes to the point where a neutral change reads as a clear win. The effect is largest exactly where it matters most, in constrained markets and peak dates, and it is invisible in the usual diagnostics because both arms look balanced on pre-period covariates. Supplier-side treatments have the same problem in reverse, since a pricing or ranking change applied to some inventory changes the alternatives that every traveller sees. Randomise at the level that contains the competition, which is normally market-by-stay-week or a switchback on a market, and power the test on the number of clusters, not the number of users.
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.
Comparing periods without accounting for seasonality or day-of-week
Compare whole weeks against whole weeks and check whether the same swing appeared in prior cycles or prior years before attributing it to anything you changed. Weekday and weekend populations often differ enough that a Tuesday-to-Saturday comparison is meaningless.
Writing SQL without stating NULL and tie-breaking behaviour
Before calling a query finished, say what it does with NULLs, ties and empty groups. NOT IN against a subquery containing a single NULL returns no rows at all, and RANK, DENSE_RANK and ROW_NUMBER differ precisely on ties, so name which one the question requires.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Describe how a Random Forest algorithm works and its advantages over a…
Describe how a Random Forest algorithm works and its advantages over a single Decision Tree.
Approach
- 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.
- Set a baseline first, so any model has something honest to beat.
Follow-up
- How would you choose the decision threshold, and who owns that choice?
- Where could label leakage enter this setup?
If a model's performance drops in production, what is your step-by-ste…
If a model's performance drops in production, what is your step-by-step process for debugging it?
Approach
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- Set a baseline first, so any model has something honest to beat.
- Say how the offline result would be validated online before it is trusted.
Follow-up
- Where could label leakage enter this setup?
- What would you monitor after launch to know the model is still valid?
Explain the concept of "Data Leakage" and give an example of how it mi…
Explain the concept of "Data Leakage" and give an example of how it might occur in a pricing model.
Approach
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- Check what information would not exist at prediction time, and exclude it.
- Say how the offline result would be validated online before it is trusted.
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?
Implement occupancy, ADR and revenue per sellable night
Two DataFrames: nights (booking_id, stay_date, supply_unit_id, night_status in booked/cancelled/no_show/stayed, unit_revenue_usd, taxes_and_fees_usd) and snap (supply_unit_id, stay_date, snapshot_date, units_available, units_sold_to_date, units_blocked). Implement, per stay_date: occupancy, average daily rate and net revenue per sellable night. Sellable nights are units_sold_to_date + units_available taken from the latest snapshot_date on or before that stay_date, per unit, excluding units_blocked. ADR excludes taxes. Return one frame indexed by stay_date and assert revenue-per-sellable-night equals ADR times occupancy.
Approach
- State the denominator convention out loud before coding: sellable nights exclude units_blocked, physical capacity includes them, and the two diverge sharply for individually-managed supply. Put the chosen convention in a column name or a returned attribute so a reader cannot mistake which one they are looking at.
- Do the as-of pick per (supply_unit_id, stay_date), not globally: filter snap to snapshot_date <= stay_date, sort by snapshot_date, then groupby(['supply_unit_id','stay_date']).tail(1). Taking the single latest snapshot_date across the whole table silently uses one date's view for every stay date and quietly changes the metric.
- Take the numerator only from
nightswith night_status == 'stayed'. units_sold_to_date at the final snapshot exceeds the stayed count by whatever cancels or no-shows afterwards, so reading the numerator off the snapshot overstates occupancy by exactly the late-cancellation rate. - Aggregate as a ratio of sums: sum the numerator and the denominator to stay_date grain and divide once. Averaging per-property occupancies or per-property ADRs is a mean of ratios and breaks the identity, weighting a four-unit property the same as a four-hundred-unit one.
- Assert the identity with np.isclose on relative tolerance: revenue/sellable equals (revenue/stayed) times (stayed/sellable) is exact arithmetic when all three are computed over the same unit-date set, so a failure means the sets differ, usually a unit present in
nightsbut missing from the snapshot.
Worked solution 30 min
- Filter snap to snapshot_date <= stay_date, sort by ['supply_unit_id','stay_date','snapshot_date'], take .groupby(['supply_unit_id','stay_date']).tail(1) as the as-of row.
- Compute sellable = units_sold_to_date + units_available on those rows, and sum to stay_date grain; keep the per-unit frame around for the coverage check.
- Filter nights to night_status == 'stayed'; sum unit_revenue_usd (taxes excluded) and count rows, both to stay_date grain.
- Left join on stay_date, then divide: occupancy = stayed / sellable, adr = revenue / stayed, revpan = revenue / sellable.
- Assert np.isclose(revpan, adr * occupancy, rtol=1e-9) and report any stay_date where the unit sets differ between the two sources.
Follow-up
- Occupancy comes out above 1.0 on three stay dates. Give the two most likely causes and how you would tell them apart.
- Rewrite the denominator on the physical-capacity convention. Which direction does occupancy move, and for which supplier type does the gap get large?
- Now split by property_class. Why can every class's occupancy rise while the blended figure falls?
Zero-result search rate by market and lead-time bucket
fct_search has one row per submitted search: search_id, searched_at_utc, destination_market_id, lead_time_days, length_of_stay_nights, results_returned_count and is_bot_flagged. Write one query returning, per destination_market_id, per lead-time bucket (0, 1-7, 8-30, 31-90, 91+ days) and per ISO week of searched_at_utc, the count of searches that returned nothing, the count of non-bot searches, and the zero-result rate. Exclude is_bot_flagged rows from both numerator and denominator. The weekly figure must be re-summed from the underlying counts rather than averaged from daily rates.
Approach
- Apply the is_bot_flagged filter once in a base CTE so numerator and denominator are drawn from the same set; a filter applied only to the denominator can push the rate above 1 on a bot-heavy day.
- Bucket the stored lead_time_days column with a CASE expression rather than recomputing check_in_date minus the search date; the stored value is frozen and survives date amendments, so it matches the rest of the metric tree.
- Aggregate with COUNT() FILTER (WHERE results_returned_count = 0) alongside COUNT(), which produces numerator and denominator in one pass and guarantees they share a group.
- Group by market, bucket and DATE_TRUNC('week', searched_at_utc), then compute the rate as the ratio of the two summed counts at the week grain.
- Return both raw counts next to the rate so a consumer can re-aggregate across markets, across buckets, or to a multi-week period, without returning to the source table. Note the limit of that promise: week buckets are not nested inside calendar months, so a monthly figure is not reachable from this output.
Follow-up
- Split the numerator into supply shortage versus restriction using fct_rate_availability_snapshot. How do you join it so you only see what the traveller could actually see?
- The rate jumped four points in one market last week. Which breakdown do you cut first, and what would make you believe it is a supply change rather than a demand mix change?
- Why is the UTC date of searched_at_utc the wrong day boundary for a market twelve hours ahead, and what would you group on instead?
Intent-to-booking conversion within a seven-day attribution window
fct_search carries trip_intent_key, searched_at_utc, device_type, lead_time_days, results_returned_count and is_bot_flagged; fct_booking carries booking_id, trip_intent_key, booked_at_utc and booking_status. For intents whose first qualifying search falls in one month, compute the intent-to-booking rate: an intent converts if any booking shares its trip_intent_key and was booked within seven days of that first search, counting bookings that later cancel. Qualifying searches are is_bot_flagged = FALSE with results_returned_count > 0. Report numerator, denominator and rate by device_type and lead-time bucket.
Approach
- Filter to qualifying searches first, then collapse to one row per trip_intent_key using MIN(searched_at_utc), and state the convention plainly: an intent whose earliest search returned nothing is cohorted on its first search that did return results.
- Carry device_type and lead_time_days from that first qualifying search, picked with ROW_NUMBER or FIRST_VALUE. One intent routinely spans mobile and desktop, and attributing it to the device of the converting search inflates whichever device closes.
- Aggregate bookings to one row per trip_intent_key with MIN(booked_at_utc) before joining. Joining raw bookings makes an intent with three bookings count three times in the numerator and, once grouped, in the denominator too.
- LEFT JOIN the booking aggregate onto the intent set and flag conversion where booked_at_utc falls within [first_search_at, first_search_at + 7 days]. Keep cancelled and no-show bookings in: this metric measures demand conversion, not delivery.
- Group by device and bucket, summing the flag and counting intents, and compute the rate as the ratio of those two sums rather than as an average of per-cell rates.
Worked solution 30 min
- Count rows, distinct trip_intent_key and distinct visitor_id over the search window, so searches-per-intent is a number you can quote rather than assume.
- Build the intent CTE with first-qualifying-search attributes and verify its row count equals the distinct intent count.
- Build the booking CTE at one row per trip_intent_key and compare it with the raw booking count to see how many intents carry more than one booking.
- LEFT JOIN, apply the seven-day predicate, and confirm the joined row count still equals the intent count.
- Aggregate by device and bucket, then re-sum the cells and check the total against a directly computed overall figure.
Follow-up
- Mobile converts at half the desktop rate. How much of that gap is mix, and what decomposition would you run to show it?
- How do you hold the seven-day window open without restating last week's published number every morning?
- A ranking change cuts searches per intent by 20% and leaves bookings flat. What happens to this metric, and what happens to a search-denominated version of it?
How would you predict the "No-Show" rate for a specific flight?
How would you predict the "No-Show" rate for a specific flight?
Approach
- Fix the population and the time window before naming any metric.
- Decompose the metric into the rates that drive it, and say which one you would check first.
- State what result would change your recommendation, so the answer is falsifiable.
Follow-up
- What would you do if the primary metric and the guardrail moved in opposite directions?
- How would you detect that the metric is being gamed rather than genuinely improving?
Quantify unmet demand in sold-out destination markets
A supply team must decide which destination markets to recruit into next quarter. They want a measure of unmet demand: trips travellers wanted and could not buy. Bookings cannot show it, because a sold-out date records capacity rather than demand. Available: fct_search (trip_intent_key, searched_at_utc, destination_market_id, check_in_date, length_of_stay_nights, lead_time_days, results_returned_count, min_result_price_usd, is_bot_flagged), fct_rate_availability_snapshot keyed on (supply_unit_id, stay_date, snapshot_date) with units_available, is_closed_to_arrival, min_length_of_stay and listed_price_usd, dim_supply_unit (supply_unit_id, destination_market_id, property_class, capacity_units) and fct_booking. Note the shape of the join before you design anything: the search records a market and no unit, the snapshot records a unit and no market, and dim_supply_unit is the only bridge between them. Propose a measurable proxy, state its bias in direction and rough size, and say which decision it can and cannot support.
Approach
- Say plainly that the estimand - intents that would have converted at a price the traveller would have paid, had a unit been open - exists in no table, and that everything downstream is a proxy carrying a stated bias.
- Resolve the candidate set explicitly, because the two fact tables do not meet directly: map each search's destination_market_id to its supply_unit_id set through dim_supply_unit, then take the snapshot rows for those units at stay_date covering the searched nights and snapshot_date equal to the search date. State the approximation this forces - the search stores no list of units it considered, so the candidate set is every unit in the market rather than the set ranking actually returned.
- Build the proxy from the censoring indicator rather than from bookings: count DISTINCT trip_intent_key where every candidate unit-date resolved that way had units_available = 0, and keep intents suppressed by is_closed_to_arrival or min_length_of_stay in a separate bucket, because a restriction is a different owner and a far cheaper fix than recruiting supply.
- Anchor the conversion assumption instead of hiding it: apply the observed intent-to-booking rate from comparable unconstrained cells matched on destination_market_id, lead-time bucket and length_of_stay_nights, rather than assuming every blocked intent would have booked.
- Enumerate the bias with direction on each mechanism. Upward: repeat searching within one intent that trip_intent_key does not fully collapse, is_bot_flagged false negatives, and browsing that was never going to convert. Downward: travellers who saw a sold-out market once and never searched again are absent entirely, intents deflected by a high min_result_price_usd never register as zero-result at all, and the market-wide candidate set is stricter than the traveller's own filters, so an intent whose acceptable units were all gone still counts as satisfied if any unit in the market was open.
- Bound the decision the number is licensed to support: it ranks markets by relative constraint, which is what a recruitment queue needs, and it cannot be converted into revenue per added unit without a price at which the marginal unit would have sold, which requires a deliberate supply or price test.
Worked solution 40 min
- Build the bridge first: join fct_search to dim_supply_unit on destination_market_id to get the candidate supply_unit_id set, then join to fct_rate_availability_snapshot on supply_unit_id with snapshot_date equal to the UTC date of searched_at_utc and stay_date between check_in_date and check_in_date + length_of_stay_nights - 1, so the availability in the join is the availability the traveller actually had. Write down that the market-wide candidate set is a stated approximation of the ranked result set.
- Collapse to trip_intent_key and classify each intent as satisfied, supply-blocked (every candidate unit-date at units_available = 0) or restriction-blocked (units open but excluded by is_closed_to_arrival or min_length_of_stay).
- Estimate the counterfactual conversion rate from unconstrained cells matched on destination_market_id, lead-time bucket and length_of_stay_nights, and carry its uncertainty forward.
- Produce a per-market ranking with an interval rather than a point estimate, and re-run it with is_bot_flagged rows excluded to test robustness.
- Write the bias statement as part of the deliverable, with a direction and a rough magnitude for each named mechanism.
Follow-up
- The top-ranked market by this proxy also has the most bot traffic. How do you check whether the ranking survives?
- A rival estimate uses waitlist sign-ups. What does that measure that yours does not, and what does it miss that yours catches?
- What experiment would convert this ranking into an expected revenue figure per added supply unit?
Blended daily rate fell while every segment's rate rose
Blended ADR for last month, computed from fct_stay_night as SUM(unit_revenue_usd) / COUNT(*) over night_status = 'stayed' at a fixed reference FX rate, fell 4.2% year over year. Cut by destination_market_id, by property_class and by rate_plan, every segment's ADR rose. Commercial leadership is drafting a note about discounting. Using fct_stay_night joined to dim_supply_unit (property_class, destination_market_id) and fct_booking (rate_plan, lead_time_days), quantify how much of the -4.2% is mix and how much is within-segment, and show that your segmentation choice is not doing the work.
Approach
- Write the identity before computing anything: blended ADR equals the sum over segments of w_s times ADR_s, where w_s is segment s's share of stayed nights. The change then decomposes into a mix term, sum of (w_s1 - w_s0) times ADR_s0; a within-segment term, sum of w_s0 times (ADR_s1 - ADR_s0); and an interaction term. Report the interaction rather than folding it silently into one side.
- Choose the segmentation from the mechanism rather than from convenience: market by property_class by rate_plan by lead-time bucket. A coarse cut leaves mix hiding inside segments, which makes the decomposition understate exactly the term you are trying to size.
- Compute w_s on stayed nights, the same denominator the metric uses. Weighting by bookings or by revenue produces terms that do not re-aggregate to the published blended ADR, and the reconciliation failure is how you will find out.
- Test that the answer is not an artefact of the cut. Rerun at two or three segmentation depths and report the spread in the mix share; if it swings wildly, the finest cut is fitting thin cells and the cell counts belong next to the numbers.
- Only now ask what moved the weights, and look for a cause with a date attached: a market that grew supply, a channel that brought shorter lead times, a seasonal shift in party size or length of stay.
Follow-up
- You have the decomposition. What do you actually recommend, given within-segment rate is up?
- The mix moved because one low-ADR market grew 40% year over year. Is that a problem to fix or the plan working as intended?
- How do you keep this decomposition honest when a segment exists this year that did not exist last year, so w_s0 is zero for it?
Roughly 90 minutes a night on weekdays with one longer weekend block. The plan deliberately cuts scope rather than compressing everything, on the assumption that finishing one thing a night beats half-starting four.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Fix the scope and set a baseline
- Read the role description and write the three things the loop will almost certainly test, then write an explicit not-doing list for everything else and keep it visible all week.
- Take one 20-minute SQL prompt and one 10-minute metric question cold, and write the single sentence that says what blocked each attempt, since that sentence is what decides which two topics get the most evenings.
- Set the week's one rule: one problem finished to completion every night, including the night you only have 40 minutes.
Deliverable: A one-page scope with an explicit not-doing list and two cold attempts, each carrying one sentence on what blocked it.
Practice prompt ↗Practice prompt ↗Worked solution ↗02One query pattern, written three times
- Choose the single pattern most likely to appear (a cohort retention grid, or a funnel counted by user) and write it three times from a blank file rather than editing the previous attempt.
- On the third attempt, write the grain of every CTE as a comment before writing its body.
- Stop at 90 minutes even if the third version is imperfect, and write the one thing you would fix with another hour.
Deliverable: Three independent versions of the same query plus a note on what changed between them.
Practice prompt ↗Practice prompt ↗03Only the statistics you will be asked to defend
- Write, in under 200 words, how you would decide whether a difference between two groups is real: the test, its assumptions, and what you would switch to when an assumption fails.
- Compute a 95 percent confidence interval for a difference in proportions by hand on realistic numbers, then write in one sentence what changes if the two samples are paired rather than independent.
- Write your answer to "what does a p-value mean", check it against a definition, and delete the version that describes it as the probability the hypothesis is true.
Deliverable: A 200-word written answer and one hand-computed interval you can reproduce under pressure.
Practice prompt ↗Practice prompt ↗04One case, and the assumptions holding it up
- Answer one product case aloud in 20 minutes with a recording running, then listen back with a pen and mark every claim you asserted without saying what it rested on: an assumed user behaviour, an assumed data source, an assumed baseline rate, an assumed grain.
- Pick the three assumptions the recommendation actually depends on, write how you would check each one against data, and say which one being wrong would flip the recommendation rather than merely weaken it.
- Write the four-step structure you used onto a card small enough to hold in working memory when you are nervous.
Deliverable: One recording, three load-bearing assumptions each with a written check, and a four-step structure card.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Your own work, timed
- Write a 90-second version and a four-minute version of your main project, and time both out loud rather than reading them.
- Prepare answers to the two follow-ups that always come: what you would do differently, and how you knew it worked.
- Put one number in the first sentence and be able to say exactly where that number came from and what it excludes.
Deliverable: Two timed narratives with one defensible number in the opening line.
Practice prompt ↗Practice prompt ↗06The one full rehearsal, in a longer weekend block
- Run a 60-minute mock covering query work, a case and a behavioural question in a single sitting with no breaks, because sustained attention is the thing evenings have not trained.
- Immediately afterwards, and before hearing any feedback, write the three moments you lost the thread.
- Spend the rest of the block only on those three moments, and on nothing you merely feel shaky about.
Deliverable: Mock notes naming three failure moments with a specific fix written under each.
Practice prompt ↗07Taper
- Write the 20-minute warm-up you will actually do on the morning of the interview: one query you can already write from a blank file, one metric you can define out loud, and nothing you have never seen before.
- Re-read only your own notes from this week, and open no new material.
- Write down the logistics: the tool you will be asked to work in, whether lookups are allowed, and the sentence you will use when you do not know something.
Deliverable: A one-page card holding the case structure, the project numbers, and the logistics.
Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
A number you shipped turned out to be wrong, and someone had already acted on it. That is one of the most useful stories a data person can carry. What is being scored is how fast you noticed, who you told first, and what you changed in the process so the same class of error could not repeat quietly.
Tell me about a time you had to explain a technical failure to a non-t…
Tell me about a time you had to explain a technical failure to a non-technical stakeholder.
Approach
- Name the disagreement or constraint, and how you resolved it with evidence.
- Pick a story where you drove the decision, not one where you observed it.
- Quantify the outcome, including what you would not claim credit for.
Follow-up
- What did you decide not to do, and why?
- How did you know the outcome was caused by your change?
Describe a situation where you had to work with a difficult teammate. …
Describe a situation where you had to work with a difficult teammate. How did you manage the relationship?
Approach
- Close with what you would do differently, concretely.
- Quantify the outcome, including what you would not claim credit for.
- Pick a story where you drove the decision, not one where you observed it.
Follow-up
- How did you know the outcome was caused by your change?
- What did you decide not to do, and why?
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 had to explain a technical failure to a non-technical stakeholder.
- 02
Describe a situation where you had to work with a difficult teammate. How did you manage the relationship?
- 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 Qantas interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Qantas. Rounds and questions reflect what candidates have reported, not a process Qantas has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult is the technical interview at Qantas?
The difficulty is generally rated as difficult to very difficult. While the questions are "stock standard" in terms of data science topics, the depth of follow-up questions and the requirement to apply concepts to aviation scenarios make it challenging.
PracHub interview research ↗What is the typical timeline from application to offer?
Qantas is known for a relatively smooth and quick communication process. Candidates often hear back within one to two weeks after each round, with the entire process typically concluding within a month.
PracHub interview research ↗Does Qantas offer remote or hybrid work for Data Scientists?
Qantas generally follows a hybrid model, with a presence required at their major hubs like Mascot in Sydney. However, specific team arrangements may vary, so it is best to clarify this during the recruiter screen.
PracHub interview research ↗What makes a candidate stand out in the Qantas interview?
Candidates who show a genuine interest in the aviation industry and can demonstrate how their models drive commercial value stand out. Being able to talk about the "fun" and "relevance" of the technical assessment also leaves a positive impression.
PracHub interview research ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
PracHub page · Accessed 2026-09-22 - 02PracHub Data Scientist practice ↗
Cross-company practice questions for this role.
PracHub page · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Booking.com Data Scientist Interview Questions & Guide 2026
A prep plan for Booking.com 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 days later ins
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
United Airlines Data Scientist Interview Questions & Guide 2026
Statistics practice aimed at United Airlines candidates: conditional probability, sampling distributions, confidence intervals people routinely misread, and saying out loud which assumption a test depends on.
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.