Tech Check 14 August — Question Navigation

Fast links into the study notes, one entry per question the client actually listed, plus the topics the prep doc marks [M] (must discuss in depth). Tick the box once you can answer it out loud in 60–120 seconds.

The bold path under each item is the primary note; the rest are related. Links are relative to this file.

The call itself: The call itself — everything except the answers is the opening, the 90-second self-intro, handling follow-ups and closing — everything that is not a technical answer.

Say it out loud: Answers — say these out loud is the one-page script — every question below with the answer written the way you would speak it, each one inside the 60-90 second budget. Read that on the morning; use this page to go deeper on anything that feels thin.

Context: Tech Check Prep — Senior Backend + Applied AI (FinTech, Part-Time) is the prep plan and the answer skeletons. The raw client brief and the hiring feedback live in description.txt, which stays local and is not published.

The question list was written from the last rejection. The AI-depth questions below are the pass/fail gates, not warm-ups.

The client’s list, in their words

Their message names these. The six below the fold are the gates; this one is the opener and it has no single note — it is your narrative.

• “LLMs: experience” — production systems, not demos
  • How would you describe your strongest project, and what questions would you expect about it? — the shape to tell it in
  • How exactly do you apply AI in your work?
  • Cover: which models and why, what scale, what it cost, what broke and how you found out. The last clause is the one that reads as production experience.

The gates — what the last candidate failed on

These six map one-to-one onto the previous rejection. Do these first.

• Fine-tuning vs RAG — the framing, not the feature list
  • Fine-Tuning vs RAG vs Prompt Engineering
  • What is RAG? — has the “has long context replaced RAG” answer too
  • Supervised fine-tuning and instruction tuning
• LLM call vs agent — who owns control flow
  • What is an agent
  • The agent loop — the loop you should be able to write from memory
  • LangChain and LangGraph — StateGraph, checkpointers, recursion limits
  • Agent failure modes — max-steps, loop detection
  • Multi-agent patterns — supervisor topology, and why five agents at 90% is 59% end to end
  • The agent framework landscape — CrewAI, Agents SDK, ADK. Correction to §4.3 of the prep doc: AutoGen and Semantic Kernel merged into Microsoft Agent Framework (GA April 2026) — naming them as separate live projects dates you
• How do you estimate the result from an LLM — evaluation
  • Building eval sets
  • Why evaluating LLM systems is hard
  • LLM as judge — name the biases: position, verbosity, self-preference
  • Agentic RAG and evaluating retrieval — recall@k, MRR, faithfulness
  • Online evaluation and experiments — production signals, ablation, CI gating
  • The eval and observability tooling — RAGAS’s four metrics, Langfuse, DeepEval, promptfoo. §4.3 marks RAGAS [M]; this is where the names live
• Observability — trace and span level, not endpoint level
  • LLM observability
  • OpenTelemetry — the vendor-neutral export path
  • Sentry — errors, and why PII scrubbing matters here
• Hallucinations — what to do, how to decrease
  • Hallucinations, Function Calling, and Tool Use
  • Guardrails and output validation
  • Hybrid search and reranking — grounding is a retrieval problem first
• What models for what tasks — routing
  • Which model for which task
  • Model-provider abstraction and LLM resilience — routing vs fallback
  • LLM inference fundamentals — why output costs more than input

RAG — the core of the role

• RAG end to end — ingest, chunk, embed, retrieve, rerank, generate, evaluate
  • What is RAG?
  • RAG Architecture Patterns — naive, advanced, modular, agentic
• Chunking — fixed, recursive, semantic, parent-document
  • Chunking Strategies and Retrieval Techniques
  • Structured Document Pipelines — Parsing, Tables, OCR, Extraction — PDFs, tables, OCR
• Embeddings — dimensions, normalisation, the re-embed trap
  • What are embeddings?
• Hybrid search, RRF, reranking — the biggest single retrieval win
  • Hybrid search and reranking
• pgvector — your own stack; HNSW vs IVFFlat, ef_search, filtered ANN
  • pgvector in production
  • Vector Databases — the wider landscape
• Context management — why more context is not better
  • Context engineering
  • Memory Strategies for LLM Conversations and Agents

Agents and structured output

• Function / tool calling, JSON schema, typed output
  • Function Calling, Tool Use, and Structured Output
  • LLM JSON Validation — Common Interview Questions and Answers
  • Pydantic AI — typed agent framework
• Human-in-the-loop, durable runs, checkpointing
  • Durable execution and human-in-the-loop
• MCP — worth a sentence if agents come up
  • Model Context Protocol — fundamentals

Prompting and cost

• Prompt design — and why prompt engineering comes before RAG
  • Prompt Engineering
• The chat API — roles, statelessness, prompt vs completion pricing
  • The chat API surface
• Caching, retries, budgets — prompt caching, semantic cache, fallbacks
  • Model-provider abstraction and LLM resilience
  • The LLM gateway and caching — the gateway layer, why the stable prefix must come first, and why semantic caching is dangerous

Databases — “which have you worked with, how do you optimise them”

• Query optimisation method — the war story lives here
  • EXPLAIN and EXPLAIN ANALYZE
  • N+1 query problem — selectinload / joinedload
• Indexes — composite column order, partial, covering, why one is unused
  • Database Indexes — Fundamentals
  • Index types
• The ORM layer — SQLAlchemy 2.0 async, migrations
  • SQLAlchemy
  • Alembic — both [M] in §4.1 and neither was linked here
• Connection pooling — PgBouncer transaction mode and what it breaks
  • Connection pooling
• Transactions and isolation — MVCC, locks, deadlocks
  • Transactions and isolation levels
  • PostgreSQL Advisory Locks
• Scaling past one box — partitioning, replicas, sharding
  • Sharding and Partitioning
• Redis — cache-aside, TTL, invalidation, stampede
  • What is Redis
  • Cache Stampede and Mitigation Patterns
• SQL vs NoSQL — if they push on DynamoDB/Mongo
  • SQL and NoSQL

Backend, APIs and integrations

• FastAPI project structure — they asked this explicitly
  • FastAPI project structure
  • The honest answer: the docs define one multi-file layout; “two types” is community shorthand
• Dependency injection — Depends, scopes, testing seams
  • Dependencies and injection
  • Dependencies and injection
• Integration design — a core responsibility in this role
  • Designing an external API integration
  • Timeouts, retries and backoff
  • Circuit breakers and bulkheads
  • Fallbacks, partial failure and graceful degradation
• Queues and DLQs — §11 names DLQs; §4.4 marks SQS [M]
  • SQS — Visibility Timeout, Consumer Patterns, and Failure Handling
  • Dead-Letter Queue (DLQ) for Celery
  • What is Celery — [M]; RAG ingestion is a background job
  • Celery Task Idempotency — idempotent consumers
• Webhooks — HMAC signature verification, replay protection, ordering
  • Practical Case: Webhook Ingestion & Processing Service
• Idempotency — the FinTech credibility signal
  • Idempotency Keys (API-Level Deep Dive)
  • Idempotency
• API design — versioning, pagination, error contract
  • REST Versioning and Pagination
  • HTTP Semantics and Caching
• Async correctness — never block the event loop
  • Python Concurrency Models: Processes, Threads, and Asyncio
  • run_in_executor and asyncio.to_thread
• Testing LLM code — mock the provider, eval as a separate gate
  • Mocking external APIs
• CI and packaging — where the eval gate actually runs
  • GitHub Actions
  • Docker and Docker Compose Command Guide — [M] in §4.1

FinTech domain — do not skip

• Money precision — Decimal or integer minor units, never float
  • Python performance for quantitative work (see How do you store money?)
  • Floats and equality
• PII in prompts — what may never leave the boundary
  • PII, privacy and the EU AI Act
  • Prompt injection
• Audit logging — immutable event trail, append-only records ([M] in §4.5)
  • CQRS and Event Sourcing
• Data residency and self-hosting — the “can data leave” question
  • AWS Bedrock and AgentCore
  • Azure and Vertex — the other two clouds, for §14’s question to the CTO
• Governance vocabulary — if the CTO is thinking about audit and the EU AI Act
  • Model governance and responsible AI

Behavioural

• Last project — problem, ownership, architecture, hardest decision, number
  • How would you describe your strongest project, and what questions would you expect about it?
  • What was the most challenging part of a recent project?
• International team / independence — be specific, not generic
  • Joining an Existing Project: How to Read and Understand the Codebase
• How you work with AI tools — likely follow-up for this role
  • How do you work with AI tools?
  • How exactly do you apply AI in your work?

Written for this interview

Two notes were added because the question list needed them and the repo had no dedicated coverage:

• pgvector in production — HNSW vs IVFFlat, ef_search as the recall dial, the filtered-ANN cliff, and why an index built for one operator is silently ignored by a query using another. Your own stack, and §10 of the prep doc asks for exactly this.
• Which model for which task — question 10 on the client’s list. Task-based routing, escalation rate, why embeddings and reranking want their own models, and the cost levers in order.

FastAPI project structure was added earlier for the FastAPI question they named directly.

The three behaviours that decide it

From the client’s feedback on the last candidate — worth more than any note on this page:

1. Reason aloud. 60–120 seconds per technical answer, in the shape context → options → decision → trade-off → result. A correct 15-second answer still fails.
2. Never stop at “I don’t know.” Bridge to the nearest thing you have done: “not Weaviate specifically, but the same pattern on pgvector, where the trade-off was…”
3. Slow English beats fast English. Fluency reads as fewer errors, not more words.