Wednesday, March 18, 2026

Interview at an Indian IT Services MNC for AI Architect Role (2026 Mar 2)

Index For Interviews Preparation
<<< Previously    Next >>> 
Context about this post

...This is my way of helping others by sharing feedback I received from ChatGPT (5.4 Thinking) on an interview. I hope it can be useful to others who are preparing for interviews, especially in data science and AI/ML roles.

Company: Indian IT Services MNC
Position: Lead AI Engineer / AI Architect


Me: Attached is one-sided call transcript of an interview. It contains just the answers of the candidate (me). 
Can you please organize it / structure it and provide what might have been the questions asked by the interviewer (putting back into the organized structure)?

AND IMPORTANTLY: Critic me and my answers.

Yes. I reconstructed it into a likely interview flow and inferred the interviewer’s probable questions from your answers. Since this is one-sided and a bit noisy, the questions below are approximate, not exact. The transcript clearly shows your intro, project discussion, role/responsibilities, a system-design style answer around ServiceNow/RAG, and Azure/cloud discussion.

Reconstructed interview structure

1) Introduction

Likely interviewer question:
“Can you introduce yourself?”

Your answer:
Good afternoon, I am Ashish. I have around 13 years of total experience, including about 11 years in data science and machine learning. Over the years, I have worked with Python, SQL, PL/SQL, JavaScript, and other technologies.

2) Current / recent project

Likely interviewer question:
“What is your current project? What kind of work are you doing right now?”

Your answer:
My recent/current work is around a Text-to-SQL / analytics-agent style platform. Different teams or markets may call it by different names, but the core idea is similar: the system accepts a natural-language query, generates SQL, and supports analytics workflows. You described it as a multi-agent setup with components such as:

  • a Text-to-SQL agent

  • a RAG agent

  • a general knowledge agent

  • a router

  • a visualization agent

3) Early career and transition into data science

Likely interviewer question:
“How did your career start, and how did you move into data science/ML?”

Your answer:
You started as a software engineer after an internship period of around one to one-and-a-half years. Early on, you worked on web applications using technologies like Java Servlets and JSP. Around 2015–2016, your work shifted more toward data analytics / data science, where the stack centered around machine learning algorithms, statistics, and Python. You also mentioned the popularity of big-data platforms at that time, including Hadoop-era enterprise environments.

4) Past project / client exposure

Likely interviewer question:
“Have you worked on big-data or enterprise-scale client environments?”

Your answer:
Yes. You mentioned working on a client environment where data was stored in Hadoop clusters/private cloud infrastructure, and that you built solutions around that ecosystem. Some names in the transcript are unclear due to transcription quality, so I would treat the exact client/platform names as uncertain.

5) Current role and responsibilities

Likely interviewer question:
“What is your current role? Are you an individual contributor or a manager?”

Your answer:
You described yourself as being in a mixed role, roughly at a mid-level manager/lead level. Your responsibilities include:

  • architecting solutions

  • owning key deliverables

  • assigning work to junior team members

  • helping resolve blockers and challenges

  • also handling some individual deliverables yourself
    You also later mentioned working with a team of around five people and coordinating within a setup that includes a scrum master.

6) Problem-solving / system design question

Likely interviewer question:
“Suppose we have ticket data in ServiceNow and want to build a solution around it. How would you approach it?”

Your answer:
You first tried to clarify the problem, which was good. Then you formed a high-level hypothesis that the problem might be a RAG-style use case. Your proposed approach was:

  1. understand the available data and source systems

  2. ingest data from ServiceNow

  3. use API-based extraction depending on what the API supports

  4. store/process the data, potentially through batch pulls

  5. generate embeddings

  6. load into a vector database

  7. build retrieval over that data for downstream use

You also discussed alternate storage/input possibilities, such as receiving ticket exports in Excel or using something like Azure Blob Storage for convenience.

7) ServiceNow / API handling

Likely interviewer question:
“How would you pull the data? Have you worked with ServiceNow APIs?”

Your answer:
You were honest that you had not worked extensively with ServiceNow APIs, though you had used the interface for viewing tickets. You said the extraction strategy would depend on the API capabilities, such as whether it supports batch downloads, single-ticket fetches, or export flows.

8) Azure experience

Likely interviewer question:
“What Azure services have you used?”

Your answer:
You mentioned using or being familiar with:

  • Azure Functions

  • Azure PostgreSQL

  • Azure Search / vector-search-related capability

  • Azure Kubernetes Service (AKS)

  • Azure Blob Storage
    You also noted that service choice depends on the exact use case and requirements.

9) Backend/frontend integration

Likely interviewer question:
“How would a React frontend interact with Python services on Azure?”

Your answer:
You explained that Python code can be exposed as APIs through Azure Functions. A React-based frontend hosted on Azure Web Apps can then call those API endpoints using the function URLs configured in the frontend. You described the flow at a high level: React UI → Azure Function API → backend logic.

10) API gateway / architecture tradeoffs

Likely interviewer question:
“Why would you use an API gateway?” or “How would you think about cost optimization here?”

Your answer:
Here you were less certain. You said you were not fully sure about API gateway usage in that context, and then shifted to saying cost optimization would require visibility into where the costs are coming from. You also clarified that your main strength has been engineering solutions rather than cost-governance ownership.

My critique of your interview answers

What you did well

You do come across as experienced. The transcript shows real exposure to engineering work, ML/data systems, solution architecture, and team coordination. You also did a few good things that interviewers generally like:

  • you tried to clarify the question before answering

  • you did not bluff heavily about ServiceNow

  • you answered from practical experience instead of purely theoretical language

  • you showed that you can think in systems: ingestion, APIs, embeddings, vector DB, frontend/backend integration, delivery ownership

Where your answers were weak

1) Your answers were too unstructured

This is the biggest issue. You know things, but your delivery sounds scattered. You start one point, branch into another, self-correct, then return halfway. An interviewer may conclude: “He has experience, but he is not crisp.” That hurts especially for senior roles.

2) You used too many filler sounds and repair phrases

There are a lot of “yeah,” “okay,” “I think,” “sort of,” “it depends,” “mm-hmm,” “sorry,” “not exactly sure,” and unfinished clauses. A few are fine. Too many make you sound less confident than you probably are.

3) You often gave partial answers instead of complete answers

Example: when asked about your background, role, Azure, or architecture, your answer often begins correctly but does not land in a clean conclusion. The interviewer is left doing the work of organizing your thoughts. That is costly in interviews.

4) You mixed honesty with under-selling

Being honest about not knowing ServiceNow deeply was good. But you sometimes framed uncertainty too broadly. For instance, instead of “I haven’t used ServiceNow APIs extensively, but I’d approach it through X, Y, Z,” you drifted into uncertain phrasing for too long. That can make your genuine strengths disappear.

5) Your seniority story was not sharply packaged

You clearly have both technical and people responsibilities, but you did not present that in a strong senior-profile way. A stronger version would have been: “I’m primarily a hands-on solution architect/lead. I own architecture and critical deliverables, mentor junior engineers, and also contribute directly to implementation.” Instead, the transcript makes it sound vague and hesitant.

6) Some answers sounded like thinking aloud rather than answering

Thinking aloud is useful in design rounds, but only if it is controlled. In your case, it sometimes sounds like raw internal thinking. Interviewers may interpret that as lack of clarity rather than good reasoning.

Specific places where you likely lost points

On the intro

Your experience is strong, but the opening was messy. You should have given a 20–30 second clean summary. Instead, the intro meandered.

On the current project

You mentioned many good concepts, but the explanation was not clean enough for a listener to immediately understand the product, users, business value, and your exact contribution.

On the ServiceNow/RAG problem

Your first instinct was sensible, but you jumped too quickly to vector DB/embeddings before locking down the user problem, success metric, and ticket schema. For a system-design discussion, you should first define:

  • what users want

  • what data exists

  • structured vs unstructured fields

  • retrieval granularity

  • expected output

  • latency/accuracy expectations
    Then bring in RAG if it truly fits.

On API gateway

This was a visible weak point. “I’m not sure” is okay once. But here it may have made the interviewer question cloud-architecture depth for a senior candidate.

Brutally honest summary

My read: you sound like someone who has done the work, but in this interview you probably did not sound as strong as your actual experience.

The gap is not mainly knowledge. The gap is:

  • answer structure

  • crispness

  • confidence in delivery

  • turning experience into clean interview-ready narratives

So the problem is less “you are weak technically” and more “you are presenting yourself below your true level.” That is exactly the kind of thing that causes interviews to feel unfair afterward.

What you should do differently next time

Use this answer pattern almost everywhere:

1. Direct answer first
“Currently I work as a hands-on lead/manager in a data/ML engineering setup.”

2. Add 2–3 concrete points
“I own architecture, key deliverables, and mentoring of junior engineers.”

3. Close with relevance
“My recent work has been around multi-agent analytics systems including Text-to-SQL and retrieval-based components.”

That structure alone would improve your interview performance a lot.

For design questions, use this pattern:

Problem → assumptions → architecture → tradeoffs → risks

Not:

“maybe vector DB… depends on API… maybe blob storage… maybe Excel…”

Overall assessment

Content strength: good
Communication clarity: below what your experience deserves
Technical credibility: decent to strong in your comfort areas
Senior interview polish: needs work
Main fix needed: structured speaking under pressure

I can next turn this into a clean mock interview transcript with:
Interviewer Question → Your improved answer → my coaching notes.

Me: Yeah, sure, go on.

Absolutely — here’s the clean mock interview version of what your call likely should have sounded like.

I’ve kept it in this format:

Interviewer question
Your improved answer
Coaching note on your original answer

Mock interview transcript — reconstructed and improved

1) Tell me about yourself.

Improved answer:

Good afternoon. I’m Ashish, and I have around 13 years of total experience, with about 11 years in data science and machine learning. Over the years, I’ve worked across software engineering, analytics, and ML solution development. My technical stack includes Python, SQL, PL/SQL, JavaScript, and related technologies.

I started my career in software engineering, building web applications using technologies like Java Servlets and JSP. Over time, I transitioned into data analytics and then into data science and ML, where I’ve spent most of my career. In my current role, I work in a hands-on lead capacity, where I contribute to architecture, delivery, and team guidance.

Coaching note:

Your original intro had the raw material, but it was not packaged well.
Problems in your actual answer:

  • too many filler words

  • repeated yourself

  • mixed intro with project details too early

  • mentioned unnecessary side points like health/fever

In interviews, your intro should feel like a prepared opening statement, not spontaneous thinking.

2) What are you currently working on?

Improved answer:

My current project is an analytics platform built around natural-language-based data access. At a high level, it is a multi-agent system that can take a natural language query, route it appropriately, and generate useful outputs such as SQL queries, retrieved knowledge, or visualizations.

The platform includes components such as:

  • a Text-to-SQL agent

  • a RAG-based retrieval agent

  • a general knowledge agent

  • a routing layer

  • a visualization agent

So the overall goal is to make analytics and information access easier through natural language interaction, while using different agents depending on the nature of the user query.

Coaching note:

Your original answer had strong content, but you described it like someone thinking out loud.
What hurt you:

  • “it goes by different names”

  • “a couple of agents... a couple more”

  • incomplete explanation of business value

  • not enough clarity on your role in the project

A stronger answer always includes:

  1. what the system does

  2. key components

  3. your role

3) What exactly is your role in the team?

Improved answer:

My role is a mix of hands-on technical leadership and delivery ownership. I’m involved in solution architecture, defining key deliverables, assigning work to junior team members, and helping resolve blockers when they face technical issues.

At the same time, I also contribute directly as an individual contributor on important tasks. So I would describe myself as a hands-on lead rather than a purely managerial resource.

Coaching note:

This is one area where you were underselling yourself.

Your original answer sounded hesitant:

  • “sort of a mid-level manager”

  • “mixed responsibilities”

  • “I also get some tasks”

That phrasing weakens you.
You should frame it with authority:

  • “hands-on lead”

  • “architecture + delivery ownership + mentoring”

  • “still involved in implementation”

That sounds senior without sounding inflated.

4) How did you transition from software engineering into data science?

Improved answer:

I began my career as a software engineer, primarily building web applications. Over time, especially around the 2015–2016 period, my work shifted more toward analytics and data-driven problem solving. That naturally led into machine learning and data science, where the underlying work involved Python, statistics, machine learning algorithms, and data platforms.

At that time, big data ecosystems were also becoming very common, so I also worked in environments where data was stored and processed on Hadoop-based or cloud-like enterprise platforms.

Coaching note:

This answer was present in your original transcript, but it was fragmented.
You jumped across:

  • internship

  • Java/JSP

  • 2015/2016

  • big data

  • client environment

All true, but not told in sequence.

For behavioral and background questions, interviewers love timeline clarity.

5) Have you worked on enterprise-scale data platforms?

Improved answer:

Yes. I’ve worked in enterprise environments where data was stored in large-scale distributed systems, including Hadoop-based ecosystems and private-cloud-style setups. My work in such settings involved building solutions on top of those data platforms, especially for analytics and machine learning use cases.

That exposure helped me get comfortable with enterprise constraints such as scale, integration complexity, and platform-driven solution design.

Coaching note:

In your original answer, this part was weak because you were trying to recall client/platform names while speaking. That is risky. If you are not 100% sure, don’t dig yourself into name-recall trouble during an interview.

Better approach:

  • speak confidently about the type of system

  • mention exact client/platform names only if you are sure

6) Suppose we have ticket data in ServiceNow and want to build a solution on top of it. How would you approach that?

Improved answer:

First, I would clarify the use case. For example:

  • Are we trying to answer natural language questions over ticket history?

  • Are we trying to retrieve similar incidents?

  • Are we generating summaries, classifications, or recommendations?

Once the problem is clear, I would examine the data structure in ServiceNow:

  • structured fields such as ticket ID, priority, status, category

  • unstructured fields such as issue descriptions, comments, resolutions

If the use case is knowledge retrieval or question answering over ticket text, then a RAG-based solution could make sense.

A high-level approach would be:

  1. extract ticket data from ServiceNow through available APIs or export mechanisms

  2. clean and normalize the structured and unstructured fields

  3. chunk relevant text where needed

  4. generate embeddings for searchable text content

  5. store those embeddings in a vector store

  6. retrieve relevant tickets or passages at query time

  7. use an LLM to produce the final response, grounded in retrieved ticket data

If needed, structured filtering can also be combined with vector retrieval, for example filtering by date, product, severity, or status before semantic search.

Coaching note:

This was the single most important technical answer in your transcript, and honestly, your original version was not strong enough.

What you did right:

  • you tried to clarify the problem first

  • you recognized it might be a RAG use case

What hurt you:

  • you jumped too fast to embeddings/vector DB

  • you did not first define the actual business problem

  • you were visibly uncertain about ServiceNow integration

  • you sounded like you were constructing the answer live, without structure

For system design, use this order every time:

Use case → data understanding → architecture → tradeoffs

Not the other way around.

7) Have you worked with ServiceNow APIs?

Improved answer:

I’ve interacted with ServiceNow more from the usage side than from deep API integration, so I would not claim extensive hands-on expertise with its APIs specifically. However, the general integration pattern would be familiar: I would first review the available API capabilities, understand the data model, check whether bulk extraction is supported, and then design the ingestion flow accordingly.

So while ServiceNow itself is not one of my strongest direct hands-on areas, building ingestion pipelines from enterprise APIs is something I’m comfortable with.

Coaching note:

This is how you should express partial unfamiliarity.

Your original answer was honest, which was good.
But it became too shaky because you kept circling around uncertainty.

This version is much better because it says:

  • what you have not done

  • what you do know

  • how you would handle the gap

That is senior and credible.

8) What if the data comes as files, like Excel exports, or sits in Blob Storage?

Improved answer:

If the data is delivered as files such as Excel exports, then the ingestion path becomes simpler. We can build a batch ingestion process to read those files, validate schema consistency, transform the contents, and then push the relevant text and metadata into downstream storage systems.

If the files are stored in Azure Blob Storage, then we can use Blob Storage APIs or SDKs to fetch the files, process them in code, and feed them into the next stages of the pipeline. In that case, the design becomes more of a storage-ingestion-processing flow rather than a direct source-system API integration problem.

Coaching note:

Your original answer here wandered too much:

  • Excel

  • Blob Storage

  • Google APIs

  • documentation

  • binary files

You were not fully in control of the answer.

You need to avoid this pattern:
new idea → another idea → correction → another branch

That makes interviewers nervous.

9) Which Azure services have you used?

Improved answer:

I’ve worked with several Azure services, including:

  • Azure Functions for exposing backend logic as APIs

  • Azure PostgreSQL for relational persistence

  • Azure Search / vector-search-related capability for retrieval scenarios

  • Azure Kubernetes Service in broader application deployment contexts

  • Azure Blob Storage for file-based storage and ingestion

My choice of service usually depends on the use case, for example whether the need is lightweight API hosting, structured data persistence, document retrieval, or scalable deployment.

Coaching note:

Your original answer had the list, but not the clarity.

The mistake you made:

  • you started listing services

  • then backed off with “depends on the use case”

  • then apologized

  • then drifted

You need to list them cleanly, then say one line on how you use them. That makes the answer complete.

10) How would a React frontend interact with Python code hosted on Azure?

Improved answer:

A common pattern is to host the frontend separately, for example as a React application on Azure Web Apps, and expose Python backend logic through Azure Functions or another API-hosting layer.

In that setup, the Python code is wrapped as API endpoints. Those endpoints have URLs, and the React frontend calls them over HTTP. So the frontend handles user interaction, and the backend APIs handle business logic, processing, model calls, or database operations.

So the interaction flow is essentially:

React frontend → backend API endpoint → Python logic → response back to UI

Coaching note:

You knew the answer. But in the actual interview, you took too long to say something simple.

That signals a communication issue, not a technical issue.

The clean version above would have made you sound far sharper.

11) Why would you use an API gateway?

Improved answer:

An API gateway can be useful when there are multiple backend services and you want centralized handling for concerns such as routing, authentication, rate limiting, monitoring, and request management.

For example, if multiple APIs are exposed to a frontend or external consumers, an API gateway can provide a unified entry point and improve control, security, and observability. Whether to use it depends on the architecture complexity and operational requirements.

Coaching note:

This was a weak spot in your interview.

You said you were not sure, and then moved toward cost optimization without really answering the question.

A better senior answer is:

  • define what API gateway is used for

  • say when it helps

  • mention tradeoff: not always needed

Even if you haven’t owned API gateway setup directly, you should still be able to answer it conceptually.

12) How would you think about cost optimization in such a system?

Improved answer:

Cost optimization starts with identifying where the major costs are coming from. In a system like this, the major areas are typically:

  • model inference cost

  • vector search / retrieval cost

  • compute or container hosting cost

  • storage cost

  • data transfer / API usage cost

Once the cost drivers are clear, optimization options include:

  • choosing the right model size

  • caching repeated responses where appropriate

  • reducing unnecessary embedding or inference calls

  • batching workloads

  • selecting the right hosting model for expected traffic

  • archiving infrequently used data

In my roles, I’ve primarily been focused on engineering and delivery, but this is the framework I would use to evaluate cost optimization.

Coaching note:

This answer saves you.

Your original answer here basically said:
“I don’t have that view.”

That is too weak for a senior-ish candidate.

Even if you were not the direct owner, you should still be able to speak about cost drivers at a high level.

Brutal but useful criticism of your interview style

Here is the straight version.

1) You sound less senior than you are

You likely have more real experience than the interview reflected.
But the way you answered made you sound:

  • less crisp

  • less confident

  • less structured

  • less architecturally mature

That is not a knowledge problem. It is a delivery problem.

2) You think while speaking instead of speaking from a structure

Your natural pattern seems to be:

  • start answer

  • recall context

  • branch into side detail

  • self-correct

  • partially answer

  • circle back

That is dangerous in interviews.

Interviewers are not scoring your internal thought process.
They are scoring your delivered answer.

3) You use too many fillers and softeners

You repeatedly rely on phrases like:

  • “I think”

  • “sort of”

  • “okay”

  • “yeah”

  • “not exactly sure”

  • “depends”

  • “sorry”

Used occasionally, these are fine.
Used repeatedly, they damage authority.

You do not need to sound aggressive.
But you do need to sound settled.

4) You sometimes answer the wrong layer of the question

For example:

  • asked about ServiceNow use case → you jumped to embeddings

  • asked about API gateway → you moved to cost

  • asked about role → you spoke vaguely about tasks

This creates an impression that you know pieces, but not how to frame answers properly.

5) You leave answers unfinished

This is one of your biggest interview problems.

A good answer has a shape:

  • opening sentence

  • 2–4 supporting points

  • closing sentence

Many of your real answers had:

  • opening sentence

  • side branch

  • correction

  • unfinished drift

That makes the interviewer work harder than they should.

6) You are too transparent about uncertainty

Honesty is good.
Overexposed uncertainty is not.

Bad:

“I haven’t worked extensively... not exactly sure... depends on the API... maybe this... maybe that...”

Better:

“I haven’t worked deeply with ServiceNow APIs specifically, but I’d approach it using the standard enterprise API integration pattern…”

That is honest without sounding weak.

What the interviewer may have concluded

Most likely something like this:

  • “He has real industry experience.”

  • “He has touched relevant technologies.”

  • “He has some architecture exposure.”

  • “But his communication is messy.”

  • “He is not giving confident, clean, senior-level answers.”

  • “I’m not fully convinced of his depth in some cloud/design areas.”

That is probably the honest read.

What you should do before your next interview

Practice these 5 answer templates until they become automatic.

Template 1: Intro

“I’m X, with Y years of experience. My background spans A, B, and C. In my current role, I focus on D.”

Template 2: Project

“The project solves X problem. The architecture includes A, B, and C. My role is D.”

Template 3: System design

“First I’d clarify the use case. Then I’d inspect the data. Based on that, I’d design the ingestion, storage, retrieval, and serving flow.”

Template 4: Partial unfamiliarity

“I haven’t worked deeply with that specific tool, but I’ve handled adjacent integration patterns, and my approach would be X.”

Template 5: Leadership

“I’m a hands-on lead. I handle architecture, critical deliverables, and support junior team members, while also contributing individually.”

Your strongest improved answers to memorize

These are the three you should literally rehearse out loud.

A) Intro

“I’m Ashish, with 13 years of total experience, including around 11 years in data science and machine learning. I started in software engineering and later moved into analytics and ML. My work spans solution architecture, delivery, and hands-on implementation.”

B) Current role

“I work in a hands-on lead capacity. I’m responsible for solution design, key technical deliverables, and guiding junior team members, while also contributing directly to implementation.”

C) ServiceNow/RAG design

“First I’d clarify the use case and inspect the ticket schema. If the goal is semantic retrieval or question answering over ticket history, then I’d design an ingestion pipeline from ServiceNow, transform the relevant text and metadata, generate embeddings, store them in a vector index, and use retrieval plus an LLM to answer user queries.”

Final verdict

You are not blank.
You are not weak.
You are under-packaged.

Your biggest problem is not lack of experience.
It is that your answers do not come out in an interview-friendly shape.

Fix that, and your performance can improve sharply without learning a huge amount of new material.

Posted by at
Labels:

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)