AI Engineer Top 100 Interview Questions

An AI engineer turns a useful model capability into a dependable product. The role combines data work, evaluation, software engineering, and operational ownership.

• Problem definition: translate a user need into a measurable outcome, identify unacceptable errors, and check whether available data can support the intended decision.
• System construction: connect data preparation, model inference, application logic, and user interfaces while keeping component contracts explicit and testable.
• Evaluation: compare against a credible baseline using representative examples, important user groups, and realistic latency and cost constraints.
• Operations: monitor behavior after release, investigate failures, maintain access controls, and define clear procedures for updates, escalation, and rollback.

I would choose the simplest approach that satisfies the required outcome. A learned model is justified when data-driven generalization adds measurable value over explicit rules.

1. Define the decision, its error costs, and the response-time requirement before selecting an implementation. Identify who will use the output.
2. Build a rules-based or manual baseline and collect representative cases, including exceptions that are expensive or difficult to handle.
3. Check whether sufficient representative data and useful labels exist. Compare candidate approaches on a held-out set using the same criteria.
4. Include maintenance, monitoring, review workload, and failure recovery in the decision. Keep the simpler approach if the measured improvement is insufficient.

flowchart TD
  A["Define outcome"]
  B["Evaluate baseline"]
  C{"Baseline sufficient?"}
  D["Use baseline"]
  E["Evaluate learned model"]
  F{"Meaningful improvement?"}
  G["Deploy with monitoring"]
  A --> B
  B --> C
  C -->|yes| D
  C -->|no| E
  E --> F
  F -->|yes| G
  F -->|no| D

Trade-offs:

• A model can handle varied inputs, but introduces ongoing data and evaluation requirements that a stable rule may avoid.
• Automation savings matter only when the remaining review workload and the cost of incorrect decisions are included.

The main difference is the source of the learning signal. Choose a learning setup based on available feedback and the behavior the system must learn.

When to use which:

• Use supervised learning when reliable input–target examples exist and the task can be evaluated using predictions on unseen examples.
• Use unsupervised or self-supervised learning when manual labels are scarce, while still defining how the resulting representation will be evaluated.
• Use reinforcement learning when actions influence later outcomes and rewards meaningfully represent success; account for exploration costs and delayed feedback.

The same neural architecture can support different learning setups, so architecture alone does not identify the learning paradigm.

Classification predicts discrete outcomes, while regression predicts numerical quantities. The correct choice depends on the meaning of the target and the decision made from it.

When to use which:

• Use classification when the task is choosing a category or detecting an event, even if those categories are stored as numbers.
• Use regression when differences between target values have quantitative meaning and the size of an error affects the business outcome.
• Use a probability or predictive distribution when downstream decisions require uncertainty, instead of reducing every output immediately to a single label or value.

Define the target before selecting the algorithm, because changing its meaning also changes labeling, evaluation, and appropriate error costs.

Underfitting means the model misses useful structure. Overfitting means it captures training-specific patterns that do not generalize sufficiently to unseen examples.

When to use which:

• Investigate underfitting when both errors remain high, checking label quality, missing features, optimization problems, and capacity before simply training longer.
• Investigate overfitting when the training–validation gap grows, using representative data, regularization, simpler models, or an earlier stopping point.
• Use learning curves and error slices to distinguish these patterns from distribution shift or an evaluation split that does not match deployment.

A performance gap is evidence to investigate, rather than proof of one cause; leakage can also make measurements misleading.

Parameters are learned from training data. Hyperparameters configure the model or training procedure and are usually selected through validation rather than direct fitting.

When to use which:

• Inspect parameters when checking what a fitted model learned, whether gradients reached expected layers, or whether a saved artifact is complete.
• Tune hyperparameters when exploring different training or complexity choices, using a fixed evaluation procedure and a clear resource budget.
• Record both categories because an identical architecture with different learned weights or training settings can produce meaningfully different behavior.

Keep final test examples out of configuration selection, since repeated decisions based on those results make the reported estimate optimistic.

A feature must be available when the prediction is made, and the target must represent the outcome the system should predict. Both need precise operational definitions.

• Availability: distinguish an event occurring from the information becoming accessible to the application. Historical training records must respect that timing.
• Meaning: document units, aggregation windows, missing values, and how labels are assigned so that training and serving use consistent interpretations.
• Relevance: prefer signals that can generalize across the intended population rather than identifiers that mainly allow the model to memorize examples.
• Quality: inspect noisy labels, selection effects, and changed definitions. A sophisticated model cannot reliably compensate for a target that measures the wrong outcome.

A baseline establishes the value that a more complex system must exceed. It also reveals whether the dataset, metric, and evaluation procedure behave sensibly.

• Comparison: choose a simple prediction rule, existing process, or lightweight model that reflects what users would otherwise receive.
• Sanity checking: unexpected baseline performance can expose label leakage, an easy shortcut, class imbalance, or an incorrectly calculated metric.
• Operational value: compare latency, cost, review workload, and maintenance alongside quality so that complexity earns its place in the product.
• Failure analysis: study where the baseline fails and whether proposed improvements address those specific errors rather than only improving an aggregate score.

Keep the baseline reproducible and evaluate it on the same held-out examples used for candidate systems.

The partitions separate learning from model selection and final assessment. Their purpose is to estimate how the chosen system will perform on genuinely unseen cases.

When to use which:

• Use training records to fit every learned transformation, including imputation, scaling, and feature extraction, rather than estimating those transformations from the full dataset.
• Use validation records for iterative choices, while tracking how repeated experiments can gradually adapt the system to that particular sample.
• Use the test set after choices are fixed, ensuring that entities, near-duplicates, and time relationships do not compromise its independence.

There is no universal split percentage; every partition needs enough representative examples for its intended role.

Data leakage occurs when development uses information that would not legitimately be available for an unseen prediction. It makes evaluation look better than real deployment.

• Future information: a feature may include outcomes, later transactions, or corrections that were recorded after the prediction should have happened.
• Shared entities: duplicate documents or related records can appear in both training and evaluation, allowing memorization instead of genuine generalization.
• Preprocessing leakage: fitting transformations or feature selection on all records lets held-out observations influence the model-development process.
• Evaluation leakage: repeatedly changing the system after inspecting test failures turns the test set into development data and weakens the final estimate.

Prevent leakage through explicit availability rules, appropriate partitioning, and transformations fitted within each training partition.

Each strategy protects a different property of the evaluation. Choose the split that most closely reproduces the kind of unseen data the deployed system will encounter.

When to use which:

• Use stratification when independent classification examples need adequate representation of each class, especially when one class is relatively rare.
• Use grouping when records share an underlying entity and sharing that entity across partitions would make generalization appear easier than it is.
• Use chronological evaluation when predicting future events, including suitable gaps if labels or overlapping feature windows create dependencies across the boundary.

These requirements can coexist, so a realistic evaluation may need both entity separation and time ordering.

I would investigate their meaning before replacing or removing them. Missingness and extreme values can represent genuine behavior, measurement problems, or inconsistent data definitions.

1. Validate units, types, permitted ranges, and collection rules. Measure how missing or extreme values vary across sources and important groups.
2. Distinguish legitimate observations from errors using domain evidence. Preserve a record of transformations and the original source where appropriate.
3. Fit imputation and any clipping or scaling rules using training data only. Consider missingness indicators when absence itself conveys useful information.
4. Apply the same transformations during evaluation and serving. Compare performance on affected records to ensure cleaning did not remove an important signal.

flowchart TD
  A["Validate records"]
  B{"Confirmed data error?"}
  C["Correct or exclude"]
  D["Preserve valid value"]
  E["Fit training transformations"]
  F["Evaluate affected groups"]
  A --> B
  B -->|yes| C
  B -->|no| D
  C --> E
  D --> E
  E --> F

Trade-offs:

• Removing unusual records can improve numerical stability while reducing coverage of exactly the rare cases the application needs to handle.
• Simple imputation is easy to maintain, but can hide relationships if missingness depends strongly on the outcome.

These transformations control different aspects of numerical scale. Select one based on the geometry or optimization requirements of the model, not a universal preprocessing rule.

When to use which:

• Use standardization when feature units differ and relative variation should influence a distance calculation or a coefficient penalty more evenly.
• Use min–max scaling when the chosen interval is meaningful, while planning for future values that exceed the observed training range.
• Use unit-length normalization when vector direction matters more than magnitude, and explicitly handle vectors whose length is zero.

Fit learned statistics on training data and consider robust alternatives when extreme values dominate the scale estimates.

Categorical encoding converts categories into representations a model can use. The representation should preserve useful meaning without creating artificial order or leaking label information.

When to use which:

• Use one-hot encoding for manageable unordered categories, with explicit behavior for categories absent during training and for missing values.
• Use ordinal encoding when the ordering is meaningful or the selected model handles categorical codes without treating them as ordinary distances.
• Use target encoding cautiously for high-cardinality features, constructing training encodings without exposing each example to its own label information.

Evaluate the encoding inside the full validation pipeline, because the most compact representation is not necessarily the most reliable.

I would start with error costs and deployment prevalence rather than overall accuracy. The model must find useful positives without creating an unmanageable number of false alerts.

1. Check label quality and build a baseline that predicts the majority class. Quantify how little its apparently strong accuracy actually accomplishes.
2. Use representative validation data and measure precision, recall, and review workload. Choose operating constraints before optimizing a summary score.
3. Compare class weighting, additional minority examples, and training-only resampling. Keep evaluation prevalence realistic and inspect probability calibration afterward.
4. Tune the decision threshold on validation data, inspect important subgroups, and deploy with monitoring for changed prevalence and review capacity.

flowchart TD
  A["Define error costs"]
  B["Evaluate rare positives"]
  C{"Recall sufficient?"}
  D["Improve data or fitting"]
  E{"Review volume acceptable?"}
  F["Tune decision threshold"]
  G["Monitor deployment"]
  A --> B
  B --> C
  C -->|no| D
  D --> B
  C -->|yes| E
  E -->|no| F
  F --> B
  E -->|yes| G

Trade-offs:

• More aggressive detection can capture additional positives while increasing the number of legitimate cases sent for review.
• Resampling can improve learning but alter estimated probabilities, so check the deployed decision rule on representative data.

Precision measures the reliability of positive predictions. Recall measures how many actual positives the classifier finds, so the two metrics answer different operational questions.

• Precision: TP / (TP + FP), where TP is a correctly predicted positive and FP is a negative incorrectly flagged positive.
• Recall: TP / (TP + FN), where FN is an actual positive that the classifier misses at the selected threshold.
• Interpretation: prioritize precision when false alerts are expensive, and recall when missed cases are expensive, while considering the joint operating trade-off.
• Reporting: define the positive class and zero-denominator policy explicitly. For multiple classes, specify whether results are per class, macro-averaged, or micro-averaged.

The F1 score combines precision and recall using their harmonic mean. It is useful when both matter, but it does not describe every aspect of classifier performance.

• Formula: F1 = 2 * precision * recall / (precision + recall), or equivalently 2 * TP / (2 * TP + FP + FN).
• Meaning: a high result requires both useful precision and useful recall; one very weak component pulls the score down substantially.
• Limitation: true negatives do not enter the formula, and equal treatment of precision and recall may not match actual error costs.
• Usage: report the operating threshold, class prevalence, and averaging convention. Inspect the underlying metrics before selecting a model solely by F1.

Both describe classifier behavior across decision thresholds. The first compares detection with false-positive rate; the second shows how positive coverage trades against positive-prediction reliability.

When to use which:

• Use a receiver operating characteristic curve to inspect ranking discrimination across classes, while translating false-positive rates into actual alert counts.
• Use a precision–recall curve when positives are rare and the reliability of flagged cases is central to the operational decision.
• Use threshold-specific results when selecting a deployment policy, because a large area under either curve does not identify the acceptable operating point.

Precision changes with prevalence, and different methods for summarizing the area under a precision–recall curve are not identical.

Discrimination describes how well scores rank different outcomes. Calibration describes whether predicted probabilities match observed frequencies, which matters when probabilities are used to make decisions.

When to use which:

• Use discrimination measures when comparing candidate rankings, especially when downstream decisions depend on selecting the highest-scoring examples.
• Use calibration checks when a probability drives expected-cost decisions, resource allocation, or statements about the likelihood of an outcome.
• Use separate validation or cross-validated predictions to fit a calibration transformation, then recheck it when the population or operating conditions change.

A model can rank cases correctly while assigning probabilities that are consistently too large, so neither property guarantees the other.

I would choose the threshold using validation data and explicit operational costs or constraints. The default midpoint is only a convention, not a generally optimal policy.

1. Define the costs of false positives and false negatives, along with review capacity, minimum recall, or other constraints the application must satisfy.
2. Calculate outcomes across candidate thresholds using representative validation examples. Check calibration if predicted probabilities are used for expected-cost calculations.
3. Select a threshold that satisfies the constraints and performs reliably across important segments, then assess the fixed choice on untouched test data.
4. Monitor workload and outcomes after release. Revisit the threshold when prevalence, capacity, or error costs change, using an auditable update process.

flowchart TD
  A["Define decision constraints"]
  B["Evaluate thresholds"]
  C{"Constraints satisfied?"}
  D["Improve model or capacity"]
  E["Validate fixed threshold"]
  F["Monitor outcomes"]
  A --> B
  B --> C
  C -->|no| D
  D --> B
  C -->|yes| E
  E --> F

Trade-offs:

• Lower thresholds often improve recall but increase review volume and false positives, so choose the whole decision policy deliberately.
• A single threshold simplifies operations, while distinct policies require clear justification and careful monitoring across affected groups.