« Previously Next »
Lead AI Engineer
@ Turing
Organized Call Transcript
The call was a recruiter-led telephonic screening. It followed five natural phases: mutual introductions, company pitch, candidate background walk-through, technical Q&A, and logistics / next steps.
Introductions & Role Context
Ronak introduces himself as a recruiter at Turing. He describes Turing's evolution from a staff-augmentation bridge connecting US companies with Indian developers (since 2018) to an AI-services company over the past three to four years. The open role is a Principal Engineer (IC-6) — one level below Engineering Manager — requiring 10+ years of experience, Python-heavy background, and 2–3 years of hands-on work in Generative AI, agentic systems, LangChain/LangGraph, RAG, and LLMs. The role is hybrid (Mumbai / Hyderabad / Bangalore / Gurgaon) with partial US-hours overlap (1 PM – 10 PM IST).
Candidate Self-Introduction
Ashish introduces himself as currently working at Accenture as a Lead AI Engineer. His current project is a multi-agent Text-to-SQL platform for a telecom client, built with a Text-to-SQL agent, a RAG agent, and a Generic Knowledge agent. He declares 13 years of total experience, 5–6 years in GenAI, and 2–3 years in RAG and agentic systems. Education: M.Tech from BITS Pilani.
Career History Walk-Through
Technical Q&A
The recruiter asked five technical questions covering: multi-agent system design & challenges; LLM cloud deployment & scalability; requirements gathering involvement; agent vs. LLM-call distinction in LangGraph; and failure/dead-end handling strategies. Answers are reconstructed in Section 2.
Motivation, Compensation & Logistics
Ashish cites project fit as the reason for leaving Accenture. Current CTC: ₹29.5 LPA. Expectation: ₹35 LPA. Competing offer: ₹32 LPA from an MNC. Notice period: serving notice, last day 21st April. Next steps agreed: coding challenge (Wednesday, 6 PM) — 45-minute RAG pipeline in Python using OOP, followed by a 5–6 question AI video screen, then a panel, then a technical + culture-fit round.
Reconstructed Q&A
Five technical questions were asked. Below is the probable exact phrasing, followed by the candidate's answer as delivered.
Can you walk me through a project where you built or extended a multi-agent workflow using LangChain, LangGraph, or an equivalent framework — and what challenges did you face during the orchestration, reasoning, or evaluation phases?
Ashish described the Data Analytics Platform at Accenture — a LangGraph-based multi-agent system for a telecom client. The orchestrator agent routes incoming queries to one of three branches: (1) a Text-to-SQL agent that converts natural language to SQL and fetches data, feeding a narrative/visualization agent; (2) a RAG agent for KPI/platform documentation queries; (3) a generic catch-all agent. He mentioned GPT-4.1 on Azure OpenAI as the LLM. The challenge cited was the model selection decision (GPT-4.1 vs. smaller models) and designing the agent graph topology.
Can you give me an example where you deployed an LLM-based system on a cloud platform and had to optimize it for scalability and performance?
Ashish was candid: the LLM was pre-hosted on Azure OpenAI and consumed as an API, so he did not personally fine-tune, host, or scale an LLM on cloud infrastructure. He acknowledged this as a gap in his experience.
Do you get involved in the requirements-gathering phase? If yes, what technical and non-technical aspects do you look out for from a client to better understand requirements?
Ashish said requirements gathering is handled by the associate director level and business analysts at Accenture. He mentioned BAs define acceptance criteria and KPIs to measure solution performance, but acknowledged he is not personally involved in that phase.
Can you explain what an agent is in LangGraph and how it is different from a simple LLM call?
Ashish explained that an agent is a task-performing entity — it can be an LLM call, a Python function, or a pre-written script. A simple LLM call is just hitting an API endpoint with a prompt and capturing the output. An agent need not be an LLM call; it has additional characteristics like defined inputs, outputs, and a specific purpose within the graph.
What do you do when an agent fails or hits a dead end in your workflow?
Ashish described the Text-to-SQL agent looping in a generate → critique → regenerate cycle. His solution was to add a recursion/loop limit on the graph to break out of infinite loops. He then mentioned a graceful fallback — returning a user-facing message such as "I wasn't able to find an answer" when the limit is hit.
Critique & Better Answers
Below is an honest, direct assessment of each answer — where it fell short and what a stronger response would have looked like. The goal is to help you walk into the next round sounding like the Principal Engineer the role demands.
Multi-Agent System Design & Challenges
PartialWhat went wrong
The architecture description was accurate but surface-level. You described what the system does but not why the design decisions were made. More critically, you listed "model selection" as a challenge — that is a pre-build decision, not an orchestration challenge. The recruiter specifically asked about challenges in orchestration, reasoning, or evaluation. You missed all three of those dimensions.
Better Answer
"The hardest orchestration challenge was deterministic routing. The orchestrator had to decide — at inference time — whether a query belonged to Text-to-SQL, RAG, or the generic agent. Early on, the LLM-based router was misclassifying ambiguous queries, so we added a structured output schema with confidence scores and a fallback re-classification step. On the reasoning side, the Text-to-SQL agent was hallucinating table names that didn't exist in the schema, so we injected a schema-grounding step that dynamically fetches the relevant table DDLs and passes them in the prompt. For evaluation, we had no ground truth SQL, so I built a semantic equivalence evaluator that runs both the generated SQL and a gold-standard query on a small test dataset and compares result sets. That gave us a measurable accuracy metric instead of relying on vibe-checks."
LLM Cloud Deployment & Scalability
WeakWhat went wrong
Admitting a gap is honest — and I respect that — but you stopped there. You had adjacent experience you could have leveraged: you consumed Azure OpenAI APIs at scale, which means you dealt with rate limits, token budgeting, latency, and cost. That is real, deployable knowledge. By saying only "I lack here," you left value on the table and gave the recruiter nothing to anchor on.
Better Answer
"I haven't personally fine-tuned and self-hosted an LLM, but I've worked extensively with Azure OpenAI at scale and hit the scalability problems from the consumer side — which is arguably where the real engineering lives in enterprise GenAI. We managed TPM and RPM rate limits by building a token-budget middleware layer, implemented exponential-backoff retry logic for 429s, and used async LangGraph execution to parallelize agent calls wherever the graph allowed it. On the evaluation side, I tracked P95 latency per agent node and used that to identify bottlenecks. If the role requires fine-tuning and hosting custom models, I'm confident I can close that gap quickly — I've been reading up on vLLM and GGUF quantization deployments on AKS."
Requirements Gathering Involvement
WeakWhat went wrong
This question was a test of your Principal Engineer mindset — not just your current job description. A Principal IC is expected to be the technical voice in discovery conversations. By saying "that's handled above me," you signalled that you operate in execution mode only. That is a Lead Engineer answer, not a Principal Engineer answer.
Better Answer
"Formally, our BAs and associate directors own requirements. But in practice, for an agentic AI system, there are questions only an AI engineer can ask — and I make it a point to be present for at least the technical discovery sessions. The things I specifically probe for: What are the data sources and their query SLAs? Are there PII or data residency constraints that affect model choice? What does the client define as a 'wrong answer' — because that shapes the evaluation harness from day one. How tolerant is the user persona for latency vs. accuracy tradeoffs? And crucially — what does failure look like in production? Those questions save you weeks of rework."
Agent vs. LLM Call in LangGraph
AdequateWhat went wrong
Your core definition was correct. But for a Principal Engineer role, "correct" is baseline — the recruiter wanted to hear you talk in LangGraph's actual mental model: nodes, state, conditional edges, and the ReAct loop. The answer lacked any LangGraph-specific vocabulary and felt generic.
Better Answer
"In LangGraph, an agent is a node in the state graph — it receives the shared state, performs some transformation (LLM call, tool invocation, business logic, or even a deterministic function), and writes back to the state. A simple LLM call is stateless by definition — it has no awareness of what happened before or what comes after. What makes something an agent in the LangGraph sense is the combination of state awareness, decision-making capability (conditional edges), and the ability to invoke tools or call sub-graphs. The ReAct pattern — Reason, Act, Observe — is the canonical loop that distinguishes a reasoning agent from a simple completion call. In our platform, even our 'generic' agent was technically an LLM node, but it had tool-binding to a document retriever and could loop until it had enough context, which is what made it an agent rather than a single-shot call."
Agent Failure & Dead-End Handling
AdequateWhat went wrong
Mentioning the recursion limit and graceful fallback is good — that's a real production pattern. But you presented it as the only solution to one specific failure mode (infinite loop). A Principal Engineer would enumerate a taxonomy of failure modes and a layered resilience strategy. You only covered one layer.
Better Answer
"We categorise agent failures into three buckets. First, infinite loops — the generate-critique-regenerate cycle you've seen; we handle this with LangGraph's recursion_limit and a human-in-the-loop node that fires when the limit is hit. Second, tool errors — the SQL agent trying to query a table that doesn't exist; we wrap every tool call in a structured error schema so the agent receives a machine-readable error rather than an exception traceback, which lets it self-correct in the next iteration. Third, semantic dead ends — the agent produces a technically valid answer that doesn't address the user's intent; we detect this with a lightweight LLM-as-judge evaluator node that scores relevance before the response is surfaced. If the score is below threshold, the query is routed to a human escalation channel. The key principle is: every failure mode needs a different recovery strategy, so you build resilience in layers, not as a single catch-all."
Reason for Change & Motivation
WeakWhat went wrong
You said "the project wouldn't suit me too much." That is vague to the point of raising flags. To a recruiter, an unexplained dissatisfaction with a current project can read as a conflict with the team, a performance issue, or a lack of commitment. It also makes you sound passive — as if work happens to you rather than you driving it. This was a low-risk question that deserved a sharper, more intentional answer.
Better Answer
"The work at Accenture has been technically solid, but the scope of the Principal Engineer role I'm stepping into here is different in kind. I want to be the person who owns the full technical lifecycle — from shaping what we build in requirements to the evaluation harness in production — not just the senior person who executes well within a defined scope. The Turing role, as you've described it, is explicitly that: an IC-6 close to the EM layer, building agentic systems from the ground up. That's the trajectory I'm optimising for."
Overall Assessment
You know your material. The multi-agent platform you built is genuinely impressive — but the interview didn't reflect that. The gap was not knowledge but framing. You consistently answered at Lead Engineer altitude when the role demands Principal Engineer altitude. The recruiter even flagged this: "you're giving right answers but getting confused in between."
Before the next round, internalise one rule: every answer should include (a) what you built, (b) why you made the key decisions, and (c) what you would do differently. That is Principal-level thinking. It's the difference between narrating a project and demonstrating architectural judgment.
