Positioning and job prep

Put an 'AI engineering projects' section first, with each flagship as a bullet group: what it does, the stack, and numbers (eval scores, latency, cost reductions).

Recast previous engineering experience in terms AI teams value: reliability, scaling, observability, API design, distributed systems, security. These are exactly the skills LLMOps and agent roles struggle to hire for.

Mirror the vocabulary of the roles you target (RAG, evals, agents, LLMOps) honestly. Every keyword should be defensible in an interview.

GitHub: a profile README with a one-line positioning statement and links to the two flagships and the from-scratch GPT. Pin six repositories. Make sure each pinned repository runs from its README instructions.

Write one substantial post: e.g. 'What actually improved my RAG system: measured' or 'Hardening a RAG app against indirect prompt injection'. Specific, with numbers and code. Share it on LinkedIn.

A post with real measurements is a conversation starter in interviews and evidence of communication skills.

Practise the chain: text → tokens (BPE) → embeddings → transformer blocks (attention moves information between positions, MLPs compute per position) → logits → sampling.

Then cost: prefill processes the prompt in parallel (time to first token); decode generates one token per step using the KV cache (tokens per second); the KV cache grows with context, consuming memory; attention compute grows with context length; long prompts are re-sent and re-billed every turn unless cached.

Rehearse aloud and time yourself. Interviewers listen for whether you understand why, not whether you know the terms.

Clarify: query volume, freshness needs, document types, access control, latency target (time to first token vs full answer), languages. Estimate: 10M docs × ~10 chunks = ~100M vectors; at 768 dimensions float32 that's ~300 GB raw, so quantisation or PQ, sharding, and a careful index choice matter.

Ingestion: queue-based pipeline, incremental updates, deduplication, chunking with metadata and ACLs. Query path: query rewriting (cached), hybrid retrieval with permission filters, sharded ANN, cross-encoder rerank on top 50, streaming generation, caching of frequent queries. Budget the latency per stage.

Operations: retrieval and generation evals, tracing, index rebuild strategy, embedding-model migration plan, cost per query.

No ground truth? Start with error analysis on real traces; write binary criteria per failure mode; label a small set yourself; use LLM-as-judge validated against those labels; use reference-free metrics (faithfulness to retrieved context, schema validity); collect user feedback; run paired comparisons between versions.

RAG vs fine-tuning: RAG for changing, citable, large or permissioned knowledge; fine-tuning for format, style, behaviour, latency or cost (distilling into a smaller model). Usually both. Start with prompting + RAG and fine-tune for a measured gap.

Have one concrete story from your own projects for each.

1. Clarify: users, inputs and outputs, scale (requests per second, corpus size), latency target, quality bar, constraints (privacy, residency, budget). 2. Estimate: tokens per request, cost per request and per month, storage for embeddings, GPU needs if self-hosting.

3. Baseline design: the simplest thing that could work (often prompt + RAG), drawn end to end with offline and online paths. 4. Deep dive: pick the riskiest component (retrieval quality, agent safety, latency) and go deep with alternatives and their trade-offs.

5. Close with operations: how you'd evaluate (offline set, online signals), observe (tracing, cost), secure (injection, PII, permissions) and iterate. Interviewers weigh this last part heavily for AI roles because it's what separates demos from products.