Likely Flight Delay Prediction Interview questions.

Tell me about this project. What were you trying to accomplish?

I worked on a flight delay prediction project where I wanted to see whether Graph Neural Networks could better capture how delays propagate through the airline network.

The main problem I was addressing is that traditional machine learning models typically treat each flight as an independent row of data. But in reality, flights are interconnected. For example, if an aircraft arrives late at one airport, that can cause its next flight to depart late, and delays at major hubs can also affect connected airports.

So I modeled the U.S. airport network as a graph, with airports as nodes and flight routes as edges, and combined that graph structure with flight, aircraft rotation, and weather information. I compared several GNN architectures, including a basic GCN, GraphSAGE, and a SemanticGNN, against traditional models like XGBoost and Ridge Regression.

One of the main things I focused on was making the predictions realistic. I evaluated the models at different prediction horizons, from essentially immediate predictions up to a week in advance, and masked information that wouldn't actually be available at that point in time.

Overall, the project showed that the graph-based models were particularly useful at longer prediction horizons, with GraphSAGE performing the best overall. I also found that previous flight delays were especially important for short-term predictions, while the broader airport and network information became more useful as the prediction horizon increased.

Why did you choose flight delays as the problem?

I chose flight delays because it was a problem where the structure of a graph naturally matched the real-world problem.

A flight isn't really an isolated event. Airports are connected by routes, and aircraft move through those airports in sequences. If an aircraft arrives late at one airport, that can affect its next flight, and delays at major hubs can propagate to other airports through the network.

That made flight delay prediction a good opportunity to investigate whether a Graph Neural Network could capture relationships that a traditional tabular model might miss. I also liked that the problem had a clear practical objective: predicting delays could potentially help airlines identify disruptions earlier and make better operational decisions.

So the project wasn't just about predicting whether a flight would be delayed. I was specifically interested in whether modeling the relationships between airports and flights could improve prediction, particularly when making predictions further in advance

Why use a Graph Neural Network instead of XGBoost or another traditional model?

We actually tested XGBoost as one of our traditional machine learning baselines. The main reason we explored GNNs was that flight delays aren't independent events.

With a traditional tabular model like XGBoost, each flight is generally represented as an individual row with its own features. Even if we give the model information about that flight, it doesn't naturally represent the relationships between airports and routes.

For example, a disruption at a major hub like Atlanta could affect flights leaving Atlanta, which could then affect aircraft rotations and downstream flights at other airports. We wanted the model to be able to capture those network relationships directly.

So we represented airports as nodes and flight routes as edges, allowing the GNN to use information from neighboring airports through message passing. We then compared those models against XGBoost to see whether that relational information actually provided an advantage.

The interesting part was that XGBoost was competitive for immediate predictions, where we had information like the previous flight's delay. But as we increased the prediction horizon and that real-time information became unavailable, the GNNs were more robust because they could use the broader structure and historical behavior of the network.

What data did you use?

I used U.S. domestic flight data from 2023, which contained approximately 5.8 million flight records, and I integrated it with localized weather data.

The flight dataset contained several categories of information. I had temporal features such as date, day of the week, and scheduled departure and arrival times; spatial information through the origin and destination airports; and operational information including airline, aircraft tail number, route distance, taxi times, and wheels-off and wheels-on times.

One of the most important pieces of feature engineering I did was tracking aircraft rotations. I used the aircraft's tail number to follow its sequence of flights and calculate things like the previous flight's arrival and departure delay, turnaround time, and how many flights that aircraft had operated that day. That gave the model information about whether the aircraft itself was already running behind schedule.

I also merged in weather data for the origin airport, including temperature, dew point, wind speed, gusts, visibility, and precipitation.

For the targets, I approached the problem in two ways: predicting the actual arrival delay in minutes as a regression problem, and predicting whether the flight would be delayed by at least 15 minutes as a classification problem.

The source data actually included similar flight datasets for many other years, but for this project I focused on the complete 2023 dataset rather than combining multiple years. Even with 5.8 million flights, I had to be conscious of memory and computational constraints on my 8 GB laptop, so I designed the pipeline to process the flight-level data efficiently and keep the relatively small airport graph separate from the much larger feature matrix.

How did you deal with 5.8 million flight records?

The dataset was fairly large, with about 5.8 million flight records, and I was working on a laptop with 8 GB of RAM, so memory management was one of the practical challenges.

The main approach I took was to separate the static graph information from the much larger flight-level data. The airport graph itself was relatively small—about 322 airport nodes—while the flight-level feature matrix contained millions of observations. Rather than treating everything as one massive graph structure in memory, I kept the airport graph separate and processed the flight-level information efficiently during training.

For the GNN training, I also used batches of 4,096 records and monitored the training process with early stopping. That allowed me to work with the full 5.8 million flight records without needing to load the entire dataset into the model at once.

So the main challenge wasn't reducing the dataset—it was designing the pipeline so I could work with the full dataset within the memory and compute limitations of my machine.

What features did you engineer?

I engineered features at several levels of the flight network.

First, I created temporal features. I extracted things like hour of day, month, and day of the week, and represented the time of day using sine and cosine transformations so the model could recognize that times like 11 PM and midnight are close to each other.

Second, and probably most importantly, I engineered aircraft rotation features. I used the aircraft's tail number to order its flights chronologically and calculated the previous flight's arrival and departure delay, the turnaround time between flights, and the number of flights that aircraft had operated that day. These features were designed to capture the fact that a late aircraft can cause delays on its subsequent flights.

Third, I created historical airport and route features. For airports, I calculated things like average departure delay, and for specific routes I calculated historical average arrival and departure delays, average air time, elapsed time, and route distance. I calculated these statistics using the training data to avoid leaking information from the validation or test periods.

I also created missingness indicators for features where weather or previous-flight information wasn't available, rather than simply assuming the data was missing at random.

Finally, I incorporated weather variables such as temperature, wind, visibility, gusts, and precipitation, and encoded categorical variables like airline identity.

What was your target variable?

I actually had two target variables because I treated the problem as a multi-task prediction problem.

The first was a regression target, where I predicted the magnitude of the flight's arrival delay in minutes. I used a log-transformed version of the arrival delay for the regression task to make the target distribution easier for the model to handle.

The second was a classification target, where I predicted whether a flight would be significantly delayed—15 minutes or more.

So the model was learning two related things at the same time: how long a flight would be delayed, and whether it would cross the 15-minute delay threshold.

Why did you predict both regression and classification?

I used both because they answer two different questions about the same delay problem.

The regression task predicts how many minutes late the flight is expected to be, which gives us the magnitude of the disruption. The classification task predicts whether the flight will be significantly delayed, meaning 15 minutes or more.

I thought it was useful to evaluate both because an airline could care about both pieces of information. For example, knowing that a flight is likely to be delayed by 45 minutes is useful, but knowing whether it is likely to cross the 15-minute threshold is also useful for identifying flights that need attention.

It also gave me two different ways to evaluate whether the graph-based approach was actually useful. Instead of only asking, "Can the model predict the exact delay?", I could also ask, "Can it reliably identify flights that are going to experience a significant delay?"

What is “horizon-aware” prediction and why was it necessary?

Horizon-aware prediction means that the information available to the model depends on how far in advance we're trying to make the prediction.

For example, if I'm predicting whether a flight will be delayed 15 minutes before departure, I might have access to information about the aircraft's previous flight and its current operational status. But if I'm trying to predict that same flight several days in advance, I obviously wouldn't have that information yet.

So for my project, I evaluated the models at different prediction horizons, ranging from near-term predictions to several days in advance, and I masked features that wouldn't realistically be available at each horizon.

This was necessary because otherwise I could accidentally give the model information from the future. A model might appear extremely accurate because it's using information that wouldn't actually be known when the prediction would need to be made.

The goal was to make the evaluation more realistic: at each prediction horizon, the model should only use information that would actually be available at that point in time.

How did you prevent data leakage?

I prevented data leakage in a few ways.

First, I used a time-based train, validation, and test split rather than randomly splitting the flights. I trained on earlier dates, validated on a later period, and tested on the most recent period. That better represents the real-world situation where we're using past data to predict future flights.

Second, I made the feature engineering horizon-aware. For each prediction horizon, I only allowed the model to use information that would actually be available at that point. For example, previous-flight delay can be used for a near-term prediction, but it can't be used when making a prediction several days in advance because that previous flight hasn't happened yet.

Third, for historical features such as average airport and route delays, I calculated those statistics using training data only rather than calculating them across the entire dataset. Otherwise, information from future flights could leak into the features used to predict earlier flights.

So overall, I tried to make sure that when the model was predicting a flight, it only had access to information that would have been known at that time.

Why did you choose GraphSAGE?

I didn't specifically choose GraphSAGE upfront. I wanted to evaluate whether graph-based models were useful for this problem, so I tested three different GNN architectures: a basic GCN, GraphSAGE, and SemanticGNN.

The goal was to see whether different ways of learning from the airport network would produce different results. The basic GCN gave me a relatively straightforward graph convolution baseline, GraphSAGE allowed the model to aggregate information from neighboring nodes, and SemanticGNN gave me another approach for incorporating the different relationships and features in the network.

I then compared all three models across the different prediction horizons and against my traditional machine learning baselines. GraphSAGE ended up performing the best overall, so that was a result of the experimentation rather than a decision I made before training the models.

What was the difference between BasicGNN, GraphSAGE, and SemanticGNN?

The three models mainly differed in how they used the graph structure and aggregated information from neighboring airports.

BasicGNN was the simplest graph-based baseline. It used the airport graph to pass information between connected nodes, giving us a straightforward way to test whether adding graph structure was useful at all.

GraphSAGE also used information from neighboring nodes, but it specifically uses neighborhood aggregation to learn a representation for each node based on its own features and information from its neighbors. This gives it a more flexible way of learning from the local network structure.

SemanticGNN was designed to incorporate different types of relationships and information in the graph rather than treating all of the graph information in exactly the same way. In our case, that allowed us to incorporate the different semantic relationships and features associated with the airport network.

So the main reason I tested all three was to see whether the way the model used the graph structure affected prediction performance. GraphSAGE ended up being the strongest overall, but I didn't assume that going into the experiment.