Predicting employee churn where imbalance and interpretability both mattered.
An end-to-end ML pipeline on 4,600+ employee records — built to answer a real HR question, not to win a leaderboard: which people are most likely to leave, and what specifically can a manager do about it?
An imbalanced dataset and a non-technical audience.
The dataset had roughly 4,600 employee records and a clear question underneath it: which people are most likely to leave next quarter, and why? The answer had to fit two constraints that shaped every choice downstream.
First, the labels were imbalanced — 34% churn, 66% stay. A naive classifier could reach 66% accuracy by predicting "stay" for everyone and quietly miss the exact people HR needed to reach. Second, the person acting on the model was not a data scientist. Whatever I shipped had to be defensible in plain terms to a manager deciding where to spend a retention budget.
Two models I could actually explain in a meeting.
That framing ruled out a lot of tempting choices. I skipped gradient boosting and neural nets and picked two classifiers I could defend line by line: logistic regression and a decision tree.
To fight the imbalance without inventing synthetic rows, I trained both with class-weighted loss so the model paid real attention to churners instead of coasting on the majority class. For feature selection I ran L1 (Lasso) regularization on the logistic model — letting the penalty drive weak coefficients to zero and leaving a small, honest feature set the tree could echo. Two simple models, same data, two ways of asking the same question.
End-to-end pipeline, then a dashboard HR could open.
The pipeline was reproducible from raw CSV to prediction: cleaning, encoding, class-weighted train/test split, cross-validated hyperparameter sweep, and a final held-out evaluation focused on minority-class recall, not overall accuracy. The L1 pass isolated education level and payment tier as the two features that stayed non-zero across folds. The decision tree, trained independently, agreed on the split order.
On top of the model I built an interactive Tableau dashboard: predicted churn probability plotted against tenure, filterable by department, with the highest-risk employees surfacing at the top. HR could open it, pick a team, and walk out with a ranked outreach list that afternoon.
0.79 recall on the class that actually mattered.
On the held-out set the class-weighted logistic model reached 0.79 recall on the churn class — meaning it caught roughly four out of every five people who eventually left. Precision-recall was the honest way to score it; raw accuracy would have flattered the model into looking better than it was.
The two-driver story — education level and payment tier — was concrete enough to act on. I proposed targeted retention initiatives tied to those specific drivers (tuition support for education-heavy roles, tier-specific compensation review) and modeled the effect against the historical churn curve to a projected ~8% reduction in annual attrition. Numbers a manager can defend up the chain.
Match the model to the room it lives in.
The lesson wasn't in the model — it was in the discipline of matching complexity to context. A boosted tree probably would have squeezed out another couple of points of AUC, but nobody in HR would have trusted it, and the model exists to be used, not admired.
Class imbalance handled by weighting instead of oversampling. Feature selection driven by L1 instead of intuition. And a Tableau layer that made "who should I call this week?" a two-click query. That's the version of ML I want to keep building — the kind non-technical stakeholders actually put into their calendar.
Bring this kind of thinking to your team.
I'm interviewing for full-time Data Science, Analytics, and Product Analytics roles starting August 2026. If you have a labeled dataset and a stakeholder who needs to act on it, this is the shape of work I do.