Foundations
Why it matters: These concepts define whether a model is learning real signal or just memorizing noise.
Case-based flashcards connecting machine learning concepts to real product, data quality, and QA problems.
MS in Data Science Candidate, Boston University — Expected May 2026
I use this page to connect interview preparation with applied data science, model validation, and real product-quality problems.
Why it matters: These concepts define whether a model is learning real signal or just memorizing noise.
Why it matters: Model choice only matters when evaluation is honest, comparable, and tied to risk.
Why it matters: Validation shows where a model fails, who is affected, and whether it is safe enough to use.
Why it matters: Production systems need monitoring, documentation, and rollback paths after the notebook ends.
Why it matters: Semantic systems can improve discovery, but similarity is not the same as verified truth.
Each topic pairs interview questions with a portfolio example and the QA failure mode I would test before trusting the system.
Regression could support translation-demand forecasting or expected time-to-English-publication, but only after the World Publishing Houses dataset has enough historical examples across countries, languages, genres, and publisher types.
A regression model should not be trusted just because it produces a number. I would check baseline comparison, residual patterns, outliers, data drift, and whether errors are larger for specific countries or categories.
World Publishing Houses could classify books into reader buckets such as “Read now in English,” “Coming soon,” or “Not yet in English.” Because the current dataset is still small for supervised ML and reader buckets may be imbalanced, accuracy alone would be misleading.
Before training a classifier, I would check class balance, minority-class count, label definitions, and whether the model simply learns the majority class.
Possible World Publishing Houses features include original language, country, publisher activity, award status, translator presence, publication lag, verification status, and translation path.
A feature can exist in the schema but still be useless for ML if it has no variation. For example, if almost every translation path is “Direct,” the model cannot learn pivot-translation behavior from that column.
A World Publishing Houses recommendation or rights-signal model would need monitoring because publishing activity changes over time: awards, rights deals, new translations, publisher acquisitions, and seasonal release patterns can all shift the data.
Production ML requires monitoring beyond uptime. I would track feature drift, prediction distribution, source freshness, error patterns, and confidence changes.
Embeddings could help World Publishing Houses find similar books, cluster publishers, normalize messy metadata, or match translation records from different sources.
Embedding similarity is not truth. I would test false matches, false misses, multilingual behavior, publisher-name ambiguity, and whether retrieval results are explainable to users.
Outcome: Compared Linear Regression, Random Forest, and Gradient Boosting models for residential property value prediction. Random Forest performed best among the tested models with RMSE of approximately $290,919, MAE of approximately $184,569, and R² of approximately 0.517. The project is framed as a model validation case study, showing how I evaluate performance, limitations, fairness risk, and production readiness.
The strongest insight was not that the model was production-ready, but that validation exposed clear limits: high prediction error, need for baseline comparison, possible location-proxy risk, and the importance of residual analysis before deployment.
The Random Forest model performed best among the tested models, but the result also shows why validation matters. An R² of approximately 0.517 means the model explains some meaningful signal, but it is not strong enough for high-stakes appraisal decisions without additional feature engineering, market-specific validation, fairness review, and monitoring.
| Model | RMSE | MAE | R² | Validation takeaway |
|---|---|---|---|---|
| Random Forest | ~$290,919 | ~$184,569 | ~0.517 | Best tested model, but still limited for production use. |
| Gradient Boosting | ~$294,663 | Not reported | ~0.504 | Similar performance, slightly weaker than Random Forest. |
| Linear Regression | ~$336,465 | Not reported | ~0.354 | Baseline interpretable model; weaker fit for non-linear housing patterns. |
A future improvement is to add a naive mean-prediction baseline so the model lift can be quantified against a simple non-ML benchmark.
Case-based cards connecting machine learning concepts to dataset readiness, model validation, and QA risk.
These flashcards are not generic study notes. They connect machine learning concepts to real product and QA problems: translation metadata, publisher entity resolution, model validation, fairness risk, and production-readiness checks.
These cards are organized in four levels: Level 1: Definition recall, Level 2: Tradeoffs, Level 3: When to use what, and Level 4: Failure cases and production risk.
Majority-class accuracy can hide weak model behavior.
A majority bucket can make a weak classifier look accurate.
The immediate risk is class imbalance and small sample size. A model can look accurate if most records fall into the same reader bucket, even when it learns little about the minority cases. Accuracy is the wrong metric by itself; precision, recall, and minority-class counts matter more.
This is a data quality and validation problem before it is a modeling problem. An ML QA review should check class balance before training and flag the dataset if minority classes are too small to support meaningful evaluation.
reader_bucket.value_counts()
Review majority bucket size
Review minority bucket counts
Compare accuracy with precision / recallReveal each layer: answer, QA angle, then the dataset reference.
Technologies and methods I use or study in my QA-to-DS transition.
Pandas, NumPy, scikit-learn, notebooks, data cleaning, model comparison, and evaluation.
Regression, classification, clustering, embeddings, decision trees, gradient boosting, cross-validation, and error analysis.
SQL, API testing, logs, automation, CI/CD awareness, cloud/data pipeline concepts, and production QA thinking.