Infosys: Senior GenAI Engineer, Final Round

Interviewer: "Your architect asks you to integrate a new GenAI feature (e.g., automated document summarizing with live grounding) into an existing legacy microservice application. How would you handle the end-to-end pipeline from design to deployment?"

                     [ Phase 1: Requirements & Feasibility ]
                                        │
                                        ▼
                     [ Phase 2: System & API Design ]
                     (OpenAPI, Async Decoupling)
                                        │
                                        ▼
                     [ Phase 3: Core Implementation ]
                     (RAG, Vector DB, Guardrails)
                                        │
                                        ▼
                     [ Phase 4: CI/CD & Deployments ]
                     (Canary Release, Blue-Green)
                                        │
                                        ▼
                     [ Phase 5: Telemetry & Observability ]
                     (Traces, Latency, Fallbacks)

Senior Engineering Response Framework:

Phase 1: Requirement Analysis & Architectural Alignment

• Identify Integration Points: Review the existing system architecture to determine whether the new GenAI feature should run synchronously via REST/gRPC or asynchronously via an event-driven bus (e.g., Apache Kafka, RabbitMQ) to prevent blocking main thread execution.
• Define SLAs & Latency Budgets: Establish strict non-functional constraints (e.g., \(P_{99}\) latency \(< 2.5\text{s}\), maximum operational cost per token, rate limits, data compliance/PII filtering).

Phase 2: Interface Design & Isolation

• API First Approach: Define clean OpenAPI/Pydantic schemas for request and response payloads.
• De-coupled Service Layer: Implement the GenAI capabilities inside an isolated microservice or domain module. Abstract model providers behind a unified Provider Interface Pattern (e.g., using LiteLLM or custom wrappers) to easily swap between OpenAI, Anthropic, or local vLLM instances without touching core enterprise logic.

Phase 3: Implementation, Guardrails & Testing

• Resilience Patterns: Wrap external model and vector database calls with Circuit Breakers (e.g., resilience4j or tenacity) and Fallback Logic (e.g., reverting to a smaller, cached, or rule-based model if the main LLM times out).
• Validation & Security: Enforce input prompt sanitization (against prompt injection) and output validation (using Pydantic / Instructor) before passing payloads to downstream services.
• Testing Strategy: Write unit tests for data transformation logic, integration tests with mocked LLM APIs, and evaluation pipelines (e.g., RAGAS) to baseline response context quality before release.

Phase 4: Deployment & CI/CD Pipeline

• Progressive Rollout: Use Canary Deployments or Feature Flags (e.g., LaunchDarkly) to route \(5\%\) of live user traffic to the new GenAI feature while monitoring system health.
• Database Migrations: Run non-blocking zero-downtime database schema updates (e.g., adding vector extensions like pgvector or creating index partitions).

Phase 5: Monitoring & Operational Observability

• Tracing & Metrics: Integrate OpenTelemetry instrumentation alongside GenAI tracing platforms (e.g., LangSmith, Phoenix) to log token consumption, latency breakdown (TTFT - Time To First Token), context retrieval relevance scores, and hallucination rates.

Interviewer: "Your lead architect is significantly more experienced than you and insists on using a single massive LLM prompt with a huge context window for an enterprise query system. You believe a modular RAG pipeline with a smaller, fine-tuned model is cheaper, faster, and more accurate. How do you handle this disagreement?"

          [ Conflict Encountered: Long Context vs. Modular RAG ]
                                    │
                                    ▼
          [ Step 1: Objectivity & Data-Driven PoC Setup ]
                                    │
                                    ▼
          [ Step 2: Establish Evaluation Criteria ]
          (Latency, Token Costs, Context Retrieval Accuracy)
                                    │
                                    ▼
          [ Step 3: Present Trade-off Decision Matrix ]
                                    │
                                    ▼
          [ Step 4: Align with Business Priorities & Commit ]

Senior Engineering Response Framework:

1. Depersonalize and Objective Framework

• Avoid emotional or opinion-based arguments. Frame the disagreement around business constraints, operational cost, \(P_{99}\) latency, and accuracy metrics.
• Acknowledge the architect's experience and validate their perspective (e.g., "Long-context models reduce operational complexity by avoiding vector database infrastructure").

2. Conduct a Data-Driven Benchmark (Proof of Concept)

• Build a quick, side-by-side empirical benchmark using \(50-100\) real-world enterprise test cases.
• Measure both approaches across four standardized dimensions:

3. Present the Decision Matrix Privately

• Schedule a 1-on-1 meeting to present the data matrix without undermining their authority in front of the broader team.
• Frame the recommendation through ROI: "Here is the benchmark data. While the single-prompt approach reduces setup time by 2 weeks, the RAG approach will cut our monthly cloud API bill by 85% and hit our sub-2-second user response target."

4. Disagree and Commit

• If the architect still insists on their approach due to strategic constraints (e.g., strict time-to-market deadlines), accept the decision, document the known technical debt, implement observability to track production costs, and align with the team.

Interviewer: "You are developing Feature A (e.g., LangGraph state transition nodes) while a teammate is working on Feature B (e.g., Fast-API middleware validation). They merge their branch into main first, leaving your branch with complex structural Git conflicts. How do you resolve this safely?"

                        [ Local Feature Branch ]
                                   │
                                   ▼
                        [ git fetch origin main ]
                                   │
                                   ▼
                        [ git rebase origin/main ]
                                   │
                                   ▼
               [ Step-by-Step Interactive Conflict Resolution ]
                                   │
                                   ▼
                [ Execute Unit Tests & Evaluation Suite ]
                                   │
                                   ▼
              [ Peer Code Review & Clean Pull Request ]

Senior Engineering Response Framework:

1. Proactive Conflict Prevention

• Modular Code Structure: Design feature layers cleanly to minimize footprint overlap (e.g., separating business domain logic from shared API schemas).
• Frequent Trunk Synchronization: Keep local branches updated daily by pulling changes from the primary development branch (git fetch + git rebase origin/main).

2. Systematic Conflict Resolution Strategy

• Communicate First: Ping the developer who merged the conflicting PR. Understand the intent behind their changes before modifying or discarding code paths.
• Prefer Rebase over Merge: Run git rebase origin/main on the feature branch rather than git merge main. Rebasing rewrites commit history linearly, making changes easier to audit, revert, or trace during debugging.
• Use Visual Diff Tools: Use IDE diff viewers (VS Code, JetBrains) or merge tools (kdiff3, meld) to inspect conflict blocks line by line.

# Workflow for clean rebase conflict resolution
git checkout feature/langgraph-state-nodes
git fetch origin
git rebase origin/main

# If conflicts occur:
# 1. Open IDE diff tool and resolve conflicts manually
# 2. Stage resolved files
git add path/to/resolved_file.py

# 3. Continue rebase step-by-step
git rebase --continue

3. Post-Resolution Verification & Testing

• Run Regression Suites: Execute all local unit tests, integration tests, and static type checks (mypy, ruff, pytest) to verify that the conflict resolution didn't break existing functionality.
• Peer Review: Request a review on the final PR specifically from the developer whose code overlapped, asking them to review the merged conflict points.

Interviewer: "You have just built a hybrid RAG pipeline using Semantic Cache and Re-Ranking for internal enterprise knowledge retrieval. How do you present and explain this work to (A) your internal technical engineering team, and (B) a non-technical corporate client stakeholder?"

                            [ Engineering Deliverable Completed ]
                                              │
                 ┌────────────────────────────┴────────────────────────────┐
                 ▼                                                         ▼
    [ Audience A: Technical Team ]                          [ Audience B: Non-Technical Client ]
    • Architecture & Mechanics                              • Business Value & Capabilities
    • Vector Search, Cosine Similarity                      • Instant Search Across All Documents
    • Re-Ranker, Cross-Encoders                             • High Precision Answers, No Hallucinations
    • Redis Semantic Caching                                • Reduced Costs & Faster Latency
    • OpenTelemetry & Observability                         • Clear ROI & Time Savings

Senior Engineering Response Framework:

Presentation A: Technical Engineering Team (Architects, Developers, DevOps)

• Focus: System Architecture, Data Flow, Performance Bottlenecks, Trade-offs, and Maintainability.
• Explanation Structure: 1. System Flow: Explain the end-to-end vector pipeline (Chunking \(\to\) Embeddings \(\to\) Vector Search \(\to\) Cross-Encoder Re-Ranking \(\to\) LLM Generation). 2. Performance Optimizations: Highlight how integrating a Redis Semantic Cache reduces overall LLM API costs by \(40\%\) and reduces response time to \(<50\text{ms}\) for repeat queries. 3. Failure Handling: Walk through how the service handles API timeouts, rate-limiting backoffs, and vector database fallback states. 4. Code Walkthrough: Review the Pydantic schema validation, LangChain/LangGraph node setups, and unit test coverage.

Presentation B: Non-Technical Client Stakeholders (Business Leaders, Operations)

• Focus: Business Value, Accuracy, ROI, User Experience, and Risk Reduction (No technical jargon like "Cosine Similarity", "Cross-Encoder", or "Quantization").
• Explanation Structure: 1. The Core Business Problem: "Previously, support employees spent 15 minutes manually scanning through 50-page PDF policy manuals to answer customer questions." 2. The Solution (Analogies): "We built an intelligent search engine that works like a supercharged digital research assistant. Instead of matching simple keywords, it understands the actual meaning behind a question." 3. Key Benefits:
• Speed: Reduces research time from 15 minutes down to 2 seconds.
• Accuracy & Trust: The system highlights the exact source page used for its answer, ensuring verifiable, zero-hallucination outputs.
• Cost Efficiency: Smart caching reduces operational costs by reusing previous answers safely.

4. Live Product Demonstration: Show a real-world user query scenario live, illustrating speed, accuracy, and clear source citations.