GenAI Interview
Saviour

• Amazon Bedrock: managed foundation-model access, Knowledge Bases, Agents, Guardrails, model evaluation/customization, and multimodal RAG capabilities.
• Amazon Bedrock AgentCore: production agent platform concerns such as secure runtime, enterprise tool/data connectivity, identity, tracing, debugging, evaluation, and AgentCore Policy for agent-to-tool controls.
• Inference optimization: evaluate prompt caching and intelligent prompt routing where supported; confirm current model, region, and cost behavior.
• Inference choice: Bedrock for managed models; SageMaker AI endpoints/HyperPod or EC2/EKS/ECS when deeper model/runtime control is required.
• Architecture: apply the AWS Generative AI Lens and security reference architecture, not only service wiring.

• Gemini Enterprise Agent Platform / Vertex AI: build, deploy, govern, and optimize enterprise agents and GenAI workloads.
• Vertex AI Agent Engine: managed agent runtime with sessions, Memory Bank, code execution, observability, private networking, CMEK, resource/concurrency controls, and enterprise compliance support.
• Google Agent Development Kit: an open-source, model-agnostic framework with current SDKs across Python, TypeScript, Go, Java, and Kotlin; evaluate it alongside A2A for interoperable agents.
• RAG choices: RAG Engine, Vector Search, Agent Search, Feature Store vector retrieval, or custom AlloyDB/Cloud SQL patterns depending on scale and control.
• Serving: Vertex AI managed endpoints/Model Garden or Cloud Run/GKE for application and custom-runtime control.

Strong answer: “I maintain a task-specific evaluation and route to the smallest model tier that passes quality, safety, latency, and cost gates. I avoid choosing from benchmark headlines alone.”

Interview-safe answer: use each provider's current unified API and capability discovery, but select models with an evaluation suite rather than a memorized leaderboard. For OpenAI, the Responses API is the primary agentic build path and works with tools, structured outputs, and the Agents SDK; its latest-model guide currently recommends GPT-5.5 for complex reasoning and coding. On AWS and GCP, confirm the model, feature, region, quota, and data-governance combination before committing to an architecture.

Exact-date answer: the current stable MCP specification is 2025-11-25. A 2026-07-28 release candidate was announced on May 21, 2026, but its final release is scheduled for July 28, 2026, so do not call it the current stable spec yet. The RC adds a stateless core, Extensions, MCP Apps, Tasks, and authorization hardening.

Threat-model against the OWASP Top 10 for LLM Applications 2025 and the OWASP Top 10 for Agentic Applications 2026. The agentic list expands the focus to goal hijacking, tool misuse, identity and privilege abuse, memory poisoning, insecure inter-agent communication, cascading failures, and rogue agents.

1. 1
   Assume model output is untrusted: never use it as authorization; validate every argument and output.
2. 2
   Bound agency: least-privilege identities, egress allowlists, step/time/token budgets, idempotency, and human approval for high-impact actions.
3. 3
   Protect state: isolate tenants, provenance-tag memory, expire/delete it, and prevent untrusted content from becoming durable instructions.
4. 4
   Verify continuously: adversarial evals, red-team tests, audit trails, kill switches, and incident exercises.

Check an item only after doing it without reading the answer. The score persists in this browser.

1. 1
   Representative tasks: normal, edge, adversarial, multilingual, long-context, and no-answer cases.
2. 2
   Layered graders: deterministic checks, calibrated human labels, then scalable LLM judges.
3. 3
   Track slices: document type, user, query complexity, tool, model, and route.
4. 4
   Gate releases: block critical safety, quality, latency, or cost regressions.
5. 5
   Close loop: production traces and corrections become new eval cases.

1. 8m
   Resume: career walkthrough; defend sub-second latency and one percentage claim.
2. 8m
   Depth: hybrid retrieval, reranking, evaluation, and when RAG is wrong.
3. 15m
   Design: secure multi-tenant financial research assistant with citations at 500 QPS.
4. 8m
   Incident: P95 doubles and faithfulness drops after an index refresh.
5. 6m
   Behavioral: disagreement, failure, remote collaboration, why this role.

1. 1
   Scope: slice by source, parser, document/query type, index version; verify eval set.
2. 2
   Separate stages: inspect Recall@K/MRR and retrieved chunks before blaming generation.
3. 3
   Hypotheses: parsing, duplicates/noise, metadata, embedding mismatch, top-k dilution, stale index.
4. 4
   Mitigate: roll back index alias, isolate bad source, restore configuration.
5. 5
   Prevent: ingestion gates, canary index, regression suite, versioned promotion.

1. 1
   Check eval representativeness and recent production failures.
2. 2
   Slice by user, language, task, context length, tool, and route.
3. 3
   Validate graders for bias, leakage, weak rubrics, and poor agreement.
4. 4
   Compare paired traces and UX/latency changes, not only answer scores.
5. 5
   Roll back/reduce traffic, add failures to evals, recalibrate gates.

Clarify: async concurrency, timeout, retryable errors, backoff/jitter, rate limits, idempotency, validation, budget, cancellation, metrics, fallback.

async def bounded_llm_call(request, *, timeout_s, max_attempts, budget):
    # validate + reserve budget; acquire concurrency permit
    # call with timeout/idempotency; retry transient errors only
    # validate output; emit trace/metrics; release resources
    ...

Typical emphasis: recruiter/hiring-manager conversations, role-specific technical assessment or interview, cross-functional conversations, values, and strong written async communication. Difficulty is high because remote effectiveness is evaluated as an engineering competency.

Typical loop: recruiter screen followed by role-specific interviews with technical and team stakeholders. Your strongest bridge is OpenSearch, hybrid retrieval, vector search, observability, and distributed remote delivery.

Typical pattern: detailed written application/questions, domain review, assessments, and multiple interviews shown in a personalized candidate dashboard. Difficulty comes from breadth, written precision, and process length.

Published process: application → interview → paid trial → final interview → offer. Developer hiring is conducted through the tools the company uses, so communication and practical execution matter as much as discussion.

Published early stages: application review → recruiter interview → 45–60 minute hiring-manager interview, followed by role-specific skills assessment/final stages. Applications focus strongly on evidence of what you can do.

Naive RAG uses only dense vector search (bi-encoder embeddings + ANN). It captures semantic similarity well but fails on exact keywords, entity names, numeric IDs, or ticker symbols.

Hybrid RAG combines dense vector search with sparse BM25 (TF-IDF based keyword matching). The two result lists are merged using Reciprocal Rank Fusion (RRF): each document gets a score of Σ 1/(k + rank_i) across all rankers, and documents are re-sorted by this fused score.

from langchain.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever
from langchain_community.vectorstores import OpenSearchVectorSearch

# Sparse retriever
bm25 = BM25Retriever.from_documents(docs, k=10)

# Dense retriever
vs = OpenSearchVectorSearch.from_documents(docs, embeddings)
dense = vs.as_retriever(search_kwargs={"k": 10})

# Hybrid: 40% BM25 + 60% semantic, merged via RRF
hybrid = EnsembleRetriever(
    retrievers=[bm25, dense],
    weights=[0.4, 0.6]   # tune per domain
)

Chunking directly controls what the retriever can find. The wrong chunk size either splits context across boundaries or retrieves too much noise.

Always add chunk overlap (10–20% of chunk size) so sentences at boundaries aren't orphaned. Metadata-enrich every chunk: source_file, page_number, created_at, entity_type — these become filterable fields in the vector DB.

Initial retrieval uses a bi-encoder (query and document embedded separately) because it's fast — you embed the query once and do ANN lookup. But bi-encoders miss subtle relevance nuances.

A cross-encoder re-ranker takes (query, document) pairs and scores them jointly with full attention — far more accurate. You run it on just the top-20 retrieved results (not the full index), making the cost manageable.

Use re-ranking when: precision matters over throughput (finance, healthcare, legal), corpus has many near-duplicate docs, or faithfulness is critical.

from langchain.retrievers import ContextualCompressionRetriever
from langchain_cohere import CohereRerank

reranker = CohereRerank(model="rerank-english-v3.0", top_n=5)
retriever = ContextualCompressionRetriever(
    base_compressor=reranker,
    base_retriever=hybrid_retriever  # retrieve top-20 first
)

RAG Fusion uses the LLM itself to generate multiple alternative query reformulations from the user's original query, runs each through the retriever independently, then fuses all result lists with RRF before generating the answer.

Standard hybrid RAG uses one query, two retrieval methods (dense + sparse), then fuses. RAG Fusion uses N query variations, one or more retrieval methods, then fuses — it solves vocabulary mismatch and query ambiguity at the query level.

def rag_fusion(query: str, k=5):
    # 1. Generate query variations via LLM
    variations = llm.invoke(f"Generate 4 alternative versions of: {query}")

    # 2. Retrieve for each variation
    all_results = {}
    for q in [query] + variations:
        results = retriever.invoke(q)
        for rank, doc in enumerate(results):
            doc_id = doc.metadata["id"]
            all_results[doc_id] = all_results.get(doc_id, 0) + 1/(60 + rank)

    # 3. RRF sort and return top-k
    return sorted(all_results, key=all_results.get, reverse=True)[:k]

RAG evaluation has two orthogonal dimensions: retrieval quality (did we get the right chunks?) and generation quality (did the LLM use them faithfully?).

from ragas import evaluate
from ragas.metrics import (
    faithfulness, answer_relevancy,
    context_precision, context_recall
)
from datasets import Dataset

dataset = Dataset.from_dict({
    "question": questions,
    "answer": generated_answers,
    "contexts": retrieved_chunks_per_q,   # List[List[str]]
    "ground_truth": reference_answers
})

results = evaluate(
    dataset,
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall]
)
print(results.to_pandas())

1. 1
   Grounding instructions in system prompt: Explicitly instruct the LLM: "Answer only from the provided context. If the answer is not in the context, say 'I don't have enough information.'" This alone reduces hallucinations ~40%.
2. 2
   Citations at generation time: Ask the LLM to cite the source chunk for every claim. You can then programmatically verify the citation exists in the retrieved context.
3. 3
   Faithfulness guardrail: Run RAGAS faithfulness check on a sample of production traffic. Alert if score drops below threshold.
4. 4
   Confidence thresholding: If retrieval similarity scores are all below a threshold (e.g., cosine < 0.6), return "no relevant information found" rather than hallucinating.
5. 5
   NeMo Guardrails / Bedrock Guardrails: Add a post-generation layer that checks the answer doesn't reference topics outside the retrieved context.

GraphRAG (Microsoft, 2024) builds a knowledge graph from documents — entities become nodes, relationships become edges. Retrieval traverses the graph rather than (or in addition to) doing vector search.

It excels when the question requires connecting multiple entities across many documents ("What are all the risk factors shared by companies X and Y?") — a pattern that naive RAG misses because no single chunk contains the answer.

Multi-turn RAG needs to resolve references ("it", "the same document", "as you mentioned") to prior turns before retrieval — otherwise the query is incomplete.

• Query condensation: Pass last N messages + current query to LLM with instruction "Rewrite the final question as a standalone query." Then retrieve with the condensed query.
• ConversationalRetrievalChain: LangChain's built-in pattern handles this automatically.
• Context window management: Summarise old turns with a summarisation LLM when conversation exceeds 20 turns, to keep token cost bounded.
• External memory stores: For long-running sessions, persist summaries to Redis or a DB keyed by session_id.

LangGraph is a low-level orchestration runtime for long-running, stateful agents. A StateGraph models work as nodes and edges; typed shared state flows through the graph and nodes return partial updates. Persistence enables durable execution, streaming, human-in-the-loop interrupts, and recovery. LangChain agents are a higher-level interface built on LangGraph; use LangGraph directly when you need explicit state and control.

from langgraph.graph import StateGraph, END
from langgraph.checkpoint.sqlite import SqliteSaver
from typing import TypedDict, List, Annotated
import operator

class AgentState(TypedDict):
    messages: Annotated[List, operator.add]  # reducer: append
    retrieved: List[str]
    answer: str
    iteration: int

def retrieve_node(state: AgentState) -> dict:
    docs = retriever.invoke(state["messages"][-1].content)
    return {"retrieved": [d.page_content for d in docs]}

def generate_node(state: AgentState) -> dict:
    answer = llm.invoke(state["messages"] + state["retrieved"])
    return {"answer": answer, "iteration": state["iteration"] + 1}

def should_continue(state: AgentState) -> str:
    if state["iteration"] >= 3: return "end"
    if "insufficient" in state["answer"]: return "retrieve"
    return "end"

graph = StateGraph(AgentState)
graph.add_node("retrieve", retrieve_node)
graph.add_node("generate", generate_node)
graph.set_entry_point("retrieve")
graph.add_edge("retrieve", "generate")
graph.add_conditional_edges("generate", should_continue,
    {"retrieve": "retrieve", "end": END})

# Checkpointing = persistence across turns (human-in-the-loop)
memory = SqliteSaver.from_conn_string(":memory:")
app = graph.compile(checkpointer=memory, interrupt_before=["generate"])

ReAct interleaves reasoning and action so a model can use observations from tools before choosing the next step. In production, do not depend on exposing the model's private reasoning trace. Log auditable state transitions, tool calls, arguments, results, policy decisions, and concise model-provided rationales instead.

Function/tool calling is the typed application interface: the model emits a structured tool request, the application validates and authorizes it, executes the tool, then returns the result. ReAct is a reasoning-and-action pattern; tool calling is an execution contract, and they can be used together.

1. 1
   Explicit budgets: Set graph-step, per-tool retry, wall-clock, token, and cost limits. Force a safe terminal state when any budget is exhausted.
2. 2
   Tool output validation: Wrap every tool in a Pydantic model. If the tool returns unexpected schema, raise a ToolException — the agent sees the error and can self-correct (max 1 retry per tool).
3. 3
   Structured outputs for routing: Force the routing decision via JSON schema (with_structured_output). Eliminates free-text routing that the LLM might misformat.
4. 4
   Human-in-the-loop for side-effecting actions: Any tool that writes to a DB, calls an API with side effects, or sends a message gets an interrupt_before checkpoint in LangGraph — requires explicit human approval.
5. 5
   Deterministic policy layer: Treat all model and tool output as untrusted. Enforce identity, authorization, egress, argument validation, effect receipts, and audit outside the model.

1. 1
   Microservice isolation: Each agent runs as a separate AWS Lambda / ECS container. Agents communicate through an SQS queue, decoupling their lifecycles and enabling independent scaling.
2. 2
   Async fan-out: Orchestrator dispatches sub-tasks via asyncio.gather — all sub-agents run concurrently. Only the final merge step waits.
3. 3
   Result caching: Sub-agent results for repeated sub-tasks are cached in Redis (TTL: 5 min for volatile data, 1hr for reference data).
4. 4
   Circuit breaker: If a sub-agent fails 3× in 60s, the orchestrator marks it unavailable and falls back to a degraded path rather than propagating failure.

MCP (Model Context Protocol) is an open client-server protocol for connecting AI applications to reusable tools, resources, and prompts. It reduces one-off integration code, but it does not remove the need to trust the server, authenticate users, authorize every action, validate outputs, and obtain approval for high-impact effects.

As of June 14, 2026: the stable specification is 2025-11-25. The 2026-07-28 release candidate is available for testing, with final release scheduled for July 28, 2026. MCP connects applications to context/tools; A2A focuses on agent-to-agent discovery and communication.

Security answer: protocol compatibility is not authorization. Authenticate identities, apply least privilege, validate schemas, constrain egress, record effect receipts, and require approval based on risk.

Strong answer: start from the task and operating constraints. Prototype the simplest bounded workflow, add model-driven autonomy only where it improves measured task success, and choose the platform that minimizes undifferentiated operations without trapping critical business logic.

1. 1
   Semantic caching (biggest win): Cache (query_embedding, response) pairs in Redis. On each new query, compute embedding similarity — if cosine > 0.92 with a cached query, return cached response. Typically serves 30–50% of traffic from cache at near-zero latency.
2. 2
   Streaming responses: Use SSE/streaming so the user sees the first token in ~400ms instead of waiting for the full response. Perceived latency drops dramatically.
3. 3
   Async concurrent retrieval: Run BM25 and dense retrieval concurrently with asyncio.gather. If retrieval and LLM call can overlap, pipeline them.
4. 4
   Prompt compression: Use LLMLingua to compress long retrieved contexts before sending to the LLM — reduces input tokens 20–40%, direct latency reduction.
5. 5
   Model routing: Route classification and simple extraction to the smallest evaluated low-latency model tier; reserve a stronger reasoning tier for complex generation. Re-benchmark by provider and region because model names, pricing, and latency change.
6. 6
   Connection pooling: Reuse HTTP connections to the Bedrock endpoint. AWS SDK connection pool + keep-alive saves 80–120ms per cold connection.

Prompts are code. Changing a prompt is a deployment. Without versioning, you can't roll back a bad prompt change that's causing hallucinations.

1. 1
   Store prompts in LangSmith Hub or a config store (SSM Parameter Store / Git): Every prompt has a version hash. Production always pins a specific version.
2. 2
   Evaluation gate in CI: PR changing a prompt triggers an eval pipeline. RAGAS scores are computed on a golden test set. Merge only if faithfulness ≥ 0.82 and answer_relevancy ≥ 0.72.
3. 3
   A/B shadow testing: New prompt gets 10% of traffic in shadow mode. Compare metrics vs current. Promote if better.
4. 4
   Instant rollback: Update SSM parameter to prior version hash. No redeploy required.

Traditional APM (Datadog, New Relic) tracks: latency, error rate, CPU, memory — all mechanical metrics. LLM observability adds a semantic layer: does the system say the right things?

• Traces: Full chain trace — input query → retrieval results → LLM prompt sent → response. LangSmith captures all of this per-run.
• Semantic metrics: Faithfulness, relevancy, hallucination rate — can only be measured by an LLM evaluator (judge model).
• Token-level cost attribution: Which component of your chain uses the most tokens? LangSmith shows cost breakdown per node.
• User feedback loops: Thumbs up/down signals feed back into your golden test set for future eval runs.

Model drift in LLMs shows up as: answer quality degradation (faithfulness drops), output format changes (model update broke JSON parsing), or latency shifts (new model version).

1. 1
   Golden test set regression: Run a versioned, representative test set on every deployment. Gate release using task-specific, statistically meaningful tolerances calibrated to business risk.
2. 2
   Embedding and traffic drift: Track query/topic distributions, retrieval success, score distributions, and labelled outcomes by version. Investigate material changes relative to calibrated baselines rather than one universal cosine threshold.
3. 3
   Knowledge freshness: For time-sensitive domains, add a "freshness" metadata filter. Prefer recently indexed documents. Surface "as of [date]" disclaimers in the response.

Problem: Full fine-tuning a 7B model updates all ~7 billion weights — requires ~112GB GPU RAM (FP16), making it infeasible without a cluster.

LoRA insight: The weight update matrix ΔW during fine-tuning has intrinsically low rank. Instead of updating W directly, decompose the update: ΔW = A × B, where A ∈ ℝ^d×r and B ∈ ℝ^r×k, with r ≪ min(d, k). Only A and B are trained. W stays frozen.

from peft import LoraConfig, get_peft_model, TaskType

config = LoraConfig(
    r=16,                              # rank
    lora_alpha=32,                     # scaling = alpha/r = 2
    target_modules=["q_proj", "v_proj"],  # attention layers
    lora_dropout=0.05,
    bias="none",
    task_type=TaskType.CAUSAL_LM
)
model = get_peft_model(base_model, config)
model.print_trainable_parameters()
# trainable: 4,194,304 / 6,738,415,616 total (0.062%)

QLoRA = Quantised LoRA. It quantises the base model to 4-bit NF4 (NormalFloat4) while keeping LoRA adapter weights in BF16. A 13B model at 4-bit takes ~6.5GB instead of ~26GB.

QLoRA also introduces double quantisation (quantise the quantisation constants) and paged optimisers (offload optimizer states to CPU RAM on memory spikes). These together enable fine-tuning a 65B model on a single A100 80GB.

RLHF (Reinforcement Learning from Human Feedback) trains a separate reward model from human preference pairs, then uses PPO to optimise the LLM against that reward model. Complex, unstable, requires large infra.

DPO (Direct Preference Optimisation) bypasses the explicit reward-model-plus-PPO pipeline. Given (prompt, chosen_response, rejected_response) pairs, it directly updates the model to prefer the chosen response. It is operationally simpler than classic RLHF, but quality and stability still depend on data, objective, hyperparameters, and evaluation.

1. 1
   Format: Use instruction-following format — {"instruction": "...", "input": "...", "output": "..."} (Alpaca format) or multi-turn chat format for conversational models.
2. 2
   Quality before scale: Start with a small, curated, representative dataset; measure the gain on a held-out eval set, inspect failures, then add targeted examples. Deduplicate and use calibrated human/model review rather than trusting one judge.
3. 3
   Diversity: Cover all intended use cases. Uneven distribution → model will overfit the majority class.
4. 4
   Contamination check: Ensure test set has no overlap with training data. Use exact and near-duplicate detection.

Chain-of-Thought (CoT) prompting encourages intermediate reasoning on multi-step tasks. It can improve performance, but production systems should not rely on exposing a model's private reasoning. Ask for a concise rationale, assumptions, calculations, citations, or verification artifacts that can be audited.

system = """You are a financial analyst. Before answering any question:
1. State the key facts given in the context.
2. Identify any missing information.
3. Show the calculations, citations, or checks needed to verify the result.
4. State the final answer and concise rationale clearly.

If you are uncertain, say so explicitly."""

Prompt engineering = crafting the instruction/template text. It's about what you say.

Context engineering = dynamically constructing the entire model input — which retrieved documents to include, how to summarise prior conversation, which tool outputs to pass, how to structure memory, and where to place instructions. It is the broader discipline of managing a model's available context budget intelligently; the exact window varies by model and provider.

• Primacy + recency: LLMs attend most to content at the very start and very end of the context. Place the most critical instructions in both positions.
• Structured delimiters: Use XML tags (<context>, <instructions>, <examples>) to cleanly separate sections — reduces instruction-following errors.
• Conversation compression: Summarise turns older than 10 with a cheap LLM. Keeps token cost bounded without losing thread.
• Lost in the middle: Long contexts suffer from "lost in the middle" — relevant info in the middle of a 100K context gets underweighted. Front-load the most important chunks.

1. 1
   Provider-native schema-constrained output: Prefer the current API's Structured Outputs / JSON Schema or typed tool-calling feature when supported. This constrains shape more strongly than plain JSON mode.
2. 2
   Application validation: Parse into Pydantic or an equivalent schema, enforce semantic/business constraints, reject unknown fields, and retry only bounded, repairable failures.
3. 3
   Fallbacks: Plain JSON mode guarantees syntax, not business correctness. Grammar/constrained-decoding libraries can help with self-hosted models, but still validate after generation.

from pydantic import BaseModel, Field
from langchain_anthropic import ChatAnthropic

class RiskAssessment(BaseModel):
    risk_level: str = Field(description="low | medium | high | critical")
    key_factors: list[str] = Field(description="Top 3 risk factors")
    recommendation: str

llm = ChatAnthropic(model="current_evaluated_model")
structured_llm = llm.with_structured_output(RiskAssessment)
result = structured_llm.invoke("Assess the credit risk for...")
# Then apply business validation and bounded error handling.

Prompt injection occurs when untrusted content influences model behavior against the application's intent. It cannot be solved reliably by one prompt, delimiter, classifier, or blocklist; design the surrounding system so a successful injection still cannot perform an unauthorized action.

• Separate instructions from untrusted data: mark provenance and prevent retrieved/user/tool content from becoming durable policy or memory without review.
• Deterministic authorization: the model may propose an action, but code validates identity, permission, arguments, data scope, and business rules.
• Least privilege and approvals: use scoped credentials, egress allowlists, read-only defaults, idempotency, and human confirmation for high-impact actions.
• Defense in depth: input/output classifiers and guardrails are useful signals, then add adversarial evals, logging, anomaly detection, kill switches, and incident response.

1. 1
   Ingestion: S3 PUT event → SQS → Lambda or container worker (parse, normalize, chunk, attach provenance) → an evaluated Bedrock embedding model → OpenSearch Serverless or the selected supported vector store. Pin model/version and plan re-indexing.
2. 2
   Query path: API Gateway → orchestrator → embed query → hybrid retrieval with tenant filters → evaluated reranker when it improves quality enough to justify latency/cost → top evidence into an evaluated Bedrock generation model → validate, cite, and stream.
3. 3
   Security: IAM roles per service (least privilege). Bedrock Guardrails for PII redaction. Row-level security in OpenSearch (users only see their org's documents). All queries logged to S3 for audit.
4. 4
   Monitoring: CloudWatch custom metrics for faithfulness, latency P95, token cost. Alarm on any metric breaching threshold.

Bedrock Knowledge Bases is AWS's managed RAG capability for connecting supported data sources, parsing/chunking content, creating or using supported vector stores, retrieving evidence, reranking where supported, and integrating retrieval with generation. Exact sources, stores, models, and features vary by region and configuration.

Rule of thumb: use Lambda for bounded, event-driven orchestration and transformation when its current quotas fit. Use ECS/Fargate or EKS for long-running agents, custom runtimes, connection-heavy streaming, background workers, or sustained workloads. Verify today's quotas and benchmark both.

Bedrock Guardrails is a managed safety layer that intercepts LLM inputs and outputs. It operates independently of the model — wraps any Bedrock-hosted model.

• Topic blocking: Define topics the model must not discuss (e.g., competitor products, investment advice). Guardrail intercepts and returns a pre-defined safe response.
• PII redaction: Automatically detects and redacts (or masks) PII in both input and output — names, SSNs, credit card numbers.
• Grounding check: Compares the generated response against the retrieved context. Flags responses that introduce facts not present in the context (hallucination detection).
• Word filters: Block specific words, phrases, or regex patterns in input/output.

Step Functions provides a managed, visual workflow orchestrator. For deterministic multi-step GenAI pipelines, it's a strong alternative to LangGraph — especially when you need:

• Built-in retry logic with exponential backoff on each step.
• Long-running workflows (days) — impossible with Lambda alone, natural with Step Functions.
• Human approval steps via waitForTaskToken — workflow pauses until a human approves, then resumes.
• Parallel fan-out via Map state — process 1000 documents in parallel, each calling a Lambda.

2026 positioning: AgentCore is the AWS platform layer for securely deploying and operating agents built with different frameworks and models. Discuss runtime isolation, enterprise tool/data connectivity, identity/access controls, tracing, debugging, and evaluation rather than treating an agent as only an LLM loop.

Guardrails can be applied consistently around model interactions to filter harmful content, protect sensitive information, assess grounding, and enforce use-case policies. Automated Reasoning checks can detect logical issues and unstated assumptions against formalized policies, but return findings in detect mode; your application decides whether to serve, revise, clarify, or escalate.

Also discuss sustainability and business impact: avoid unnecessary large-model calls, measure value, and retire low-value workloads.

1. I
   Ingest: Cloud Storage events → Pub/Sub/Eventarc → Cloud Run or Dataflow workers; use Document AI where layout/OCR matters. Make jobs idempotent and dead-letter failures.
2. R
   Retrieve: Choose Vertex AI RAG Engine for managed orchestration, Vector Search for high-scale ANN, or AlloyDB/pgvector when relational joins and transactions dominate. Store tenant and ACL metadata with every chunk.
3. G
   Generate: Call an evaluated Vertex AI model, enforce grounded citations and structured output, then validate before serving through Cloud Run/API Gateway.
4. O
   Operate: IAM service accounts, VPC Service Controls/Private Service Connect where applicable, CMEK, Cloud Logging/Monitoring/Trace, offline golden sets and sampled online evaluation.

Interview answer: start with compliance, integration, latency, portability and operating-model requirements; then choose. Do not select an agent platform merely because the workflow calls an LLM.

Cross-question: Prove the choice with corpus size, update rate, filter selectivity, recall@k, P95 latency, data residency, team skills and total cost.

Separate the latency-sensitive serving path from asynchronous ingestion/evaluation. Scale each independently and put Pub/Sub between bursty producers and workers.

• Managed endpoint: prefer when managed autoscaling, model lifecycle, monitoring and IAM integration outweigh runtime customization.
• Cloud Run/GKE: prefer for custom inference engines, unusual dependencies, portability or tight hardware control.
• Decision evidence: quality benchmark, tokens/sec, first-token latency, concurrency, accelerator utilization, availability, region, safety and cost per successful task.

Threat model: prompt injection, data exfiltration, poisoned retrieval, excessive agency, insecure tool arguments, cross-tenant leakage and model/vendor outages.

1. 1
   Publish immutable ingestion/evaluation events with schema version, tenant, correlation ID and idempotency key.
2. 2
   Use Dataflow when transformations are high-volume, streaming, windowed or need replay; use Cloud Run workers for simpler task queues.
3. 3
   Land sanitized traces and evaluation facts in BigQuery; partition by event date, cluster by tenant/model/version, and enforce retention/access policies.
4. 4
   Monitor backlog age, dead letters, duplicate rate, processing latency, quality drift and evaluation cost.

State your access patterns, consistency needs, region topology, transaction boundaries, retention and expected growth before naming a database.

• Build/deploy: Cloud Build → Artifact Registry → Cloud Deploy or controlled infrastructure pipeline; promote immutable application, prompt, model-policy and dataset versions.
• Pre-production gates: unit/contract/security tests plus golden-set quality, latency and cost thresholds; canary before full rollout.
• Runtime: Cloud Logging/Monitoring/Trace with correlation IDs across retrieval, model and tools. Alert on SLOs, quotas, safety, groundedness, tool failures and spend.
• Rollback: independently roll back prompt, model route, index alias and application version.

Senior answer: map capabilities, then re-evaluate IAM, networking, regional availability, quotas, reliability, operating skills and cost. A service-name translation is not an architecture migration.

HNSW (Hierarchical Navigable Small World) builds a multi-layer proximity graph. Higher layers have few nodes with long-range "highway" connections; lower layers get progressively denser with short-range connections — mimicking how road networks work (motorways → main roads → local streets).

Search: Starts at an entry point in the top layer, greedily walks toward the query vector, then descends to lower layers for precision. Gives O(log n) average search time with high recall.

Key HNSW parameters: ef_construction (build quality, more = slower build but better graph), M (connections per node, more = better recall but more memory), ef_search (search time recall trade-off).

Metadata filtering restricts ANN search to a subset of vectors matching a filter condition (e.g., doc_type == "earnings_report" AND date >= 2026-01-01).

Three approaches with different tradeoffs:

• Pre-filtering (filter then search): Narrow to matching documents first, then ANN search over that subset. High precision but if the subset is small, HNSW degrades toward brute force.
• Post-filtering (search then filter): Run ANN over full index, then discard non-matching results. Fast but can return fewer than k results if many are filtered out.
• ACORN / filtered HNSW: Modern approach — metadata stored alongside vectors in the graph. Filter-aware graph traversal. Best of both worlds. Used in Pinecone, Weaviate.

Storing a 1536-dim float32 embedding takes 6KB. For 10M documents that's 60GB. Quantisation compresses vectors to reduce memory at the cost of some recall accuracy.

Product Quantisation (PQ) splits the 1536-dim vector into M sub-vectors (e.g., M=64, each 24-dim). Each sub-vector is mapped to its nearest centroid in a codebook of 256 centroids. Result: 64 bytes instead of 6144 bytes — 96× compression. Distance computation uses a precomputed lookup table, keeping it fast.

Binary quantisation: Convert each float to a single bit (positive=1, negative=0). 32× compression. Works surprisingly well for high-dimensional embeddings with cosine similarity.

• Upsert by document ID: Every document has a stable ID. Reprocess and upsert when the document changes. All major vector DBs support upsert (Pinecone, OpenSearch, Qdrant).
• Chunk deletion on update: When a document is updated, delete all chunks with parent_doc_id == document.id, then re-ingest. Track chunk-to-document mapping in a separate metadata store (DynamoDB/RDS).
• Event-driven ingestion: S3 Object Lambda or DynamoDB Streams → SQS → Lambda ingestion pipeline. Near-real-time index updates without polling.
• Versioned indexes: For zero-downtime updates on large corpora, build the new index alongside the old one, then do an atomic alias swap (OpenSearch index aliases).

1. I
   Ingestion: S3 → SQS (decouple) → Lambda fleet (parse PDF/DOCX/XLSX, hierarchical chunk: parent 1024t / child 256t, 50t overlap) → an evaluated Bedrock embedding model → OpenSearch Serverless (kNN + BM25 fields). Metadata: doc_type, entity_id, created_at, source. Row-level security by entity_id.
2. D
   Data model: OpenSearch index with both embedding: knn_vector(dimension) and content: text (for BM25). Store the evaluated embedding dimension and model version in the index schema. Separate metadata fields as keyword type. DynamoDB tracks chunk-to-document mapping for updates/deletions.
3. E
   Retrieval: Hybrid BM25 + kNN with evaluated fusion → an evaluated reranker when useful → evidence budget sent to the generation model. Add a version-aware semantic cache only after measuring correctness, staleness, latency, and hit rate.
4. G
   Generation: An evaluated Bedrock reasoning/generation model. System prompt enforces: cite source for every claim, flag if answer not in context. Bedrock Guardrails for PII + topic blocking. Response streaming via Lambda Response Streaming.
5. Ev
   Evaluation: versioned offline set plus risk-based production sampling. Calibrate retrieval, groundedness, task success, safety, latency, and cost gates against human review and business impact; do not present generic RAGAS thresholds as universal.
6. M
   Monitoring: CloudWatch: latency P95 < 1.5s, error rate < 0.5%, cost per query. LangSmith: full trace per request. X-Ray for distributed tracing across Lambda chains.
7. S
   Security: IAM roles per service. Bedrock Guardrails PII redaction. Entity-level index partitioning (user A cannot retrieve user B's documents). All queries audit-logged to S3.

1. 1
   Architecture — Supervisor pattern in LangGraph: IntentClassifier node (routes query type) → either KnowledgeAgent (RAG over support docs), ActionAgent (CRM/order system APIs), or EscalationAgent (human handoff).
2. 2
   Intent classification: An evaluated low-latency model tier classifies intent: information_request | account_action | complaint | escalation. Select it against an intent test set and explicit latency/cost SLO rather than relying on a model-name assumption.
3. 3
   Escalation triggers: (a) User explicitly asks for human, (b) agent confidence < threshold for 2 turns, (c) complaint category detected, (d) max turns (10) reached. LangGraph uses interrupt_before at escalation node.
4. 4
   Context handoff: Full conversation summary + entity extraction (customer ID, issue category, sentiment score) passed to human agent dashboard via Amazon Connect + DynamoDB.
5. 5
   Memory: Short-term in LangGraph state. Long-term in DynamoDB keyed by customer_id (preferences, past issues) — injected as context on next session.

1. 1
   Data collection: Risk-based, privacy-reviewed production sampling to an asynchronous evaluation queue. Oversample rare, high-impact, low-confidence, and newly changed slices.
2. 2
   Judge layer: Use deterministic checks where possible and one or more evaluated judge models for rubric-based criteria. Calibrate judges against blinded human labels, monitor agreement/bias, and version judge prompts/models.
3. 3
   Aggregation: Daily Lambda aggregates scores → writes to RDS → visualised in Grafana dashboard.
4. 4
   CI gate: Every code, prompt, model, retriever, or policy change triggers a representative regression suite. Fail or require review when calibrated quality/safety tolerances or SLOs are breached.
5. 5
   Feedback loop: Low-scoring samples surfaced to human reviewers → added to golden test set → improves future evals.

1. C
   Capacity: derive concurrent streams from QPS × average duration; size connection pools and rate limits against provider quotas, not only CPU.
2. S
   Security: per-tenant keys/policies, secret isolation, egress allowlists, audit trail and prompt/response retention controls.
3. X
   Cross-question answers: prevent duplicate billable calls with an invocation ledger, idempotency key and explicit handling of ambiguous timeouts. Route fallback only to providers that satisfy the required schema/tool capability contract, then validate output. Test residency with policy-as-code, regional routing tests, blocked cross-region egress, and audit-log evidence.

1. 1
   Control plane: agent definitions, prompt/model/tool versions, policy, evaluations, rollout and audit.
2. 2
   Data plane: isolated runtime executes a bounded state machine; tool gateway authenticates, authorizes, validates arguments and records effects.
3. 3
   Memory: separate immutable event history, short-term working state and curated long-term memory with consent, expiry and deletion.
4. 4
   Safety: risk-tier tools; read-only may auto-run, money/data mutations require deterministic checks and human approval. Never trust model text as authorization.
5. 5
   Operate: trace every reasoning-independent event, tool call, policy decision and approval; cap steps/tokens/time and provide kill switches.

API/data model: POST /documents, GET /jobs/{id}, webhook completion; Document, Page, Element, Extraction, Evidence, ReviewDecision and ModelVersion.

1. P
   Path: WebRTC/media gateway → streaming ASR → dialogue/agent runtime → tools/RAG → streaming TTS. Keep regional session state and a durable event summary.
2. L
   Latency: budget each stage; stream partial transcripts and speech; use VAD and speculative work carefully. Measure time-to-first-audio and interruption-stop latency.
3. B
   Barge-in: cancel TTS and downstream work, advance the turn epoch, and reject late results from the old epoch.
4. R
   Reliability: reconnect token, session checkpoint, provider fallback, bounded silence/timeouts and graceful transfer to human.

Cross-question: How do you prevent a partially heard confirmation from triggering a payment? Require explicit deterministic confirmation before high-impact tools.

• Router inputs: task type, complexity, modality, context size, tenant policy, region, safety tier, live health, measured quality, latency and cost.
• Policy: deterministic hard constraints first; learned or rules-based ranking second; fallback must preserve schema/tool capability and safety.
• Cache: key includes normalized intent plus tenant, policy, prompt, model family, knowledge/index version and safety context. Never share across authorization boundaries.
• Evaluate: counterfactual shadow traffic, quality-regret, cache precision, hit rate, cost per accepted task and tail latency.

Key principle: the model proposes a tool call; deterministic systems decide whether and how it executes. Treat tool output as untrusted input before returning it to an agent.

class ModelProvider(Protocol):
    async def generate(self, req: GenerationRequest) -> GenerationResult: ...
    async def stream(self, req: GenerationRequest) -> AsyncIterator[TokenEvent]: ...

class Gateway:
    def __init__(self, router, providers, policies, telemetry): ...
    async def generate(self, req):
        checked = self.policies.validate(req)
        route = self.router.choose(checked)
        return await self.providers[route.provider].generate(route.request)

Use canonical request/result types and provider adapters. Keep routing, retry, safety, telemetry and provider calls separate. Preserve provider-specific capabilities through an explicit capability contract rather than leaking arbitrary dictionaries everywhere.

Cross-question answers: Record each invocation ID and outcome so an ambiguous timeout is reconciled before retry. Surface streaming failures as typed terminal events while preserving already emitted tokens and trace IDs. Test adapters with provider contract tests, deterministic fake providers, recorded fixtures and a small gated live integration suite.

Document(id, tenant_id, source_uri, content_hash, version)
IngestionJob(id, document_id, version, state, attempt, lease_until)
Chunk(id, document_id, version, ordinal, text_hash, metadata)

RECEIVED -> PARSED -> CHUNKED -> EMBEDDED -> INDEXED -> ACTIVE
                         \-> FAILED_RETRYABLE | FAILED_FINAL

• Use (tenant_id, source_uri, content_hash) or an explicit idempotency key to deduplicate.
• Workers claim jobs with leases; every transition uses compare-and-set. Retries resume from durable artifacts.
• Build a new document version, verify counts/quality, atomically switch active version, then garbage-collect old chunks.

ToolSpec(name, version, input_schema, required_scopes, risk_tier, timeout)
Invocation(id, actor, agent, tool, args_hash, status, effect_receipt)

execute(invocation):
  authenticate -> authorize -> schema_validate -> policy_check
  -> approve_if_required -> run_isolated -> validate_output -> audit

Use Registry/Repository for discovery, Command for invocations, Policy object for authorization, and an idempotency store for mutations. The executor receives short-lived scoped credentials; the LLM never receives a reusable secret.

Use optimistic concurrency on sequence/epoch. Summaries are derived views, never the sole source of truth. Support deletion and retention across events, embeddings, caches and analytics copies.

• Rate limit: hierarchical token buckets for tenant, model/provider and global capacity; account for requests and estimated tokens.
• Retry: only retry transient errors within the request deadline; exponential backoff with jitter; honor provider retry hints.
• Circuit breaker: CLOSED → OPEN after threshold → HALF_OPEN probes → CLOSED on recovery. Scope by provider/region/model capability.
• Correctness: attach invocation IDs and record outcomes so a timeout does not automatically become a duplicate billable/action call.

class Evaluator(Protocol):
    name: str
    async def score(self, case: EvalCase, output: Output) -> Score: ...

EvalCase(id, input, expected, rubric, tags, dataset_version)
Run(id, system_version, dataset_version, seed, status)
Score(metric, value, rationale, evaluator_version, cost)

Support deterministic checks, retrieval metrics, human rubrics and model judges behind one interface. Run asynchronously with bounded concurrency; persist every version and raw artifact. Compare paired cases and confidence intervals, not only averages.

Two-stage lookup: exact canonical key first; semantic ANN lookup second. A candidate is reusable only if similarity passes an evaluated threshold and all hard dimensions match: tenant/ACL, locale, policy, prompt version, model capability, knowledge/index version and tool-state class.

• Store answer, evidence, creation/expiry, safety decision and provenance; encrypt and enforce tenant boundaries.
• Invalidate by version bump or event; use short TTL for volatile facts and never cache sensitive/high-impact actions by default.
• Measure cache precision with sampled replay, not just hit rate. A false hit can be more expensive than a miss.

POST /v1/conversations/{id}/messages
Headers: Idempotency-Key, Last-Event-ID
Response: text/event-stream
events: accepted, retrieval, token, citation, completed | failed

cancel_event set -> stop provider stream -> persist terminal status
client disconnect -> bounded cleanup; do not leak provider connections

What interviewer checks: async iteration and backpressure, cancellation, timeout budgets, idempotency, ordered event persistence, reconnect/resume, dependency injection, validation and tests for disconnect/error races.

Given an integer array and a target, return indices of the two numbers that add up to target. You may not use the same element twice.

Key insight: For each element n, we need target - n. Store each value's index in a hash map. On each step, check if the complement is already in the map.

def two_sum(nums: list[int], target: int) -> list[int]:
    seen = {}  # value → index
    for i, n in enumerate(nums):
        diff = target - n
        if diff in seen:
            return [seen[diff], i]
        seen[n] = i
    return []

# Example: two_sum([2,7,11,15], 9) → [0, 1]

Find the length of the longest sequence of consecutive integers. Must run in O(n) time.

Key insight: For each number, only start counting if it's the beginning of a sequence (n-1 is not in the set). This ensures each number is visited at most twice — O(n) overall.

def longest_consecutive(nums: list[int]) -> int:
    num_set = set(nums)
    best = 0
    for n in num_set:
        if n - 1 not in num_set:   # sequence start
            cur, length = n, 1
            while cur + 1 in num_set:
                cur += 1; length += 1
            best = max(best, length)
    return best

# [100,4,200,1,3,2] → 4  (sequence 1,2,3,4)

Group strings that are anagrams of each other into sublists.

from collections import defaultdict

def group_anagrams(strs: list[str]) -> list[list[str]]:
    groups = defaultdict(list)
    for s in strs:
        key = tuple(sorted(s))    # e.g. 'eat' → ('a','e','t')
        groups[key].append(s)
    return list(groups.values())

For each index i, compute the product of all elements except nums[i]. O(n) time, no division operator.

Insight: result[i] = prefix_product[i-1] * suffix_product[i+1]. Do two passes: left prefix in one array, multiply by right suffix on the fly.

def product_except_self(nums: list[int]) -> list[int]:
    n = len(nums)
    res = [1] * n
    # Left pass: res[i] = product of nums[0..i-1]
    prefix = 1
    for i in range(n):
        res[i] = prefix
        prefix *= nums[i]
    # Right pass: multiply by product of nums[i+1..n-1]
    suffix = 1
    for i in range(n - 1, -1, -1):
        res[i] *= suffix
        suffix *= nums[i]
    return res

Return the k most frequent elements. O(n) solution using bucket sort.

from collections import Counter

def top_k_frequent(nums: list[int], k: int) -> list[int]:
    freq = Counter(nums)
    # Bucket index = frequency value
    buckets = [[] for _ in range(len(nums) + 1)]
    for val, cnt in freq.items():
        buckets[cnt].append(val)

    res = []
    for i in range(len(buckets) - 1, -1, -1):
        for val in buckets[i]:
            res.append(val)
            if len(res) == k: return res

Find the minimum window in string s that contains all characters of string t.

from collections import Counter

def min_window(s: str, t: str) -> str:
    need = Counter(t)
    window = {}
    have, total = 0, len(need)
    best = (float("inf"), 0, 0)
    left = 0
    for right, ch in enumerate(s):
        window[ch] = window.get(ch, 0) + 1
        if ch in need and window[ch] == need[ch]:
            have += 1
        while have == total:
            if (right - left + 1) < best[0]:
                best = (right - left + 1, left, right)
            window[s[left]] -= 1
            if s[left] in need and window[s[left]] < need[s[left]]:
                have -= 1
            left += 1
    l, r = best[1], best[2]
    return s[l:r+1] if best[0] != float("inf") else ""

Given n courses and prerequisites, determine if you can finish all courses. Equivalent to detecting a cycle in a directed graph.

def can_finish(n: int, prereqs: list[list[int]]) -> bool:
    adj = [[] for _ in range(n)]
    for a, b in prereqs: adj[b].append(a)

    # 0=unvisited, 1=in-stack (cycle), 2=done
    state = [0] * n

    def dfs(node):
        if state[node] == 1: return False  # cycle
        if state[node] == 2: return True   # already processed
        state[node] = 1
        for nei in adj[node]:
            if not dfs(nei): return False
        state[node] = 2
        return True

    return all(dfs(i) for i in range(n) if state[i] == 0)

def climb_stairs(n: int) -> int:
    if n <= 2: return n
    a, b = 1, 2
    for _ in range(3, n + 1):
        a, b = b, a + b  # rolling Fibonacci
    return b

Pattern recognition: Whenever f(n) = f(n-1) + f(n-2) or similar recurrence appears, recognise it as Fibonacci DP. Roll two variables instead of an array for O(1) space.

Directly used in diff algorithms, tokenisation comparison, and DNA sequence alignment.

def lcs(text1: str, text2: str) -> int:
    m, n = len(text1), len(text2)
    dp = [[0] * (n + 1) for _ in range(m + 1)]
    for i in range(1, m + 1):
        for j in range(1, n + 1):
            if text1[i-1] == text2[j-1]:
                dp[i][j] = dp[i-1][j-1] + 1
            else:
                dp[i][j] = max(dp[i-1][j], dp[i][j-1])
    return dp[m][n]

def knapsack(weights: list, values: list, W: int) -> int:
    n = len(weights)
    dp = [0] * (W + 1)
    for i in range(n):
        for w in range(W, weights[i] - 1, -1):  # reverse!
            dp[w] = max(dp[w], dp[w - weights[i]] + values[i])
    return dp[W]

Key: Iterate weights in reverse when using 1D DP (ensures each item is used at most once). Forward iteration = unbounded knapsack (items can repeat).

Determine if string s can be segmented using words from a dictionary. Directly related to LLM tokenisation problems.

def word_break(s: str, words: list[str]) -> bool:
    word_set = set(words)
    dp = [False] * (len(s) + 1)
    dp[0] = True  # empty string is breakable
    for i in range(1, len(s) + 1):
        for j in range(i):
            if dp[j] and s[j:i] in word_set:
                dp[i] = True; break
    return dp[len(s)]