Iata Data Scientist Interview: Questions, Experience & Prep (2026)

IATA (International Air Transport Association) is the global trade body for the airline industry. Its Data Scientist roles sit at the intersection of aviation economics, safety analytics, and digital transformation. With 38 open roles tracked by knok jobradar as of July 2026, IATA is one of the more active aviation-sector hirers for data professionals.

The work spans airline safety reporting, passenger and cargo traffic modelling, sustainability metrics (including SAF adoption and emissions tracking), and financial settlement systems used by airlines worldwide. Candidates typically bring domain exposure in transportation, logistics, economics, or large-scale time-series forecasting.

Salary bands across the Indian data science market, per knok jobradar data, run from 8-16 LPA for entry-level profiles (0-2 years) to 18-30 LPA at mid-level (3-5 years), 30-48 LPA for senior roles (6-9 years), and 45-70+ LPA at Lead or Principal level. IATA does not separately publish India-specific compensation figures, so treat these as market benchmarks.

In the broader Data Scientist market tracked by knok jobradar across 937 total active postings, Bangalore leads with 166 open roles, followed by Delhi (46), Hyderabad (27), Pune (18), Mumbai (17), and Chennai (8). IATA roles are distributed across its regional and global offices, so confirm location details with your recruiter.

Candidates report a process that typically includes an initial HR screening call, a technical assessment or case study, and one or more panel rounds with data and domain leads. Questions tend to test both core data science fundamentals and aviation-sector awareness.

1. Walk me through a forecasting model you built. How did you choose between time-series approaches?
2. IATA handles irregular operations data such as delays, cancellations, and schedule disruptions. How would you build an anomaly detection system for flight operations?
3. How would you model passenger demand across routes when you have missing or inconsistent historical data?
4. Describe your experience with large, multi-source datasets. How did you ensure data quality before modelling?
5. IATA produces global safety reports. How would you design a dashboard to help airline safety teams identify risk patterns?
6. How would you approach building a model to forecast jet fuel consumption trends for a regional airline cluster?
7. Explain a time you had to communicate a complex analytical finding to a non-technical stakeholder. What did you change in your approach?
8. How would you evaluate the business impact of a new pricing recommendation model for an airline?
9. IATA works across regulatory, airline, and airport stakeholders. How do you handle conflicting requirements when scoping an analytics project?
10. Which Python libraries do you use for time-series analysis, and what are their trade-offs?
11. How would you handle class imbalance in a safety incident prediction model?
12. IATA is expanding work on sustainability metrics. How would you quantify the carbon offset impact of Sustainable Aviation Fuel (SAF) adoption across a fleet?

Q: Walk me through a forecasting model you built. How did you choose between time-series approaches?

*Situation:* My team needed to forecast monthly cargo volumes for a logistics client across multiple origin-destination pairs, with several years of historical data available.

*Task:* I was responsible for model selection, training, and handing over a production-ready pipeline to the engineering team.

*Action:* I first ran stationarity tests (ADF and KPSS) on each series. Several routes showed strong seasonality with trend, so I used SARIMA as a baseline, then compared it against Facebook Prophet and a gradient-boosted tree model with lag features. I used rolling cross-validation with a 3-month forecast horizon to avoid data leakage. Prophet performed best on routes with clear seasonality, while XGBoost with lag features won on noisier routes. I documented the selection criteria so the business team could understand why different models ran for different routes.

*Result:* Mean absolute percentage error dropped meaningfully versus the existing moving-average baseline, and the pipeline ran in production for over a year with quarterly retraining.

---

Q: How would you handle class imbalance in a safety incident prediction model?

*Situation:* At a previous role, I built a model to flag high-risk maintenance events before they escalated. Safety incidents were rare, making up a very small share of labelled records.

*Task:* I needed a model with high recall on the minority class, because missing a true positive carried far more cost than a false alarm.

*Action:* I tried three strategies: SMOTE oversampling on the training set, adjusting class weights in the loss function, and threshold tuning on the probability output. I evaluated all three using precision-recall curves rather than accuracy, since accuracy was misleading given the imbalance. Threshold tuning combined with class-weight adjustment gave the best recall without flooding operations with false positives. I presented the trade-off to the safety team as a curve, not a single number, so they could choose the operating point themselves.

*Result:* The model was accepted for a pilot after the safety team understood and owned the threshold decision. Showing domain stakeholders the trade-off rather than picking a number for them built trust in a safety-critical context.

---

Q: How would you communicate a complex analytical finding to a non-technical stakeholder?

*Situation:* I had built a route profitability segmentation model and needed to present findings to a commercial director with no data background.

*Task:* I had to translate cluster outputs into actionable recommendations without losing the nuance of the analysis.

*Action:* I dropped all model jargon and reframed each cluster as a business persona, for example 'high-volume, low-yield leisure routes' versus 'low-volume, high-yield business routes.' I used a single visual, a scatter plot of yield against load factor with cluster colours, and anchored each point to a named route the director recognised. I prepared a one-page brief that led with the recommendation, not the methodology.

*Result:* The director approved a pricing trial on two route segments within the same meeting. The methodology section moved to an appendix and never came up in discussion.

The STAR method (Situation, Task, Action, Result) works well for behavioural questions. Keep Situation and Task brief, two to three sentences combined, and spend the bulk of your time on Action and a concrete Result.

For technical questions, candidates report that IATA panels appreciate a structured walk-through: state your assumptions first, then your approach, then the limitations. Avoid jumping straight to a tool name like 'I would use XGBoost' before explaining why it fits the problem.

For domain questions about aviation data, use this structure:

• Restate the business problem in plain terms
• Identify what data you would need and likely gaps
• Describe the modelling or analytical approach
• Explain how you would validate and communicate the output

On numbers and metrics: always anchor your answer to a business outcome, not just a model metric. MAPE and F1 scores matter less to IATA stakeholders than 'this improved on-time performance reporting accuracy' or 'this reduced manual reconciliation in the settlement process.'

Hedging appropriately: when you do not know a domain detail, say so directly and explain how you would find out. Interviewers at trade bodies like IATA typically value intellectual honesty over bluffed expertise.

Based on publicly reported candidate feedback and the nature of IATA's work, panels typically look for five things.

Domain curiosity. IATA is not a tech company. It is a membership organisation serving airlines and regulators. Candidates who show genuine interest in aviation economics, safety standards, or sustainability policy tend to stand out. Reading IATA's public economics reports before your interview demonstrates this clearly.

Rigorous statistical thinking. Aviation data is messy: irregular operations, seasonal spikes, missing legs, and multi-currency financial data. Panels want to see that you think carefully about data quality, distributional assumptions, and model failure modes before reaching for a library.

Stakeholder communication. IATA data scientists typically present findings to airline executives, government regulators, and airport operators, not just internal data teams. Your ability to simplify without oversimplifying is tested directly.

Python and SQL fluency. Candidates report that technical screens cover SQL window functions, pandas and NumPy operations, and at least one ML implementation task. Writing clean, readable code matters more than showing off clever one-liners.

Global and cross-cultural sensitivity. IATA operates across a large number of countries globally. Interviewers may probe how you have worked in or adapted to diverse team contexts.

Two to three weeks out:
Read the IATA Economics pages and the most recent 'World Air Transport Statistics' summary. Note key terms that come up repeatedly, such as RPK (revenue passenger kilometres), cargo tonne-kilometres, and load factor, so you can use domain vocabulary naturally.

Review time-series fundamentals: stationarity, ARIMA and SARIMA, Prophet, and how to do proper walk-forward validation. These appear repeatedly in candidate reports for aviation-sector data science roles.

Refresh SQL: window functions (ROW_NUMBER, LAG, LEAD, PARTITION BY), CTEs, and aggregation on large tables.

One week out:
Practise three to five STAR stories covering a forecasting or regression project, a stakeholder communication challenge, a data quality problem you solved, and a time you had to work under ambiguity.

Prepare two or three questions for the panel that show sector awareness, for example: 'How does the team balance real-time operational data with the slower reporting cycles that airlines submit to IATA?' or 'What does the data infrastructure look like for ingesting member airline data at scale?'

The day before:
Review your resume line by line. Be ready to go deep on any project you have listed. Panels often pick one project and probe every technical decision you made.

Knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you, so keep your profile updated if you are tracking multiple IATA or aviation-sector openings in parallel.

Treating IATA like a product company. Candidates sometimes pitch ideas around 'building an AI product' or 'shipping features.' IATA is a standards and membership body. Frame your value around rigorous analysis, policy-relevant insights, and multi-stakeholder reporting.

Skipping domain prep. Walking in with strong Python skills but no knowledge of how airline settlement systems work, or what BSP stands for, signals that you did not research the organisation. Thirty minutes on IATA's public website closes most of this gap.

Jumping to models before problem framing. A common report from candidates who did not advance is that they named tools immediately without scoping the problem. Always start with: what is the business question, and what data would you need?

Using accuracy as the primary metric. For the kind of imbalanced, high-stakes data IATA works with (safety incidents, fraud in settlement systems), accuracy is almost never the right headline metric. Use precision, recall, AUC-PR, or a business cost framing instead.

Weak answers on communication. If your STAR stories for communication questions focus only on what you built rather than how you changed your audience's understanding or decision, you will not score well. The output of a communication effort is a decision made, not a slide deck delivered.

Not asking questions. Panels at membership organisations are often genuinely curious whether you understand their mission. Asking no questions at the end signals low interest.