Interview Questions — Titanic Survival Prediction¶

This project demonstrates the full supervised learning workflow: data cleaning, feature engineering, model selection, hyperparameter tuning, and evaluation — on a dataset small enough to understand completely and complex enough to require real decisions at every step.

Q1: Why is Titanic a good first data science project?¶

Show answer

The Titanic dataset hits a rare combination: it is small enough to load into memory in milliseconds and understand completely, but it requires real decisions at every stage. The missing values are not random — they correlate with the target. The most informative feature (sex) is categorical, not numeric. The best engineered feature (title extracted from name) requires domain knowledge to discover. The relationship between family size and survival is non-linear, which means a model that only knows linear relationships will underperform.

It also has a ground truth that students can reason about from first principles: "women and children first" is historical fact. When your model ranks sex and title as the top features, that is validation — your model learned something real, not a spurious correlation.

Finally, the Kaggle competition for Titanic has a public leaderboard, so students can benchmark their work against thousands of other data scientists and get immediate feedback on whether their feature engineering and model tuning actually helped.

Q2: How did you handle missing age values? Why not drop those rows?¶

Show answer

Age is missing for 177 of 891 passengers — about 20% of the training set. Dropping those rows would shrink the training set by a fifth and introduce selection bias: missingness in age correlates with passenger class (third-class passengers were less likely to have recorded ages), so the dropped rows are not a random sample.

Instead, age was imputed with the median (28.0 years), using SimpleImputer(strategy='median') inside a sklearn Pipeline. Median is preferred over mean here because the age distribution has a right tail — a few elderly passengers pull the mean upward, and median is robust to those outliers.

The imputation is fitted on the training set only and then applied to the test set. Fitting on the full dataset would leak test set statistics into the preprocessor, which overstates test performance.

The age_bucket feature partially compensates for imputation noise. Passengers with imputed ages will land in the young_adult or adult bucket, which groups them with genuinely similar-aged passengers rather than treating each imputed value as precise.

Q3: What did you do with the deck column and why?¶

Show answer

The deck column was dropped entirely. It has 688 missing values out of 891 passengers — 77.2% missingness. Critically, this missingness is not random: third-class passengers rarely had assigned cabins and therefore have no deck entry. Imputing 688 values from only 203 known values would mean fabricating the majority of a feature's content, which tends to produce noise rather than signal.

Before dropping, it is worth noting that deck information would be genuinely useful — passengers on higher decks (closer to the boat deck) had faster lifeboat access. The missingness is itself informative: a deck_known binary flag was considered as an alternative, since knowing whether a passenger had a recorded deck correlates with first-class status, which correlates with survival. In this implementation the flag was not added, but it is a valid extension worth trying.

The lesson: high missingness is not automatically a reason to drop a column, but when the missingness rate is 77% and imputation would require fabricating most of the feature, dropping is safer than creating a column that is 77% fictional data.

Q4: Why did you extract a title feature from the name column?¶

Show answer

The name column appears useless at first glance — every value is unique, so it cannot be one-hot encoded directly. But names in early 20th-century passenger records follow a rigid format: Last, Title. First Middle. The title encodes information that other columns capture imperfectly.

Master is the key discovery: in that era, "Master" was used exclusively for boys under roughly 13 years old. This matters because age is 20% missing. When age is null, the model cannot use the "children survive more" signal — but title == Master flags male children even when their age is not recorded. This single insight accounts for a meaningful share of the accuracy improvement from 78% to 83%.

Beyond Master, titles encode sex (Mr vs Mrs/Miss) and, for rare titles (Lady, Countess, Sir), high social status. After grouping rare titles into a single Rare category, the final title feature has five levels: Mr, Mrs, Miss, Master, Rare — each with a distinct survival rate.

This is a textbook example of why you should understand what your raw columns actually represent before deciding to drop them.

Q5: Which features were most predictive? Does that match the historical record?¶

Show answer

Permutation importance on the held-out test set ranked features in this approximate order:

sex_female — shuffling this feature drops accuracy by ~9 percentage points
title_Master — identifies male children, a high-survival group
pclass — first-class survival rate (63%) vs third-class (24%)
fare — a proxy for class and deck position
fare_per_person — normalises shared tickets
family_size — small families survived better than solo travellers or very large groups

This matches the historical record precisely. The "women and children first" order of evacuation is directly quantified by features 1 and 2. The class hierarchy — first-class passengers had cabins closer to the boat deck, better information about what was happening, and were served by crew more attentively — is captured by features 3 and 4.

The embarkation port features ranked near the bottom, which also matches expectations: port survival differences in the raw data are almost entirely explained by the class composition of passengers boarding at each port. Cherbourg had proportionally more first-class passengers, which is why its survival rate looked higher.

Q6: Your model gets 83% accuracy — is that good? How would you explain it to a non-technical stakeholder?¶

Show answer

83% is meaningfully better than the 61.5% baseline (predicting "everyone died"), so the model has learned something real. In the context of the Kaggle leaderboard, 83% puts this model approximately in the top third of public submissions. It is a solid first result without heavy feature engineering or ensemble methods.

Whether it is "good" depends on the use case, but for a historical analysis project it is excellent — the remaining 17% of errors are largely passengers the dataset does not have enough information to classify correctly (luck, proximity to a specific lifeboat, etc.).

For a non-technical stakeholder, the explanation might be: "If I show this model a passenger's sex, ticket class, age, and a few other details, it correctly predicts whether they survived roughly 5 out of every 6 times. The model learned that women and first-class passengers were far more likely to survive — which matches what historians know about how the evacuation unfolded. The 17% of cases it gets wrong are mostly passengers who beat the odds or were victims of bad luck that no data can predict."

Avoid saying "83% accuracy" without context. Always anchor it against the baseline.

Q7: What is the difference between precision and recall here, and which matters more?¶

Show answer

For class 1 (survived):

Precision (0.82): Of all passengers the model predicted would survive, 82% actually did. High precision means when the model says "survivor," it is usually right.
Recall (0.74): Of all passengers who actually survived, the model identified 74% of them. Low recall means the model missed 26% of actual survivors — it predicted they died.

The model has higher recall for deaths (0.91) than for survivors (0.74) because deaths are the majority class. The model is implicitly biased toward predicting death when uncertain.

Which matters more depends entirely on the application. For this historical analysis project, both error types are equally important — we want to understand the survival pattern accurately. In a hypothetical rescue triage scenario where resources are limited, recall for survivors matters far more: failing to identify a survivor (false negative) means leaving someone behind, which is far worse than incorrectly prioritising a non-survivor (false positive). In a fraud detection analogy: precision matters when false alarms are costly, recall matters when missing a real case is costly.

The F1-score (0.78 for survivors) is the harmonic mean of precision and recall — it penalises a large gap between the two and gives a single number that balances both concerns.

Q8: If you had more time, what would you try to improve this model?¶

Show answer

Several extensions are worth pursuing, roughly in order of expected impact:

Feature engineering: - Extract cabin deck from the partial deck data and create a deck_known binary flag. Even with 77% missingness, the 23% of passengers with known decks might add a useful interaction. - Add a ticket prefix feature — ticket numbers often have alphabetical prefixes that correlate with cabin location and passenger class. - Create a sex_class interaction feature explicitly, since the EDA showed that the combination of sex and class is more predictive than either alone.

Modelling: - Try XGBoost or LightGBM — gradient boosting implementations that are faster and often slightly better-tuned than sklearn's GradientBoostingClassifier. - Build a stacking ensemble: train Logistic Regression, Random Forest, and Gradient Boosting as base models, then use a second-level Logistic Regression on their predictions. Stacking tends to add 0.5–1% when the base models make different types of errors. - Apply CalibratedClassifierCV to ensure the model's predicted probabilities are well-calibrated, not just its class labels.

Evaluation: - Submit to the Kaggle Titanic competition to get an objective leaderboard score on the held-out 418-passenger test set. - Run a threshold analysis: the default 0.5 classification threshold is not necessarily optimal. Plotting precision and recall across thresholds from 0 to 1 shows whether a different threshold improves the metric you care about most.

← Model Building | ← Evaluation