Data Preprocessing and Handling for AI Questions

Covers the end to end preparation of raw data for analysis and modeling in machine learning and artificial intelligence. Topics include data collection and ingestion, data quality assessment, detecting and handling missing values with deletion or various imputation strategies, identifying and treating outliers, removing duplicates, and standardizing formats such as dates and categorical labels. Includes data type conversions, categorical variable encoding, feature scaling and normalization, standardization to zero mean and unit variance, and guidance on when each is appropriate given model choice. Covers feature engineering and selection, addressing class imbalance with sampling and weighting methods, and domain specific preprocessing such as data augmentation for computer vision and text preprocessing for natural language processing. Emphasizes correct order of operations, reproducible pipelines, splitting data into training validation and test sets, cross validation practices, and documenting preprocessing decisions and their impact on model performance. Also explains which models are sensitive to feature scale, common pitfalls, and evaluation strategies to ensure preprocessing does not leak information.

HardTechnical

65 practiced

Compare methods for robust outlier detection at scale: Isolation Forest, Robust Covariance (Mahalanobis), LOF, and deep autoencoders. For each method, discuss assumptions, complexity, and when to prefer it for streaming vs batch data; include deployment considerations and false-positive controls.

Sample Answer

Situation: You're selecting anomaly detection methods at scale. Below is a concise, role‑appropriate comparison of Isolation Forest, Robust Covariance (Mahalanobis), LOF, and deep autoencoders covering assumptions, complexity, streaming vs batch use, deployment concerns, and controlling false positives.

Isolation Forest- Assumptions: anomalies are easier to isolate by random partitioning; works well with tabular numeric features, less sensitive to scaling.- Complexity: O(n log n) average training, O(n) memory for trees; prediction O(trees * depth).- Streaming vs batch: Batch by default; can use incremental/online variants (e.g., streaming isolation forest) but with careful reservoir sampling.- Deployment: Lightweight, interpretable (path length), easy to parallelize; model drift requires retraining periodically.- False-positive controls: Calibrate score with validation set, use contamination parameter, and set thresholds based on precision-recall trade-offs.

Robust Covariance (Mahalanobis)- Assumptions: data ~ multivariate Gaussian (or elliptic); covariance robustly estimated (e.g., Minimum Covariance Determinant).- Complexity: O(d^2 n) to estimate covariance; prediction O(d^2).- Streaming vs batch: Primarily batch; streaming requires incremental robust covariance estimators (complex).- Deployment: Simple scoring and explainable; sensitive to high dimensionality — use dimensionality reduction (PCA).- False-positive controls: Compute p-values from chi-square distribution of Mahalanobis distance; set alpha for desired FPR.

LOF (Local Outlier Factor)- Assumptions: local density deviations indicate anomalies; needs meaningful distance metric.- Complexity: O(n log n) with efficient neighbor indices, but high memory for neighbor graphs.- Streaming vs batch: Batch preferred; online LOF variants exist but are complex.- Deployment: Good for local/contextual anomalies; choose k carefully and use approximate neighbors for scale.- False-positive controls: Use validation to map LOF scores to probabilities; ensemble over k to stabilize.

Deep Autoencoders- Assumptions: normal data reconstructs well; anomalies reconstruct poorly; requires sufficient training data and representativeness.- Complexity: Training O(epochs * n * model_cost); inference cheap per instance but depends on model size.- Streaming vs batch: Batch training, but can do continual learning with careful regularization; susceptible to catastrophic forgetting.- Deployment: Requires infra for GPUs (if large), monitoring for drift, and explainability aids (reconstruction residuals per feature).- False-positive controls: Use reconstruction error distribution on holdout to set thresholds, use extreme value theory (EVT) for tail modeling, and calibrate with downstream feedback loop.

When to prefer which- Use Isolation Forest for general-purpose, scalable tabular anomaly detection.- Use Robust Covariance when data is low-dimensional and roughly elliptical.- Use LOF for contextual/local anomalies where density differences matter.- Use autoencoders for complex, high-dimensional data (images, time series) when you can invest in training and monitoring.

Operational best practices- Always reserve labeled/clean validation data to calibrate thresholds and measure precision/recall.- Combine methods (ensemble) to reduce false positives.- Monitor concept drift, re-calibrate thresholds automatically, and implement human-in-the-loop feedback to update models and reduce alert fatigue.

EasyTechnical

87 practiced

For a computer vision classification task, enumerate common image augmentation techniques (flips, rotations, color jitter, mixup, cutout) and explain when each helps generalization versus when it can introduce label noise. Include brief mention of preserving class semantics.

Sample Answer

Common image augmentations and when they help vs harm (with class-semantics note):

1. Horizontal/vertical flips- Helps: doubles data, useful when object orientation is irrelevant (e.g., animals, many objects).- Hurts: introduces label noise when orientation is class-defining (e.g., text, digits like 6 vs 9, traffic signs).- Semantics: ensure flipped image still maps to same label.

2. Rotations / small affine transforms (±10–30°), scaling, translation- Helps: adds robustness to viewpoint, camera jitter; small rotations usually safe.- Hurts: large rotations can break semantics (upside-down faces, rotated logos) or crop important context.- Semantics: constrain magnitude to preserve class meaning.

3. Color jitter (brightness, contrast, saturation, hue)- Helps: robustness to lighting and camera variation, especially for texture-agnostic classes.- Hurts: extreme color shifts can change class cues if color is critical (e.g., fruits, medical stains).- Semantics: limit ranges or apply per-channel with care.

4. MixUp / CutMix (pixel/patch-level mixing of two images and labels)- Helps: regularizes decision boundaries, improves calibration, helpful with limited data.- Hurts: if mixing across semantically incompatible classes (e.g., mixing object and background-only images) labels become ambiguous; model must learn soft labels.- Semantics: use with soft-label training and ensure blended samples are meaningful.

5. Cutout / Random Erasing- Helps: forces reliance on multiple cues, robust to occlusion and missing features.- Hurts: if erased region removes the only class-defining feature (tiny object), label-noise risk increases.- Semantics: control size/placement so object isn't fully removed.

6. Noise, blur, JPEG compression- Helps: robustness to sensor noise and compression artifacts.- Hurts: heavy degradation may remove discriminative features; avoid for fine-grained tasks.

Guidelines:- Always validate augmentations with a holdout set; prefer weaker transforms first.- For class-sensitive tasks (digits, medical, fine-grained), restrict augmentations that change geometry/color semantics.- Consider class-conditional augmentation policies or automated search (AutoAugment) to balance benefit vs label noise.

MediumTechnical

70 practiced

You have a multi-class imbalance problem (10 classes, highly skewed). Propose sampling or weighting strategies, explain metric choices for evaluation, and how to ensure that the model does not collapse to predicting only majority classes in production.

Sample Answer

Situation/Approach:With 10 highly-skewed classes I’d combine sensible sampling, loss weighting, and robust evaluation plus production safeguards to avoid collapse to majority classes.

Sampling & weighting strategies:- Loss weighting: compute class_weight = 1 / sqrt(freq) or inverse freq, plug into cross-entropy (reduces extreme amplification). Alternatively use focal loss (gamma=1-2) to focus on hard/rare examples.- Mini-batch sampling: use stratified or weighted batch sampler so every batch contains examples from rare classes (prevents forgetting during SGD).- Data augmentation / synthetic sampling: for tabular use SMOTE variants (multiclass-aware); for images use targeted augmentations (mixup, RandAugment) on rare classes.- Hybrid undersample-majority + oversample-minority to limit overfitting and keep dataset size manageable.Example (PyTorch):

python

# compute weights per class
class_weights = torch.tensor(1.0/np.sqrt(class_counts))
loss = nn.CrossEntropyLoss(weight=class_weights)

Metric choices:- Primary: macro-averaged F1 (treats all classes equally) and per-class recall for rare classes.- Secondary: macro precision, balanced accuracy, and per-class AUPRC (useful when classes are extremely rare).- Confusion matrix and class-wise calibration plots to see specific confusions.

Prevent model collapse in production:- Validation checks: during training monitor per-class recall/F1; early stop if minority recall degrades.- Thresholding & decision rules: optimize per-class thresholds on validation set (not only argmax).- Calibration: temperature scaling or isotonic regression so confidence matches true likelihoods.- Ensemble or two-stage model: first detect rare-class candidates (binary detectors), then classify — helps boost recall for small classes.- Continuous monitoring: track per-class metrics in production, input-distribution drift, prediction-rate changes; set alerts when minority-class rate drops or per-class recall decreases > X%.- Feedback loop & human-in-the-loop: sample low-confidence or minority predictions for labeling; periodically retrain with new labels.- Safety nets: fallback to “request human review” when model confidence is low or when downstream cost of missing a rare class is high.

Trade-offs:- Aggressive oversampling risks overfitting; aggressive weighting can increase false positives on rare classes. Tune via validation focusing on business cost (precision vs recall) and use stratified cross-validation.

This combined strategy ensures the model learns rare classes, is evaluated fairly, and includes production monitoring and remediation to prevent collapse.

HardTechnical

65 practiced

Data leakage can silently inflate model metrics. Describe common sources of leakage during preprocessing (temporal leakage, aggregate features computed with future labels, scaling using full dataset), propose detection methods, and outline mitigation strategies including tests to run in CI.

Sample Answer

Situation: Data leakage during preprocessing can silently boost metrics and produce models that fail in production. Below I describe common sources, detection techniques, and practical mitigation + CI tests an AI Engineer should implement.

Common sources (with examples)- Temporal leakage: using features that include information from after the prediction time (e.g., churn label or future transactions in training features).- Aggregates computed with future labels: computing per-user target-mean encoding or rolling averages that include the target period.- Scaling/normalization on full dataset: fitting StandardScaler/MinMax on train+test, leaking distributional info.- Join-time leakage: joining external tables with keys that implicitly encode outcomes (order of joins matters).- Imputation leakage: imputing missing values using statistics computed across all splits (or using target to impute).

Detection methods- Train/test metric gap and time-split validation: large drop in time-ordered holdout indicates temporal leakage.- Feature importance/SHAP audit: features with unusually high importance correlated with label post-event.- Permutation/zero-out tests: randomly permute candidate features — if performance barely drops, feature may be leaking label-derived signal.- Leak hunting via causal/time analysis: verify each feature can be known at prediction time.

Mitigation strategies- Enforce strict feature engineering pipeline that respects event timestamps: derive each feature using only historical data up to prediction_time.- Use proper splitting: time-based splits for temporal problems; group/k-fold for grouped data.- Fit transformers only on training folds (scikit-learn Pipelines with fit on train inside CV).- For aggregate features, compute using out-of-fold or expanding-window approach; use target-encoding with K-fold target-blending.- Log and version data joins; validate join keys to avoid backfilled indicators.- Prefer simple, auditable transformations and document feature availability times.

CI tests to run- Unit tests that assert no feature uses timestamp > prediction_time (e.g., feature metadata: available_at timestamp).- Reproducible leakage check: run a permutation test in CI — permute labels in train; model AUC should fall to random baseline.- Out-of-fold vs. full-fit check: ensure that metrics on strict time holdout are within expected tolerance of cross-val.- Feature importance sanity: flag features with extremely high importance that were created from label-derived sources.- Schema/transformer checks: ensure scalers/encoders are fitted only on training data by instrumenting pipeline calls.- Data drift/leak alerts: monitor production predictions for sudden performance uplift that might indicate new leakage.

This combination of process (time-aware pipelines, out-of-fold aggregates), automated tests in CI, and periodic audits (SHAP and permutation) prevents and detects preprocessing leakage early.

MediumSystem Design

62 practiced

Propose a data versioning scheme and tooling (e.g., DVC, Delta Lake, MLflow) to make preprocessing reproducible across experiments. Explain how you would version raw data, transformed datasets, and transformation code, and how you'd enable rollbacks and lineage queries.

Sample Answer

Requirements and constraints:- Reproducible preprocessing across experiments, immutable raw data, queryable lineage, support rollbacks, integrate with CI/CD and model tracking.

High-level design:- Raw data: immutable object storage (S3/GCS) with content-addressed storage (SHA256) and a manifest (catalog) in a Delta Lake table for metadata (path, hash, schema, ingested_at, source_id).- Transformed datasets: stored as Delta Lake tables/paths (partitioned) with versioned commits; each commit records the transformation run_id and input hashes.- Transformation code & configs: stored in Git; experiments tracked in MLflow (or MLflow Projects). Use DVC for dataset pointers and to link data versions to Git commits if needed.

Core components & responsibilities:1. Object storage + Delta Lake: durable storage for raw and transformed parquet/Delta; Delta provides ACID, time travel and versioned commits for rollbacks.2. DVC: optional for local reproducible pipelines, pointers to large files/Delta table snapshots; records data hashes and generates a dvc.lock that ties data artifacts to code commits.3. MLflow: track runs, parameters, artifacts, and store run_id. Log mapping: run_id → git_commit_sha → transformation_config → input_hashes → delta_version_id.4. Metadata store / Lineage catalog: use a lightweight service (e.g., Amundsen/Atlas or custom Postgres) that indexes relationships: raw_hash → transform_run_id → delta_version → downstream_model_run_ids.

Dataflow / reproducibility:- Ingest: write raw file to S3, compute SHA256, write entry to Delta raw_catalog table with path+hash+schema.- Preprocess: pipeline reads raw_catalog entries by hash or date, runs transformation code from a specific git commit (checkout by SHA), MLflow starts run and logs params. Write transformed data to Delta table; Delta commit generates version_id (timestamp + version). Pipeline writes a lineage record: {run_id, git_sha, input_hashes, delta_table, delta_version, processing_env (docker image), conda/requirements}.- Rollback: use Delta time travel to restore a previous version_id or use Delta's RESTORE. MLflow run_id and git_sha allow re-running pipeline for a deterministic rebuild. DVC can fetch exact input artifacts by dvc.lock for local runs.

Lineage & queries:- Populate lineage catalog with entries linking inputs → run_id → delta_version → model_run. Provide REST API or SQL views to answer: - "Which raw hashes produced delta_version X?" (query catalog) - "Which model used delta_version Y?" (track model artifacts via MLflow tags referencing delta_version) - "Show full lineage graph" (visualize via Amundsen/Atlas)

Operational practices:- Enforce: every pipeline run must log MLflow run, Git SHA, Docker image digest, and input hashes.- CI: On PR, run lightweight DVC/Delta checks; on merge, run full pipeline to produce artifacts and record lineage.- Access control & retention: immutable raw files; lifecycle policies for intermediate artifacts; Delta vacuum controlled.- Testing: unit tests for transforms; snapshot tests comparing hashes; integration tests that re-run old git_sha+run to ensure reproducibility.

Trade-offs:- Delta Lake gives strong versioning and time travel at scale but requires managed compute (Spark/Databricks) and storage. DVC is simpler for smaller teams/local workflows. Combining MLflow+Delta provides best of model tracking and scalable data versioning.

Example query patterns:- SQL on lineage store: SELECT * FROM lineage WHERE delta_version = 'v123';- Delta time travel: SELECT * FROM table VERSION AS OF 12;- MLflow: mlflow.get_run(run_id).data.tags['delta_version'] to map run → data.

This scheme ensures every transformed dataset is tied to immutable inputs, a specific code commit and environment, enabling deterministic re-runs, rollbacks via Delta time-travel or rebuilds, and answerable lineage queries across experiments.

Unlock Full Question Bank

Get access to hundreds of Data Preprocessing and Handling for AI interview questions and detailed answers.

Join thousands of developers preparing for their dream job.