IBM: AI Engineer, Bengaluru (2025)

SELECT department_id, salary
FROM (
  SELECT department_id, salary,
         DENSE_RANK() OVER (PARTITION BY department_id ORDER BY salary DESC) AS rk
  FROM employees
) t
WHERE rk = 2;

• DENSE_RANK handles ties, so two people on the top salary are both rank 1. Window functions work in MySQL 8 and later.

def two_sum(nums, target):
    seen = {}
    for i, x in enumerate(nums):
        if target - x in seen:
            return [seen[target - x], i]
        seen[x] = i
    return []

• One pass with a hash map: O(n) time and O(n) space, compared with O(n²) for brute force. State the brute force first, then optimise.

Answer (a structure to follow):

1. The problem: "Analysts spent hours searching 3,000 policy PDFs."
2. The architecture: loader → chunker (800 tokens, 120 overlap) → embeddings → vector DB → retriever (hybrid + re-rank) → LLM with a citation prompt → FastAPI + UI.
3. Problems and fixes: - Tables were split badly, so I switched to layout-aware parsing. - Wrong chunks were retrieved, so I added a re-ranker and metadata filters. - The model hallucinated, so I made the prompt strict and showed "no answer" when the retrieval score was low.
4. Metrics: recall@5 went from 0.71 to 0.89, faithfulness reached 0.93, and p95 latency was 2.1 seconds.

• Accuracy: only when classes are balanced.
• Precision: of the items predicted positive, how many really are positive. Use it when false positives are costly, such as spam filters.
• Recall: of the actual positives, how many were caught. Use it when misses are costly, such as fraud or disease detection.
• F1: the harmonic mean of precision and recall, for imbalanced data.
• ROC-AUC: ranking quality across thresholds. PR-AUC is better under heavy imbalance.
• Confusion matrix: the full picture. Pick the decision threshold based on the business cost of each error type.

• Offline:
• A golden set of 100 to 500 questions with expected answers.
• Retrieval metrics: recall@k and MRR.
• Generation metrics (RAGAS / DeepEval): faithfulness, answer relevance, correctness.
• Task-specific checks such as exact match for extraction or JSON validity.
• LLM-as-judge with a clear rubric, calibrated against human labels.
• Online: thumbs up/down, escalation rate, resolution rate, latency and cost per query, plus A/B tests for prompt or model changes.
• Safety: toxicity, PII leakage, jailbreak test sets.

• Overfitting: the model learns the noise in the training data, so it scores high on training and low on validation.
• Fixes:
• More or augmented data
• A simpler model
• Regularisation (L1/L2, dropout, weight decay)
• Early stopping
• Cross-validation
• Feature selection
• Ensembles (bagging)
• For LLM fine-tuning: a lower learning rate, fewer epochs, LoRA instead of a full fine-tune, and a held-out evaluation set.

• List vs tuple: a list is mutable; a tuple is immutable, hashable (if its elements are), slightly faster, and can be used as a dict key.
• Shallow copy (copy.copy, list[:]): a new outer object whose nested objects are shared.
• Deep copy (copy.deepcopy): recursively copies everything, so changing a nested item does not affect the original.

1. Clarify: what problem, who the users are, what success looks like (a metric), and the constraints (data, privacy, budget).
2. Check feasibility: what data exists and its quality, whether a simple rule or classic ML would do before reaching for an LLM, and the risks.
3. Build a quick proof of concept on a small evaluation set and show it to users early.
4. Plan production: security, monitoring, cost and a human fallback.
5. Measure and iterate against the agreed metric. - Managers listen for business thinking + pragmatism, not just model names.