QIC: Техническое собеседование

Check nulls, invalid dates, negative or implausible prices/quantities, duplicate rows, category spelling issues and distribution outliers.

Start with schema and null checks: required columns, date parsing, missing category, missing price or quantity. Then validate numeric ranges: price and quantity should usually be non-negative, quantities should be plausible, and extreme values should be inspected for unit or extra-zero mistakes.

For time and categorical fields, check unexpected dates, duplicate events, inconsistent category names and very rare categories. For a revenue task, also inspect the distribution of row-level price * quantity, because one bad row can dominate the answer.

The point in an interview is not to list every possible test, but to show that you understand the data contract and the business meaning of each column before trusting aggregate metrics.

Data drift is a shift in input or target-related distributions. Monitor feature, prediction and business metrics; react with investigation, retraining, threshold changes or fallback rules.

Data drift means the production data no longer follows the same distribution as the data used to train or validate the model. It can be feature drift, label drift, concept drift, seasonality, new user segments or a pipeline bug.

Detection should combine several layers. Track feature distributions, missing rates, categorical cardinalities, prediction-score distributions, calibration, latency and business metrics. If labels arrive later, compare delayed quality metrics against historical baselines. Statistical tests can help, but dashboarded trend changes and alert thresholds are often more actionable.

The response depends on cause and severity. You may retrain on fresh data, refresh calibration or thresholds, fix a broken data pipeline, add monitoring for a new segment, roll back a model or use a simpler fallback while collecting labels.

Overfitting shows up as improving train quality with worsening validation quality. Reduce it with more/better data, regularization, dropout, augmentation, early stopping, simpler models and ensembles.

The canonical symptom is a growing gap between train and validation metrics: train loss keeps improving while validation loss or business metric gets worse. You also look at cross-validation variance, segment-level metrics and whether performance collapses on newer or shifted data.

Mitigations are data-side and model-side. Data-side: collect more representative data, clean labels, add augmentation or synthetic data when valid, and use a better validation split. Model-side: L1/L2 regularization, dropout, early stopping, reducing model capacity, pruning features, ensembling and calibration.

For neural networks, dropout, weight decay, augmentation and early stopping are common. For tabular/classical models, constraints such as tree depth, minimum leaf size, regularized linear models and robust validation are often more important.

Clarify the business decision, build a baseline or pretrained-model prototype, estimate value, design labeling or weak supervision, and avoid committing to a heavy model before data proves it is useful.

First clarify what decision the model should improve, what metric matters and how much error the business can tolerate. Often the first deliverable should be a baseline, rules, analytics or a pretrained-model prototype rather than a full custom model.

If the domain has usable pretrained models, test them on a small real sample. If labels are missing, design a labeling loop: human annotation, product events as proxy labels, weak supervision, active learning or LLM/VLM-assisted pre-labeling with human review. At the same time, estimate the value of collecting the data and the time needed to know whether the idea works.

The important senior answer is to control investment. Sometimes the right answer is to not build ML yet, because a dashboard, heuristic or product change gives faster business value while data collection ramps up.

The path includes packaging the model, serving API, config, containerization, CI/CD rollout, monitoring, alerts, rollback and collaboration with platform or DevOps when needed.

A full-cycle ML engineer should be able to turn an offline model into a service or batch job that production systems can call. That includes serializing or converting the model, defining input/output schemas, writing the inference code, adding validation, packaging the service, and preparing deployment config.

Production readiness also includes monitoring and operations: latency, error rate, input validation, feature drift, prediction distribution, business metric hooks, logs, alerts and rollback plan. Deployment mechanics can be Kubernetes, CI/CD, canary, rolling release, staging/prod environments or a platform-specific one-command flow.

The best answer also distinguishes ownership from solo heroics. ML engineers can own the model-serving contract and quality, while relying on platform or DevOps for cluster-level incidents or infra primitives.