Deloitte Gen AI interview questions & answers

Sure sir. Recently I built an enterprise document chatbot using RAG — Retrieval-Augmented Generation. The pipeline has a few parts. First, document ingestion. Then chunking — breaking documents into small pieces. Then we create embeddings using a transformer model and store them in a vector database. When a user asks a question, we do a similarity search, pick the most relevant chunks, put them in the prompt, and the LLM generates the answer.

Good question sir. There are three reasons. First, cost and token limit. If we send the full PDF with every question, the token count becomes very big and the API cost goes up with every single query. Second, latency. A big prompt takes more time to process, so the time to first token increases and the user waits longer. Third, accuracy. LLMs are actually not very good at finding one small fact hidden in a very long context. This is called the "lost in the middle" problem. With RAG, we give only the few relevant chunks, so the model focuses better.

Usually 500 to 1000 tokens. It depends on the document — if the document is dense or has complex structure, I adjust it. For overlap, I keep around 10 to 20 percent, like 50 to 100 tokens. The reason is, when we cut text, sometimes an important idea gets split between two chunks. Overlap keeps some common text in both chunks, so the meaning and the connection between sentences is not lost during retrieval.

Okay. An embedding converts text into a set of numbers. These numbers represent the meaning of the text. So sentences with similar meaning get similar numbers. That's how the system can compare, group and find text based on meaning, not just matching words.

First thing, I will not directly blame the LLM or change the model. I will check the pipeline step by step. Step one, retrieval — did the vector store actually fetch the correct chunks for that question? Step two, the source data — are the documents in the knowledge base correct and up to date? Step three, the prompt — are the system instructions and the context clearly structured, with no conflicting instructions? Step four, generation settings — like temperature or top-p, if the answer format or reasoning is drifting.

No sir, not 100 percent. Because LLMs are probabilistic — they predict the next token. They are not a fact lookup table. But we can reduce hallucination a lot. Strong RAG grounding, low temperature, telling the model to say "I don't know" when the answer is not in the context, prompt guardrails, and an automatic groundedness check before the answer reaches the user.

Sure. One, user sends the question. Two, the question is converted into an embedding using the embedding model. Three, similarity search runs on the vector database, for example ANN search with an HNSW index. Four, we get the top-K relevant chunks. Five, we combine the system prompt, the chunks and the user question into one prompt. Six, this prompt goes to the LLM. Seven, the LLM generates the answer. The maximum latency is in the LLM generation step — the generation time and time to first token. After that comes embedding generation and network calls. Vector search is usually the fastest part if the index is done properly.

At temperature 0, the model becomes deterministic. It always picks the most likely token, so the answers are consistent and repeatable. That is good for factual extraction and structured tasks. At 1.2, randomness becomes very high. The answers become more creative and varied, but reliability and factual accuracy go down, and the risk of nonsense or hallucination goes up.

I will give two options. Option one, a private enterprise cloud deployment — like Azure OpenAI with private endpoints, where the data is not logged, not stored and not used for training. Option two, self-host an open-source model like Llama 3 or Mistral inside the client's private cloud VPC or on their own on-premise servers. Along with this, security measures — role-based access control with their identity provider like Azure AD or Okta, encryption for data at rest and in transit, and private VPC peering so no data goes out to the public internet.

Okay. I will explain in layers. First, the request flow — employees come through an API gateway with authentication, then a load balancer, then FastAPI services. Before going further, we check a semantic Redis cache. If a similar question was already answered, we return it directly. Otherwise, the service queries the vector database cluster and then the LLM pool.

Okay. So the category is at index 1 in each tuple. I will create an empty dictionary called grouped data. Then I loop over all the batches using data dot values. Inside that, I loop over each tuple. I take the category using item index 1. If that category is not in grouped data, I create an empty list for it. Then I append the tuple to that list. At the end, I print it. So the output will be: category A has 101, 103 and 105, category B has 102 and 104, and category C has 106.

Yes, I can use setdefault, or a defaultdict from collections with list. Then I don't need the if condition — I can directly append. But the logic is the same.

Sure. Step one, the query reaches the agent framework, like LangGraph or CrewAI. The system loads the short-term conversation memory and the previous state. Step two, reasoning — the LLM looks at the user intent and the tool descriptions, which are defined using JSON schemas, and decides whether to answer directly or call a tool. Step three, action — the framework calls the tool, like vector database retrieval, enterprise search, a code interpreter or a REST API. Step four, observation and reflection — the tool result comes back to the agent, and the LLM checks if the goal is achieved. If there is an error or the result is incomplete, it retries or changes the tool input. Step five, once all sub-tasks are done, the final answer is generated, it passes through moderation and safety guardrails, and it is streamed back to the user.

I will use two approaches. First, human-in-the-loop. Before the query hits the database, we pause the agent and show the generated SQL to an authorized person. Only after they approve, it runs. Second, parameterized templates. Instead of letting the LLM write any raw SQL, we write pre-approved, tested SQL templates and store them in a vector database. The agent does a semantic search to find the right template, and the LLM is used only to fill the parameters, like date range or user ID. So the LLM never writes free SQL.

It depends on who leads the engagement. If it is client-led, and the client already has a fixed tech stack — like Azure OpenAI, AWS Bedrock, LangChain or Semantic Kernel — then we build the agent pipeline strictly inside that stack. If it is consultant-led, where we own the architecture, we choose based on the project need. For example, LangGraph for stateful multi-agent systems, AutoGen or CrewAI when agents need to collaborate in different roles, or custom Python orchestration with native APIs when low latency is very important.

Four steps. First, find the bottleneck — I will check the sprint board and see if the problem is a technical blocker, scope creep, or some missing external dependency. Second, re-prioritize — I will do a backlog grooming session with stakeholders, freeze non-essential features, and focus only on the MVP. Third, re-allocate resources — I will pair senior developers with juniors on the critical blocking tasks, so we clear them fast without adding technical debt. Fourth, transparent communication — I will proactively update the project manager and the client lead with the updated burn-down chart, the risk matrix and a clear plan with timelines.