3‑Minute Spoken Pitch (English — ready to say)

"Hi, I’m [Your Name], an AI Engineer with 3 years of experience building production‑grade LLM and agentic systems. I focus on translating high‑level business needs into reliable, maintainable AI services — from data pipelines and vector search to multi‑agent orchestration and CI/CD. I have hands‑on experience with LangChain, LlamaIndex, containerised deployments and observability tooling like LangFuse and Prometheus. I care deeply about model traceability, reproducibility and practical safeguards against hallucinations and bias.

In my recent roles I led end‑to‑end projects: scoping requirements with stakeholders, selecting architectures that balance latency, cost and reliability, and shipping systems that include monitoring, automated tests and clear rollback plans. I enjoy prototyping new approaches, running rigorous A/B experiments and operationalising successful patterns.

I’m excited about DEUS because you combine engineering rigour with human‑centered design and ethical AI — exactly how I like to work. If I join, I’ll bring technical leadership, a pragmatic approach to risk and a passion for turning ambiguous problems into clear, testable solutions. Thank you."

---

Three 1‑Minute Project Descriptions (English)

Note: each description targets 1 minute spoken length. Use concise, confident tone.

1) Connells — Conversational Property Assistant

• Problem
  • Large property chain received thousands of customer enquiries across chat and email. Agents were answering inconsistently, leading to missed leads and low NPS.
• Architecture
  • User interface → API gateway → multi‑agent orchestration (intent classifier agent, retrieval RAG agent, business rules agent) → vector DB + knowledge connectors → CRM integration and audit log.
• Stack
  • LLMs via OpenAI and local Llama family for PII‑sensitive flows, LangChain for orchestration, Pinecone for vectors, FastAPI + Kubernetes, GitHub Actions for CI/CD, LangFuse for traceability.
• Challenges
  • Ensuring SLA for responses (<300ms for cached answers), preventing hallucinations on legal/property details, synchronising state with CRM, and privacy handling of personal data.
• Result
  • 40% faster first response time, 25% increase in qualified leads, and a 60% reduction in repetitive agent tickets. Traceability logs enabled easy audits and A/B testing of prompts.

2) Insparya — Clinical Document Triage & Summarisation

• Problem
  • Clinical teams faced backlog of referral documents and needed accurate triage and summarisation to prioritise patients quickly.
• Architecture
  • Upload ingestion → OCR + text cleaning → document embedding pipeline → RAG summarisation + structured extraction agent → UI for clinicians + secure EHR integration.
• Stack
  • Python pipelines, LangChain/LlamaIndex, HuggingFace models for extraction, AWS S3 + Lambda for ingestion, Snowflake for metadata, Terraform for infra, LangSmith for traces.
• Challenges
  • High accuracy requirements, strict data governance (patient PII), deterministic extraction of critical fields, and low false negatives for urgent cases.
• Result
  • Reduced triage time by ~70%, improved prioritisation accuracy, and clinicians reported higher confidence due to traceable provenance and extracted evidence snippets.

3) Recommender — Personalized Product Recommendations (Hybrid)

• Problem
  • A retail client needed real‑time, explainable product recommendations that combined collaborative signals with product knowledge and promotional rules.
• Architecture
  • Event stream → feature store → candidate generation (collab filtering + content) → re‑ranking via LLM‑based contextual scorer (RAG for product copy) → API → frontend.
• Stack
  • Kafka, Redis, Snowflake feature store, Faiss/HNSW for similarity, PyTorch for models, LangChain for contextual re‑ranking, Docker + Kubernetes for serving.
• Challenges
  • Balancing latency (real‑time serving), freshness of features, blending machine and business rules, and providing human‑readable reasons for recommendations.
• Result
  • Lifted CTR by 15%, AOV by 7%, and provided on‑page explainability which increased conversion and reduced returns.

---

What is RAG? (30s answers)

• English (30s spoken): "RAG — Retrieval Augmented Generation — is a pattern that combines a retrieval step with a generative model. Instead of asking the model to answer solely from its weights, we fetch relevant documents or embeddings from a vector store or knowledge base, provide them as context to the LLM, and then generate an answer grounded in those documents. This reduces hallucinations, enables up‑to‑date knowledge, and supports traceability."

• Portuguese (30s spoken): "RAG — Recuperação Aumentada por Geração — é um padrão que junta um passo de recuperação de documentos com um modelo generativo. Em vez de confiar apenas no que o modelo 'sabe', buscamos documentos relevantes numa base de conhecimento (vetorial ou tradicional), damos esse contexto ao LLM e geramos uma resposta fundamentada nesses documentos. Ajuda a reduzir alucinações e permite rastreabilidade e atualidade das respostas."

---

Senior Answer — How to avoid hallucinations? (short)

Practical senior approach:

• Use RAG: ground outputs with retrieved evidence and include provenance pointers.
• Constrain generation: use system prompts, structured output schemas and function calls so the model must adhere to formats.
• Ensemble checks: cross‑validate answers with smaller deterministic extractors or rule engines.
• Verification pipelines: run secondary verification LLM that judges factuality with the same context.
• Monitoring & feedback: instrument factuality metrics (using LangFuse/LangSmith) and roll out guardrail updates; add human‑in‑the‑loop for high‑risk flows.
• Fail safe: if confidence is low, respond with "I don’t know" or route to human support.

---

3–4 Impact Phrases (Impressives — ready to say)

1. "I ship with observability first: if you can’t measure it, you can’t iterate it."
2. "I design models for risk profiles — not for maximum score on a benchmark."
3. "Production reliability beats novel architectures when the business depends on consistent outcomes."
4. "I treat prompt engineering like software engineering: versioned, tested and monitored."

---

3–4 Questions to Ask the Interviewer (ready)

1. "What are the key business metrics you expect this role to influence in the first 6–12 months?"
2. "How do you currently balance rapid experimentation with production stability and governance?"
3. "What are the most common sources of friction between product, data and engineering teams here?"
4. "Can you describe a recent technical decision where ethical considerations changed the design?"

---

Three STAR Stories (ready to narrate)

STAR 1 — Reduce Costs (S/T, A, R)

• Situation/Task: A client’s LLM inference bill had tripled after deploying a full‑context RAG service.
• Action: I profiled latency and token usage, introduced a two‑tier retrieval cache, implemented short‑context distilled model for low‑risk queries, and added dynamic temperature/response length controls by intent type.
• Result: Reduced monthly inference cost by 45% while keeping latency & user satisfaction within SLAs. Results validated with A/B test.

STAR 2 — Production Incident (S/T, A, R)

• Situation/Task: During a Black Friday peak, the recommendation service experienced timeouts and stale embeddings due to a failed reindex job.
• Action: I led the incident response: implemented circuit breaker for the re‑ranker, switched to fallback cached re‑rank service, added automated alerts for reindex failures and created an emergency roll‑forward reindex with partial updates.
• Result: Downtime under 12 minutes, no revenue loss measured, and we shipped post‑mortem actions that prevented recurrence; SLA penalties were avoided.

STAR 3 — Managing Stakeholders (S/T, A, R)

• Situation/Task: Multiple stakeholders (product, legal, clinicians) had conflicting priorities for a clinical summarisation product.
• Action: I organised a cross‑functional workshop, proposed a prioritisation matrix based on clinical risk and user value, established a phased delivery (MVP with human‑in‑loop then automation), and set up weekly demos and success metrics.
• Result: Alignment on roadmap, faster decision making, and successful rollout of phase 1 with stakeholder buy‑in and clear escalation paths.

---

One‑pager System Design (Whiteboard) — RAG + Multi‑Agent (High Level)

Goal: Sketch an architecture you can draw in 3–5 minutes on the whiteboard.

1. Actors & Clients

   • Users, Frontend, Internal services, Admin console

2. Ingestion & Storage

   • Connectors: S3 / DB / APIs → ETL pipeline (cleaning, OCR) → Document store (raw) + Vector DB (embeddings)
   • Metadata store (Snowflake / Postgres)

3. Retrieval Layer

   • Embedding service (batch + realtime), Vector DB (HNSW/IVF), ANN API
   • Traditional index search fallback (Elasticsearch)

4. Orchestration & Agents

   • Agent Manager (LangGraph / custom controller) orchestrates multiple agents:
     • Intent classifier agent
     • Retriever agent (RAG)
     • Business rules / validation agent
     • Synthesiser / response generator agent
     • Safety & compliance agent (PII scrubbing, hallucination detector)
   • Agents communicate via messages (Kafka / Redis streams) or synchronous calls depending on latency needs.

5. LLM Serving

   • LLM endpoints (OpenAI + self‑hosted LlamaX), model pool with selector (cost/latency/privacy)
   • Prompt templates, function‑call handlers, structured output schemas

6. API & UI

   • FastAPI / GraphQL frontend, caching layer (Redis), auth + RBAC

7. Observability & Governance

   • Logging, traces (LangFuse/LangSmith), metrics (Prometheus/Grafana), alerts
   • Model catalog, version control, CI/CD for prompts and pipelines, audit logs

8. Deployment

   • Kubernetes + Helm, Terraform infra as code, GitOps, Canary rollouts, automated tests

Key tradeoffs to discuss on whiteboard:

• Freshness vs cost (reindex cadence)
• Latency vs grounding (how much context to pass)
• Privacy (self‑host vs external API)
• Consistency vs autonomy of agents

---

Cheatsheet — Quick Technical Reference

RAG types:

• Sparse retrieval + LM (BM25/ElasticSearch) — cheap, interpretable.
• Dense retrieval (embeddings + ANN) — semantic matching, flexible.
• Hybrid retrieval — combine sparse + dense for best recall.
• Closed‑book + RAG fallback — use LM first, if unsure use retrieval.

Agents (ReAct / agentic patterns):

• ReAct pattern: interleave Reasoning (internal chain of thought) + Actions (tool calls). Good for tool use and stepwise tasks.
• Architectures: single agent with tools vs multi‑agent (specialised roles). Multi‑agent simpler to test/assign responsibilities.
• Safeguards: timeouts, budget caps, action whitelists, audit trails.

LLM parameters (quick):

• temperature: controls randomness (0.0 deterministic — 1.0 creative). For production factual tasks use 0–0.3.
• top_p (nucleus): sample within cumulative probability p. Combine with temperature; lower p narrows output.
• max_tokens / response_length: limit cost/latency.
• context window: max tokens for prompt + response. Use retrieval + summarisation when context exceeds window.
• best_of / n: multiple samples; increases cost and latency.

Vector DB quick compare — HNSW vs IVF

• HNSW (Hierarchical Navigable Small World)
  • Fast, high recall, good for dynamic inserts, single‑node memory heavy.
  • Good for production low‑latency nearest neighbours.
• IVF (Inverted File + PQ)
  • Scales to huge datasets with quantisation (lower memory), better for disk/large scale but may need offline training and reindexing.
  • Potentially lower recall unless well tuned.

When to use which:

• Small–medium dataset, frequent updates -> HNSW.
• Very large scale (100M+ vectors) and tight memory budget -> IVF + PQ hybrid.

---

Live‑coding Exercises — Ready‑to‑explain Code

Note: All examples are Python 3, minimal dependencies. Explain tradeoffs while coding.

1) Chunking text for embeddings

# chunk_text.py
from typing import List

def chunk_text(text: str, chunk_size: int = 512, overlap: int = 64) -> List[str]:
    """Simple whitespace chunker that preserves word boundaries.
    chunk_size and overlap in number of tokens (approx using words as proxy).
    """
    words = text.split()
    if chunk_size <= overlap:
        raise ValueError("chunk_size must be greater than overlap")

    chunks = []
    start = 0
    n = len(words)
    while start < n:
        end = min(start + chunk_size, n)
        chunk = " ".join(words[start:end])
        chunks.append(chunk)
        if end == n:
            break
        start = end - overlap
    return chunks

# Example
if __name__ == '__main__':
    text = """This is a long document ... (imagine many words)"""
    print(chunk_text(text, chunk_size=100, overlap=20))

Talking points: token vs word approximation; better to use tokenizer (tiktoken) for exact token counts; choose overlap to preserve context for embeddings.

2) Retry with exponential backoff and jitter

# retry_backoff.py
import time
import random
from typing import Callable

class RetryError(Exception):
    pass

def retry_with_backoff(fn: Callable, max_attempts: int = 5, base_delay: float = 0.5, max_delay: float = 10.0):
    """Retries a function with exponential backoff and jitter.
    fn should raise exceptions on failure.
    """
    attempt = 0
    while attempt < max_attempts:
        try:
            return fn()
        except Exception as e:
            attempt += 1
            if attempt >= max_attempts:
                raise RetryError(f"Max attempts reached: {e}") from e
            # exponential backoff with full jitter
            delay = min(max_delay, base_delay * (2 ** (attempt - 1)))
            sleep = random.uniform(0, delay)
            time.sleep(sleep)

# Example usage
if __name__ == '__main__':
    import requests

    def flaky_call():
        r = requests.get('https://httpbin.org/status/503')
        r.raise_for_status()
        return r.text

    try:
        result = retry_with_backoff(flaky_call, max_attempts=4)
    except Exception as e:
        print('Failed after retries:', e)

Talking points: full jitter reduces thundering herd; consider idempotency; handle specific transient exceptions only; integrate with async frameworks.

3) Parse JSON with fallback and validation

# parse_json_fallback.py
import json
from typing import Any, Dict

SCHEMA_KEYS = {'id', 'title', 'summary'}

class ParseError(Exception):
    pass

def parse_json_with_fallback(text: str) -> Dict[str, Any]:
    """Attempt strict parse; if fails, try to extract JSON block heuristically and validate schema.
    """
    try:
        obj = json.loads(text)
        if validate_schema(obj):
            return obj
        raise ParseError('Schema validation failed')
    except Exception:
        # Fallback: try to find first {...} block
        start = text.find('{')
        end = text.rfind('}')
        if start == -1 or end == -1 or end <= start:
            raise ParseError('No JSON block found')
        candidate = text[start:end+1]
        try:
            obj = json.loads(candidate)
            if validate_schema(obj):
                return obj
        except Exception:
            pass
    raise ParseError('Unable to parse valid JSON')

def validate_schema(obj: Dict[str, Any]) -> bool:
    return isinstance(obj, dict) and SCHEMA_KEYS.issubset(set(obj.keys()))

# Example
if __name__ == '__main__':
    bad_text = 'Response:\nSome explanation\n{"id": 1, "title": "X", "summary": "Y"}\nThanks'
    print(parse_json_with_fallback(bad_text))

Talking points: prefer function calls or structured outputs where LLM returns JSON via function calling; always validate schema and handle missing keys; add safety for malicious content.

---

Final Interview Preparation Checklist

• Tech & Environment

  • Laptop fully charged, charger nearby
  • Camera at eye level, ring light / good daylight
  • Microphone or headset tested (Mic levels, background noise)
  • Stable internet (have phone hotspot as backup)

• Personal & Content

  • 3‑minute pitch rehearsed (timing ~3 minutes)
  • Project descriptions (Connells, Insparya, Recommender) rehearsed (~1 min each)
  • STAR stories practised (concise: 60–90s each)
  • Impact phrases memorised (use 1–2 naturally)

• Coding & Tools

  • Code editor open with sample scripts and required packages installed
  • Python venv activated and linting/tests runnable
  • Explain tradeoffs & complexity for whiteboard system design

• Logistics & Questions

  • 3–4 questions to ask interviewer ready
  • Note about accommodations (if needed) prepared
  • Minutes buffer: start call 5 minutes early to avoid issues

Good luck — and if you want, I can tailor the pitch with your name and specific metrics, or convert the pitch and project descriptions into audio for practice.