Infosys Gen AI interview questions & answers

Good morning sir. I am working on production Gen AI applications — mainly RAG systems and agentic workflows. My own ownership is the orchestration layer — I designed how the agent calls external tools, and I manage the backend execution flow.

In our application, the agent does more than just generate text. The LLM works like a reasoning engine. It looks at the input, decides what action is needed, calls external tools or APIs, gets the feedback, and continues this loop by itself until the task is complete.

The model picks the tool, based on the task and the tool descriptions. But our orchestration layer controls which tools are exposed and what permissions each tool has. To handle wrong tool selection in production — first, very clear tool descriptions and parameter schemas, using Pydantic. Second, restricted tool access and strict input and output validation. Third, fallback handling and loop limits, so the agent fails gracefully or asks the user for clarification, instead of making a chain of mistakes.

Yes sir. MCP, Model Context Protocol, is an open standard that gives AI applications one common way to connect with tools, data sources and context providers. MCP servers expose tools, resources and prompts, and the MCP host can discover them and connect dynamically.

Normal function calling is custom — written directly inside one application for its own hardcoded functions. MCP is a standard protocol layer. Instead of building a separate integration for every tool and every app, any MCP-compatible host can discover and plug into any MCP server. So the client and the tools are decoupled.

Actually they solve different problems. RAG is for when the model needs private or frequently changing company knowledge, without retraining. Fine-tuning is for when we want to change the model's behavior — tone, style, format, or a special domain task. And yes, we can use both together — for example, a fine-tuned model for the right domain tone, which is also grounded with live context from a RAG pipeline.

"Users are happy" is not enough. We evaluate systematically at two levels. Retrieval — precision at K, recall at K and ranking metrics. Generation — faithfulness, relevance and correctness against the retrieved context.

It means our test dataset does not match real user questions. So we capture real production failures, difficult queries, edge cases and user feedback, and keep adding them back into the evaluation test suite.

Concurrent. Async is important because AI backends do a lot of I/O — waiting for network calls — and async doesn't block the event loop while waiting. For three independent calls, like user data, vector DB and order status, I will use asyncio.gather, so all three run together and the total waiting time is much less.

Concurrency is handling many things by switching between them — good for I/O tasks. Parallelism is doing many things at the exact same time on multiple cores — needed for CPU-heavy work like embeddings or chunking. The GIL is a lock in CPython that lets only one thread run Python bytecode at a time. So for CPU-heavy work, threads don't help, and we use multiprocessing.

Having access to tools doesn't mean the agent should use all of them. I will add tool selection rules and routing logic, and clear system prompt instructions on when a tool is really needed. For known, repeated workflows, I will use deterministic routing, so the LLM doesn't need to reason at all. And I will set strict iteration limits and timeouts on tool calls.

No sir. That is a big security and operational risk. We enforce authorization at the application level, role-based access control, and a mandatory human-in-the-loop approval before any destructive or sensitive action — like deleting data or a financial transaction.

Sure sir. The problem was enterprise knowledge retrieval. We built a hybrid system — around half standard RAG and half agentic AI for doing tasks automatically. For the tech stack, LangChain and LlamaIndex for the RAG pipeline, LangGraph and CrewAI for multi-agent workflows, a cloud vector store like Pinecone or pgvector with metadata filtering, and Azure OpenAI or vLLM-hosted models through async endpoints. We deployed it as containerized microservices — FastAPI on Kubernetes with autoscaling — for thousands of employees at the same time. And the documents were mixed — tables, multi-page PDFs, scanned images and plain text.

Complex documents like scanned PDFs and multi-column tables need OCR and heavy parsers, like Unstructured or LlamaParse, so ingestion compute goes up compared to plain text. More documents means more vector storage, and HNSW indexes need a lot of RAM for fast search, so instance cost goes up. To optimize, we use delta ingestion — only new or changed files are chunked and embedded — and metadata pre-filtering, so each search scans less data.

Step one, loading — using document loaders like PyPDFLoader or UnstructuredPDFLoader, so the structure is preserved. Step two, chunking — recursive character chunking, which splits by paragraphs, then lines, then spaces, around 500 to 1000 tokens with 10 percent overlap. Or semantic chunking, which splits when the meaning between sentences changes. Step three, embedding and indexing in a vector database with an ANN index like HNSW. Step four, retrieval — the query is embedded, we get the top-K chunks, and a cross-encoder reranker sorts them by relevance. Step five, generation — the reranked chunks and the question go to the LLM for a grounded answer.

The system prompt sets the role, behavior, tone, rules and safety limits — like "You are an HR policy assistant. Answer only from the given documents." It stays the same across sessions. The user prompt is the actual question in that session — like "What is the annual leave rollover policy?"

Multithreading runs many threads in one process with shared memory. Because of the GIL, only one thread runs Python code at a time, so threads help mainly for I/O tasks — API calls, database queries, file reading. Multiprocessing creates separate processes, each with its own interpreter and memory, so it bypasses the GIL and gives true parallelism on multiple cores. That is good for CPU-heavy tasks like parsing and tokenization.

Most Gen AI backend work is I/O — calling embedding APIs, LLM APIs and vector databases — so threads or asyncio still work well even with the GIL. But CPU-heavy parts like document parsing or computing embeddings locally should go to a process pool, or to worker queues like Celery, so the GIL doesn't become a bottleneck.

LLMs generate by predicting token probabilities — they don't check facts against a truth source. Factors: high temperature or high top-P, which makes the model pick lower-probability tokens. Poor or noisy context — irrelevant, cut-off or conflicting chunks in the prompt. And very long prompts, where the model misses details in the middle — the "lost in the middle" problem.

For evaluation, we use RAGAS or DeepEval — faithfulness, answer relevance, context precision and context recall. For monitoring, we use LangSmith, Arize Phoenix or OpenTelemetry to trace every step, and we watch time to first token, token usage, latency per component, error and refusal rates, and user feedback like thumbs up and thumbs down.

I will do it in five phases. Phase one, requirements — decide whether it should be a synchronous REST call or asynchronous through an event bus like Kafka, so it doesn't block the main flow. And fix the SLAs — for example p99 latency under 2.5 seconds, cost per token, rate limits and PII rules. Phase two, design — API first with OpenAPI and Pydantic schemas, keep the Gen AI part in an isolated service, and hide the model provider behind one interface, like LiteLLM, so we can switch between OpenAI, Anthropic or vLLM easily. Phase three, implementation — circuit breakers and fallbacks around model and vector DB calls, prompt injection checks on input, Pydantic validation on output, and unit tests, integration tests with mocked LLMs, and a RAGAS baseline. Phase four, deployment — canary release or feature flags, starting with around 5 percent of traffic, and zero-downtime database changes. Phase five, monitoring — OpenTelemetry plus LangSmith or Phoenix for tokens, latency, time to first token, retrieval relevance and hallucination rate.

I will keep it objective, not personal. First, I will respect his view — long context does avoid vector database complexity. Then I will build a quick benchmark with 50 to 100 real test cases and compare both approaches on accuracy, p99 latency, cost per 1000 queries and vendor lock-in. Then I will present the results to him one-on-one, not in front of the whole team, in terms of ROI — like "this saves our API cost and meets the 2-second target." And if he still decides on his approach because of business reasons like a deadline, I will disagree and commit — accept it, document the technical debt, and add monitoring for cost.

First, I will talk to the teammate and understand their changes before touching anything. Then I will fetch origin and rebase my branch on origin main, instead of a merge, so the history stays clean and linear. I will resolve the conflicts in an IDE diff tool, add the files, and continue the rebase step by step. After that, I run all unit tests, integration tests and type checks. And I ask that same teammate to review the conflict points in my pull request. To prevent this in future, I keep my branch updated daily and keep the code modular.

For the technical team, I will explain the architecture — chunking, embeddings, vector search, cross-encoder reranking and LLM generation — and how the Redis semantic cache cuts LLM calls and makes repeat queries very fast, how we handle timeouts and rate limits, and then a code walkthrough. For the client, no jargon. I will say — earlier, employees spent around 15 minutes searching a 50-page PDF. Now it's like a smart digital research assistant that understands the meaning of the question and answers in about 2 seconds, with the exact source page, so they can trust it. And smart caching reduces the running cost. Then I will show a live demo.