<<< Previously Next >>>
Lead AI Engineer
Call Reconstruction & Critique
Organised & Structured Transcript
The raw call recording was fragmented and conversational. Below is the cleaned, logically sequenced account of what the interviewee communicated, grouped by topic.
The Anomaly Detection Project — Amex Loyalty Platform
- Project involved detecting anomalies in credit card transaction data on the American Express loyalty platform.
- Anomaly categories targeted: unusually large-amount transactions, unusually small-amount transactions, and anomalies by merchant type.
- Business outcome: the client used these flagged anomalies to generate alerts in their platform and decide whether to block suspicious transactions.
- New data was provided on a quarterly basis for ongoing inference.
Data Engineering & Infrastructure
- Historical training data spanned approximately one to two years of credit card transactions.
- Data originated from Amex's mainframe systems.
- A dedicated data engineering team was responsible for extracting and loading data from mainframes into Hive-based databases.
- The data science team consumed this data via PySpark, running on a Jupyter-like notebook environment within a platform called Cornerstone (a mixed/managed compute platform).
- Data was entirely structured (tabular credit card transaction records).
Feature Engineering & Modelling Approach
- Although the raw data had many columns, the team narrowed focus to four to five key features: transaction amount, merchant type, and time (used primarily for visualisation).
- The problem was framed as unsupervised learning — no ground-truth labels existed.
- Three model architectures were evaluated:
- Isolation Forest
- Autoencoder (neural network based)
- K-Medians clustering
Contamination Factor & Model Validation
- Because there were no labels, a Gaussian Mixture Model (GMM) was used to estimate the contamination factor — the expected proportion of anomalies in the dataset.
- Anomaly scores from Isolation Forest and the Autoencoder were plotted in a scatter plot. Density analysis revealed two regions: a high-density core (normal) and a sparse periphery (anomalous).
- The sparse cluster's percentage of total points became the contamination factor fed into the final models.
- A human-in-the-loop existed: the loyalty/transaction team monitored alerts raised by the system, each alert triggering a ticket for review.
- Precision was reported as above 75–80%, with acknowledged volatility during trend shifts (e.g., Christmas peak spend causing a temporary spike in false positives).
Generative AI Experience — Semantic Search POC
- While on the bench at Cognizant (first two months), developed an internal semantic search POC.
- Source corpus: issues and Q&A threads scraped from GitHub and Stack Overflow.
- Questions and answers were converted to vector embeddings and stored in a vector database.
- At query time, the input was embedded and compared against the stored embeddings using similarity search to retrieve closest matches.
- Self-characterised as a "POC-level" GenAI engagement — not a production deployment.
Location Preferences & HR Discussion
- Based in Delhi (Inderlok area), commuting to Tikri Sector 48 office; also stays at Sector 79.
- Family constraints (mother) tie him to Delhi NCR.
- First preference: Delhi. Acceptable: Gurgaon, Noida. Difficult: Pune, Indore. Not preferred: Bangalore, Chennai.
- Asked about current HCM (Shivam Shrivastav, from AML CoE) — was told HCM may change on project allocation.
Reconstructed Q&A — Full Dialogue
The interviewer's questions have been inferred from context and the interviewee's responses. Each exchange is presented as a coherent dialogue unit.
Critique & Better Answers
A frank, point-by-point evaluation of the responses — identifying weaknesses in communication, technical depth, and strategic framing, with the sharper answer each question deserved.
The introduction was rambling and repetitive — "large transactions or very small number of transactions, large amount transaction or small amount transactions" was said almost verbatim twice. The business impact was buried and vague ("should we block them"). There was no STAR-style framing: no clear statement of scale, no team context, no timeline, and no outcome lead. An interviewer for a Lead role expects structured, confident narration — not a stream-of-consciousness recall.
You reduced an inherently rich challenge to "we zeroed down on four or five features." For a Lead role, the interviewer wants to understand how you chose those features — what was your methodology? Was there domain knowledge involved? Did you run correlation analysis, VIF, or feature importance from a supervised proxy? You also glossed over data quality issues entirely — mainframe-sourced transaction data is notoriously messy (encoding issues, missing fields, schema drift). Saying "it was structured data" and moving on was a missed opportunity.
The technical substance here was genuinely solid — the GMM-based contamination estimation, ensemble of Isolation Forest and Autoencoder anomaly scores, and density-based threshold-setting is a legitimate and thoughtful methodology. However, the explanation was confused and hard to follow. The phrase "we create two clusters… not two clusters, basically one cluster and outside" is almost incoherent when spoken. For a Lead AI Engineer, clarity of technical communication is as important as the technical knowledge itself. You also never explained why you chose Isolation Forest + Autoencoder specifically, or why you dropped K-Medians.
When pushed on why 75% precision wasn't higher, the response became defensive and wandered into an explanation of seasonal false positives — which, while valid, sounded like excuse-making rather than engineering problem-solving. A Lead Engineer should respond to a precision ceiling by describing active remediation strategies: retraining cadence, concept drift detection, ensemble re-weighting, or feedback loop design. You also never mentioned whether you measured recall or framed a precision-recall tradeoff, which is critical in fraud/anomaly contexts where false negatives (missed frauds) are often costlier than false positives.
This is the most damaging part of the interview. You were interviewing for a Lead AI Engineer role in 2024–25 — a role that almost certainly has significant GenAI expectations. You self-described your GenAI background as "not much experience" and spent fewer than five sentences on the only GenAI project you mentioned. You did not name the embedding model used, the vector database, the chunking strategy, the retrieval method (cosine similarity? FAISS? ANN?), or any evaluation approach. You also did not mention any current reading, self-directed learning, or projects in LLMs, RAG pipelines, or LangChain/LangGraph — all of which you've actually explored. This is a credibility-damaging gap for a Lead role.
Raising the location constraint repeatedly and with evident anxiety signals to the interviewer that you may be inflexible. Asking whether it would "impact your availability to the client" reveals a self-awareness about the disadvantage — which, when voiced aloud, reinforces it. In a bench situation, flexibility is a competitive advantage. The better approach is to state a preference clearly and confidently once, without revisiting it or asking the interviewer to manage it for you.
The underlying expertise is real — the contamination factor methodology, the ensemble approach, and the PySpark/Hive stack show genuine ML engineering experience. But the presentation of that expertise was significantly below what a Lead AI Engineer role demands. Two changes would have materially improved the outcome: (1) preparing structured, confident narration for each project using a STAR framework, and (2) leading with GenAI competence rather than apologising for its limits. The knowledge is there — the packaging needs work.
