Scikit Learn Interview Questions — Practice Real Python ML Questions

Scikit-learn estimators follow a strict three-phase lifecycle. First, the constructor __init__ receives and stores hyperparameters (like C, max_depth) — it does no learning. Second, fit(X, y) learns parameters from data and stores them in attributes with trailing underscores (like coef_, classes_). Third, predict or transform applies those learned parameters to new data. Calling predict before fit raises a NotFittedError, and fit cannot be called before the object exists, so this order is universal across all scikit-learn estimators.

Scikit-learn uses random_state as a seed for its internal random number generators. When set to a fixed integer, the same sequence of pseudo-random numbers is produced every run, yielding identical results. When left at None, results may vary between runs.

This design exercise tests whether a candidate can select the right scikit-learn cross-validation tool for an imbalanced dataset. The keyed criteria reward naming a stratified splitter, explaining why stratification matters for an 8% minority class, and specifying concrete, justified parameters — all of which the sample answer demonstrates.

This design exercise tests whether a candidate can choose scikit-learn's TimeSeriesSplit for chronologically ordered regression data. The keyed criteria reward justifying the tool by contrasting it with named alternatives (c1), explaining the expanding-window mechanism with its strict index-ordering property (c2), and discussing concrete parameters (c3) — all demonstrated in the sample answer. The overlap in the original c2 trailing clause has been removed by replacing the comparative statement with a requirement to state the strict index-ordering property that distinguishes the mechanism itself.

This split is the foundation of scikit-learn's whole transformer API: .fit(X) learns whatever the transformer needs to learn from the data it's given — for StandardScaler, that's each feature's mean and standard deviation — and stores it as fitted attributes. .transform(X) then applies that already-learned transformation to data, which can be the same data or entirely different data (most importantly, held-out test data), using the parameters that were fitted, not recomputing new ones. .fit_transform(X) is a convenience method that does both in one call on the same data, but the two-step split is what makes it possible to fit once on training data and then correctly transform test data (or new production data) using training-set statistics rather than the test data's own. The other options invert or invent the relationship — fit doesn't transform anything on its own (c), the two methods do genuinely different things (b), and transform requires a prior fit to have parameters to apply, not the other way around (d).

False. random_state is a per-object parameter, not a global setting — train_test_split, cross-validation splitters like KFold, and any stochastic estimator each have their own independent randomness that needs its own random_state fixed. Seeding only the RandomForestClassifier leaves train_test_split free to produce a different train/test partition on every run (since it has no seed of its own), so even though the forest's internal randomness is now fixed, the actual data it's trained and evaluated on still changes run to run. Genuine reproducibility means explicitly setting random_state on every stochastic step in the script, not just the model at the end of it.

The convenience of one fit/predict call is real, but the correctness guarantee under cross-validation — automatic per-fold refitting — is the reason Pipeline is considered standard practice rather than optional tidiness.

Options A, B, and C all compute statistics (mean/std, median, category mappings) using the full dataset before the split, so information from test-fold rows influences training-time preprocessing — the classic leakage pattern. Option D simply removes targetless rows that cannot be used for supervised learning at all; it does not transfer test-fold signal into training, so it does not cause leakage.

set_params modifies the estimator in place and returns self. After clf.set_params(C=5.0), the C parameter is updated to 5.0. Calling get_params() returns a dictionary of all parameters, and get_params()['C'] retrieves the updated value, which is 5.0.

scikit-learn's naming convention deliberately separates two kinds of state on an estimator: constructor parameters (LogisticRegression(C=1.0)) are hyperparameters the user chooses before fitting, while trailing-underscore attributes (.coef_, .intercept_, .feature_importances_, .classes_) are populated only once .fit() has run, holding whatever the estimator actually learned from the training data. Trying to access .coef_ before calling .fit() raises a NotFittedError precisely because it documents that dependency in the API itself — the trailing underscore is a visual signal that the attribute doesn't exist yet at construction time. It's neither a privacy convention (b — these are meant to be read directly, that's the whole point of exposing them), nor a deprecation marker (c — it's the opposite, a stable, deliberate naming pattern used throughout the library), nor classifier-specific (d — LinearRegression.coef_ is a standard regressor example of the exact same convention).

A linear model's coefficient multiplies a feature's numeric value directly, so if OrdinalEncoder maps 'red'→0, 'blue'→1, 'green'→2 with no real order behind those categories, the model is implicitly fit as if 'green' is numerically 'more' of whatever the coefficient represents than 'blue' is more than 'red' — a relationship the data never actually claimed (a). OneHotEncoder sidesteps this entirely by giving each category its own binary column, so no numeric ordering is ever implied between categories (b). The severity genuinely differs by model family, too: tree-based models split by asking 'is this feature ≤ some threshold,' so an arbitrary numeric code just needs a boundary between groups to exist somewhere, not any meaningful magnitude relationship, which is why ordinal encoding is a much smaller practical concern for trees/forests/boosted trees than for linear or distance-based models (e). OrdinalEncoder works perfectly well as a Pipeline step — it's a standard scikit-learn transformer with no such restriction (c is false) — and one-hot encoding a feature with N categories produces N (or N-1, with drop='first') columns versus ordinal's single column, meaning one-hot always produces more, not fewer, columns for the same feature (d is backwards).

True. .fit_transform() on the training set both learns the transformation's parameters from training data and applies them, which is correct since the training set is exactly the data those parameters should be learned from. Calling .transform() — not .fit_transform() — on the test set applies that same already-learned transformation without recomputing anything from the test data itself, which is exactly what keeps test-set statistics out of the preprocessing the model was effectively trained under. Calling .fit_transform() on the test set instead would compute a brand-new set of parameters from test data alone, meaning the model would be evaluated against features scaled differently than the ones it actually learned from — a leakage bug that also silently invalidates the evaluation.

The scaler object at line 6 is the same object that was already fitted on X_train at line 2 — it's holding the training set's mean and standard deviation internally. Calling .fit_transform(X_new) on it throws that fitted state away and recomputes a fresh mean/standard deviation from whatever's in the new production batch, then scales X_new against those new-batch statistics instead of the training-set statistics the model actually learned its coefficients against. The model's weights encode relationships in the training-scaled feature space, so scoring features scaled a different way (especially if a production batch's distribution differs even slightly from training, e.g. it's smaller, or skewed toward one segment of users) produces predictions that are silently wrong, with no error raised anywhere. The fix is X_new_scaled = scaler.transform(X_new) — reusing the already-fitted scaler's stored parameters, never re-fitting at inference time. fit_transform on the training set (b) is exactly correct, since that's the data the scaler should legitimately learn from; the constructor-chaining syntax on line 3 (c) is completely valid, ordinary scikit-learn usage; and a fitted scaler is very much stateful — it holds the learned mean/std as fitted attributes, and calling fit_transform again explicitly discards and replaces that state rather than being a no-op (d is false).

The 'just convenience' framing is the trap this question is checking for. Pipeline's real value is correctness: it guarantees that inside cross-validation or GridSearchCV, every preprocessing step gets refit on only the current fold's training data and applied to validation data purely via .transform(), which is exactly what prevents the fold's own statistics from leaking into its own evaluation. A strong answer names both the convenience (one fit/predict call for a multi-step sequence) and the correctness guarantee (per-fold refitting inside CV/grid search), since the second is the part that actually matters for whether a reported score can be trusted.

Each step exists to keep the test set genuinely unseen until the very end. Splitting first, before any preprocessing touches the data, is what makes 'held-out' actually mean something — if preprocessing ran on the full dataset before the split, test-set statistics would already have leaked into the transformers by the time evaluation happens. Fitting a Pipeline (rather than separate fit calls) on the training set alone ensures every preprocessing step's learned parameters come only from training data. Hyperparameter tuning via cross-validation happens next and must also stay confined to the training set, since the whole point of a held-out test set is that no tuning decision was ever influenced by it. Refitting the selected pipeline on the full training set (rather than shipping whichever fold happened to score best during tuning) uses all the training data available once the hyperparameters are settled. And evaluating against the test set comes strictly last, and exactly once — evaluating repeatedly and adjusting anything in response would turn the 'held-out' test set into something the model was effectively tuned against too, defeating its purpose as an unbiased final check.

random_state pins the RNG seed for a single estimator's internal randomness, but reproducibility also depends on identical library versions, platform-level floating-point behavior, and thread ordering. It does not provide cross-version or cross-platform guarantees.

The leakage here is subtle because the code runs without error either way — it's the score that's silently wrong. If you call scaler.fit_transform(X) on the full dataset before cross-validation splits it into folds, the mean and standard deviation used to scale every fold's data (including what will become that fold's validation portion) were computed using information from all the data, validation portion included. That means each fold's 'held-out' validation data isn't fully held out — its own statistics helped shape the scaling applied to it — so the reported cross-validation score is optimistically biased relative to what the model would actually do on truly unseen data. Wrapping the scaler and model together in a Pipeline and passing the pipeline to cross_val_score fixes this: for each fold, the pipeline's scaler is fit fresh on only that fold's training portion, and the validation portion only ever sees .transform() with those training-only statistics — genuinely never touched during fitting. This isn't a style preference (c) or a compatibility requirement between unrelated modules (d) — a bare scaler works fine as a cross_val_score step in isolation (b is false) — it's a correctness issue with a real, measurable effect on the score.

best_score_ is optimistically biased by construction — it's the score of whichever combination happened to perform best across your specific cross-validation folds, so some of that 'best' is genuine signal and some is the combination getting lucky on those particular folds (a); that's exactly why a fully held-out test set, untouched by anything inside the GridSearchCV call, is still needed afterward for a less biased final estimate (d). For imbalanced classification, plain KFold splits rows without regard to class balance, so a fold can end up by chance with almost no minority-class examples, making any metric computed on that fold noisy or meaningless — StratifiedKFold (the default GridSearchCV actually uses for classifiers) preserves each fold's class ratio to avoid exactly this (b). The scoring parameter genuinely drives which combination is selected as 'best' — passing scoring='f1' versus the default optimizes for a materially different objective, so option (c) describes the opposite of how it actually works. And RandomizedSearchCV is frequently more compute-efficient than an exhaustive grid search, especially over large or high-dimensional hyperparameter spaces, since it samples a fixed budget of combinations rather than evaluating every single one — grid search is not 'always' more efficient (e is false).

The scaler is fit on X — the entire dataset — before train_test_split ever separates it into train and test portions, which means the mean and standard deviation used to scale every row (test rows included) were computed with the test rows' own values folded in. That's leakage: information about the test set (its actual values, via their contribution to the fitted mean/std) has influenced the preprocessing the model is trained under, so cross-validation or a naive train/test split evaluated this way reports an optimistic score relative to genuinely new data the scaler's statistics never touched. The correct order is to split first, then scaler.fit_transform(X_train) and scaler.transform(X_test) separately — or equivalently, wrap the scaler and model in a Pipeline and pass that to train_test_split/cross_val_score, which enforces this ordering automatically. random_state=42 (b) is exactly the right practice for reproducibility, not a bug; a missing random_state on LogisticRegression() (c) affects run-to-run reproducibility of that estimator's own internals, not leakage; and 'the scaler needs to see the full range of the data' (d) is the precise misconception this question tests — a scaler only ever needs to see the data it's legitimately allowed to learn from, which is the training set alone.

The first set_params(scaler=MinMaxScaler(feature_range=(-2, 2))) replaces the entire scaler pipeline step with a fresh MinMaxScaler instance whose feature_range is (-2, 2). The second set_params call uses nested parameter notation: scaler__feature_range=(0, 1) updates the new MinMaxScaler's feature_range to (0, 1), and clf__C=7.0 updates the LogisticRegression's C to 7.0. Consequently: type(...).__name__ prints MinMaxScaler, the scaler's feature_range prints (0, 1), and the classifier's C prints 7.0.

The scikit-learn API convention mandates that every attribute learned during fit must end with a trailing underscore (_). This separates constructor-set hyperparameters (e.g., n_components, alpha) from estimated quantities (e.g., components_, coef_). The convention is relied upon by BaseEstimator.get_params (which inspects only __init__ parameters), clone (which creates a fresh estimator with the same hyperparameters but no learned state), and Pipeline internals.

The scikit-learn development guide explicitly states that __init__ should only store parameters and never validate or transform them; all validation belongs in fit. If validation were done in __init__, then clone—which calls __init__ with the parameters returned by get_params—could fail or produce side effects, breaking GridSearchCV, cross_val_score, and Pipeline. By deferring validation to fit, the framework guarantees that cloning and parameter-setting are side-effect-free operations.

This is a staff-level question because the trap is genuinely dangerous in practice: 98% sounds impressive in isolation, and only becomes obviously bad once compared to what a model that learned nothing would already score by exploiting the class imbalance. A strong answer explicitly computes or reasons about that majority-class baseline, names the actual metrics that separate minority-class performance from the accuracy number (precision, recall, F1, confusion matrix), and connects the choice back to the real-world cost asymmetry between a missed fraud case and a false alarm — which is ultimately what should drive both the metric choice and the decision threshold, not accuracy or even a single fixed probability cutoff.

SelectKBest with f_classif ranks features by their univariate correlation with the target y. When fit on the full dataset, every sample's label — including those that will later land in a validation fold — influences which 10 features survive. The classifier is then evaluated on folds whose labels already shaped its input, inflating cross-validated scores. The fix is to place SelectKBest inside a sklearn.pipeline.Pipeline so that feature selection is fit only on each training fold during cross-validation. Note that cross_val_score itself has no way to detect or undo leakage that happened before it was called; it simply receives the already-reduced matrix.

Scikit-learn's BaseEstimator.get_params() introspects the __init__ signature via inspect.signature to discover parameter names, then retrieves each value with getattr(self, name). The constructor parameter is n_features, but line 6 stores it as self.k. Calling get_params() raises AttributeError because getattr(self, 'n_features') fails. This breaks clone(), set_params(), GridSearchCV, and any tooling that relies on standard estimator introspection. The fix is self.n_features = n_features.