The complete
handbook library.
Full-length technical handbooks on agentic AI, LLM systems, and building in public. Free to read. Take what you need.
The Prompting Handbook.
A friendly, hands-on field guide for everyday humans — learn the CRISP framework, spot bad prompts, practice with real recipes, play a drag-and-drop game, and test yourself with a quiz. No code required.
The Agentic AI Interview Handbook.
Twenty topics every senior AI engineer should be able to reason about live — from eval pipelines to reliability patterns for generative systems.
The Senior AI Engineer Interview Handbook.
60 questions across architecture, production incidents, agentic systems, RAG, evals, cost, safety, and leadership — what staff-level AI interviewers actually probe for.
50 Angular Interview Questions.
A visual handbook covering components, change detection, RxJS, signals, routing, forms, performance, and testing — what interviewers actually probe for in senior Angular roles.
50 Python Interview Questions.
Fundamentals to advanced: data structures, OOP, iterators & generators, the GIL, asyncio, memory, testing, and the standard library — a visual walk through everything a Python interview touches.
51 LLM Evals Interview Questions.
Golden sets, LLM-as-judge, regression testing, offline vs online evals, RAG evals, agent evals, red-teaming, and observability — demystified for interviews and production.
The Agent Evaluations Handbook.
A self-contained handbook on evaluating AI agents — theory, interactive widgets, and practical guidance. Trajectory evals, tool-use scoring, LLM-as-judge, observability, and reliability for PMs, engineers, and founders.
The System Design Fundamentals Handbook.
The load-bearing ideas behind every distributed system — the CAP theorem and consistency models, concurrency and locking, partitioning and replication, and consensus and coordination — each tied to a real worked design you can study interactively.
CAP Theorem & Consistency Models.
What a distributed system can promise when the network splits — CP vs AP, why "CA" is a myth, PACELC, and the full spectrum from linearizable to eventual consistency. Part of System Design Fundamentals.
Concurrency, Locks & Isolation Levels.
How overlapping operations stay correct — race conditions, optimistic vs pessimistic locking, the four isolation levels and their anomalies, MVCC, and distributed locks with fencing tokens. Part of System Design Fundamentals.
Partitioning, Sharding & Replication.
How one dataset becomes many — range vs hash partitioning, consistent hashing and virtual nodes, hot partitions, replication topologies, replication lag, and quorums. Part of System Design Fundamentals.
Consensus, Transactions & Coordination.
How nodes that can crash still agree on one truth — majority quorums, Raft and Paxos, leader election, two-phase commit vs the saga pattern, and idempotency for exactly-once effects. Part of System Design Fundamentals.
Claude Skills: A Builder's Manual.
Everything learned from building Skills in production, distilled into something you can read in a sitting.
Building in Public, For Engineers Who Hate Marketing.
A systems-approach to content, distribution, and open source for people who would rather be coding.
MCP Servers from Scratch.
A practical walkthrough from zero to a shipped Model Context Protocol server, including the ugly parts.
The Agent Patterns Handbook.
The design patterns behind every LLM agent — the ReAct Thought–Action–Observation loop, tool/function calling, plan-and-execute, reflection, memory, multi-agent orchestration, and the failure modes (loops, hallucinated tools, recovery, human-in-the-loop) that break agents in production.
The LLM Serving Handbook.
How to serve large language models fast and cheap — prefill vs decode, the KV cache, continuous batching and PagedAttention (vLLM), quantization, speculative decoding, and the latency-vs-throughput tradeoffs that decide your inference bill.
The Transformers Handbook.
The architecture behind every LLM, built up from scratch — tokens and embeddings, positional encoding, self-attention (query/key/value), multi-head attention, the transformer block (FFN, residuals, layer norm), and how a decoder-only model generates text autoregressively.
The RAG Handbook.
Retrieval-augmented generation end to end — why LLMs need it, chunking, embeddings and vector search, hybrid retrieval, two-stage reranking, grounded generation with citations, and how to evaluate a RAG system so a quietly-drifting index never fools you.
The Fine-Tuning Handbook.
When to fine-tune vs RAG vs prompting, full fine-tuning vs parameter-efficient methods, how LoRA and QLoRA make it cheap enough for a single GPU, why the data matters more than the method, catastrophic forgetting, and how to evaluate and decide.
The Vector Databases Handbook.
How vector search actually works — why brute-force kNN doesn't scale, distance metrics, approximate nearest neighbor, the HNSW, IVF and product-quantization indexes and their recall/latency/memory tradeoffs, metadata filtering, updates, scaling, and when you need a dedicated vector DB vs pgvector.
The Kafka Handbook.
Apache Kafka as a distributed append-only log, not a queue — topics, partitions and offsets, producers, consumers and consumer groups, per-key ordering, replication and ISR, delivery semantics (at-least-once and exactly-once), retention vs log compaction, and when Kafka beats a message queue.
The Redis Handbook.
Redis as an in-memory data-structure server, not just a cache — the core structures (strings, hashes, lists, sets, sorted sets), why single-threaded is fast, RDB vs AOF persistence, eviction and TTL, the classic patterns (cache, rate limiter, leaderboard, session, queue, pub/sub), high availability with replication, Sentinel and Cluster, and when it's the wrong tool.
The SQL Handbook.
What the database does underneath your SELECT — the relational model and keys, joins (inner/left/right/full), indexes and B-trees, the query planner and reading EXPLAIN, transactions and ACID, isolation levels and the anomalies they prevent, normalization vs denormalization, and the pitfalls (N+1, missing indexes, SELECT *).
The Kubernetes Handbook.
The one idea under all the YAML — declare desired state, and a control loop makes reality match. Covers the orchestration problem, pods, deployments and replicasets, services and networking, the reconciliation loop and self-healing, the scheduler, config/secrets and health probes, autoscaling, and when you actually need Kubernetes.
The Observability Handbook.
Seeing inside production — monitoring vs observability, the three pillars (metrics, logs, traces) and what each answers, structured logging, metric types and the cardinality trap, distributed tracing, the golden signals and SLIs/SLOs/error budgets, alerting on symptoms not causes, and correlating all three during an incident.
The React Interview Handbook.
What senior React interviews actually probe — components and JSX, props vs state, the render cycle with the virtual DOM and reconciliation, hooks and the rules of hooks, why components re-render and when memoization helps (and hurts), keys and lists, controlled inputs, and context vs prop drilling.
The Networking Handbook.
How a request actually travels — the layered model, IP addressing and routing, TCP vs UDP, the TCP handshake and head-of-line blocking, DNS resolution and caching, HTTP/1.1 vs HTTP/2 vs HTTP/3 (QUIC), TLS/HTTPS, and why round-trip latency, not bandwidth, dominates.
The Diffusion Models Handbook.
How AI images are really made — generation as iterative denoising, the forward noising and reverse denoising processes, the elegant noise-prediction training objective, sampling and the steps-vs-speed dial, conditioning and classifier-free guidance, latent diffusion (Stable Diffusion), and why diffusion beat GANs and VAEs.
The Reinforcement Learning Handbook.
Learning to act by trial and error — the agent-environment loop, cumulative reward and discounting, exploration vs exploitation, value functions and Q-learning, policy gradient methods (REINFORCE/PPO), why RL is unstable and reward hacking happens, model-free vs model-based, and how RLHF turned LLMs into assistants.
The Behavioral Interview Handbook.
The round that decides your level — why behavioral interviews matter and what they signal, the STAR method with a worked example, building a flexible story bank, leadership and ownership, conflict, failure, ambiguity and prioritization, thoughtful questions to ask, and the red flags that sink good candidates.
The Model Context Protocol (MCP) Handbook.
The open standard connecting AI agents to the outside world — why M×N bespoke integrations collapse to M+N, the host/client/server roles over JSON-RPC, the three primitives (tools, resources, prompts), the connect→discover→call session lifecycle, when MCP earns its keep, and the security sharp edges (a server's output is untrusted input).
The Loop Engineering Handbook.
Stop prompting your agents — design the system that prompts them for you. The inner vs outer loop, the four loop types (heartbeat, cron, hook, goal), the six building blocks (automations, worktrees, skills, MCP connectors, subagents, external memory), stopping conditions and the verification split, state across runs, cost engineering, and the six failure modes that burn tokens at 3am.
The Context Engineering Handbook.
The discipline that replaced prompt-tweaking: curating everything the model sees under a finite attention budget. The anatomy of a production context window, the three taxes on an overstuffed one (context rot, cost, behavioral drift), the four operations (write, select, compress, isolate), agent-specific patterns like compaction and just-in-time retrieval, six production habits, and where it sits in the prompt → context → loop → harness stack.
The Agent Skills Handbook.
Packaged, on-demand expertise for AI agents: what a skill folder actually is (SKILL.md + scripts + resources), progressive disclosure and why the system prompt couldn't do it, the skills vs tools vs MCP vs fine-tuning decision table, six habits of skills that actually trigger, and why third-party skills are supply-chain dependencies to review like code.
The Agentic Coding Handbook.
Working with coding agents — Claude Code, Cursor and their cousins — without drowning in AI slop. The loop + tools + context anatomy, the CLAUDE.md instruction file (your highest-leverage artifact), the plan-then-verify workflow, skills/subagents/hooks, the vibe-coding review dial, the security sharp edges (injection, secrets, dangerous commands), and the team norms that keep quality from eroding.
The On-Device AI Handbook.
Small models, everywhere: why 1–14B models got frontier-adjacent (distillation + textbook data), the napkin law of local inference (tokens/sec ≈ bandwidth ÷ bytes), quantization and the llama.cpp / GGUF / Ollama / MLX stack, the honest local-vs-cloud decision table, four hybrid patterns that ship, and the evals craft of choosing a small model that actually fits the device.
The AI Security Handbook.
Your app now reads the internet and believes it. Why prompt injection is a design problem filters cannot solve, the lethal trifecta (private data + untrusted content + exfiltration), defense in depth from least privilege to output validation, where PII actually leaks (logs, embeddings, weights), MCP/model supply-chain trust, and the red-team eval suite that gates CI.
The Git Internals Handbook.
Learn the model and the commands become obvious. Git as a content-addressed database: blobs, trees and commits; branches as 41-byte files; the three trees behind add/commit/reset; what merge and rebase mechanically do (and why rewriting shared history is a law, not a preference); the reflog recovery recipe; packfiles.
The Docker Handbook.
A container is a lie told by the kernel — namespaces (what a process sees) plus cgroups (what it uses), not a VM. Image layers and the cache-ordering rule that halves build times, multi-stage Dockerfiles that ship small, volumes vs bind mounts, name-based networking, Compose, and the handoff to Kubernetes.
The PostgreSQL Internals Handbook.
UPDATE never updates, and a janitor keeps it working. Heap pages and tuples, MVCC's row versions (xmin/xmax visibility arithmetic), VACUUM, bloat and the wraparound scare, B-trees, HOT updates and index-only scans, the WAL's three superpowers (recovery, replication, PITR), reading the planner honestly, and why PgBouncer is infrastructure.
The GPU Fundamentals Handbook.
The bottleneck is never where you think. SIMT and warps, the memory hierarchy from registers to HBM, arithmetic intensity and the roofline (compute-bound vs bandwidth-bound), where LLM workloads actually land, why FlashAttention was inevitable, the kernel stack from CUDA to Triton to torch.compile, and the multi-GPU interconnect story.
The API Design Handbook.
An API is a promise you keep for years. Choosing REST vs gRPC vs GraphQL honestly, resource-modeling REST so consumers can guess it, contract-first gRPC and protobuf evolution, the retry-safe semantics that survive real networks (idempotency keys, cursor pagination, structured errors), versioning without breaking clients, and why agent tool schemas are the newest API surface.
The Distributed Training Handbook.
When the model doesn't fit, split it four ways. What actually eats training memory, data parallelism and all-reduce, ZeRO/FSDP sharding stages, tensor parallelism inside a layer, pipeline parallelism across layers (and the bubble micro-batching hides), 3D parallelism, the communication-overlap that decides MFU, and the memory tricks (mixed precision, gradient accumulation, activation checkpointing) you reach for first.
RAG vs Fine-Tuning.
The most common wrong turn in AI engineering — reaching for fine-tuning when you needed retrieval, or vice versa. The one distinction that decides it (knowledge vs behavior), a head-to-head table, when to use each, and why the strongest systems combine them: fine-tune for behavior, RAG for knowledge.
Kafka vs RabbitMQ.
They both "move messages", which is exactly why teams pick the wrong one. Kafka is a durable, replayable log where consumers track their own offset; RabbitMQ is a smart broker that routes each message and deletes it on ack. The remember-vs-forget core difference, throughput and ordering trade-offs, and how to choose.
Redis vs Memcached.
Both put data in RAM by a key, so they look interchangeable — but Memcached does one thing (a lean multithreaded cache) while Redis is a data-structure server with persistence, replication and pub/sub. The one-job-vs-many split, a feature table, and why most teams now default to Redis.
SQL vs NoSQL.
Framed as a war, it’s really a menu. Relational databases give you schema, joins and ACID; NoSQL is an umbrella of document/key-value/wide-column/graph stores that drop some of that for flexibility and horizontal scale. The relationships-vs-scale core difference, the CAP trade-off, and why to start relational.
PostgreSQL vs MySQL.
Both are excellent free relational databases you can build a company on, so the choice is about character, not capability: Postgres prizes correctness, rich types and advanced features; MySQL prizes simplicity and read-heavy speed. The real differences, when each wins, and why Postgres became the modern default.
gRPC vs REST.
Both let services talk, and you often want both. REST over HTTP/JSON is universal, cacheable and debuggable — the right skin for public APIs; gRPC uses typed protobuf over HTTP/2 for fast, streaming service-to-service calls. The audience-decides rule, a trade-off table, and the REST-at-the-edge, gRPC-inside pattern.
MCP vs Function Calling.
Pitted against each other, but they live at different layers — like comparing USB-C to sending data. Function calling is the model capability to emit a structured tool request; MCP is the open standard for discovering and connecting to tool servers. How MCP uses function calling, and when each matters.
50 System Design Interview Questions.
The questions that actually come up in senior and staff loops, each with a concise, defensible answer you can say out loud: scaling and estimation, load balancing, caching, databases and sharding, CAP and consistency, message queues, reliability, and the classic design scenarios like URL shorteners and news feeds. Mark what you master as you go.
AI for Lawyers.
The practical middle ground for legal professionals: where AI genuinely helps (first drafts, brief summaries, review triage), the three non-negotiable rules — confidentiality, verify every citation, you sign it you own it — five workflow recipes with exact prompts, a spot-the-danger judgment exercise, and the five questions to ask any AI vendor. No coding required.
AI for Doctors.
The practical middle ground for clinicians: where AI genuinely helps (notes from dictation, discharge instructions, prior auths, literature summaries), the three non-negotiable rules — PHI needs a BAA, verify everything clinical, the chart is yours — five workflow recipes with exact prompts, a spot-the-danger judgment exercise, and the six questions to ask any clinical AI vendor. No coding required.
AI for Civil Engineers.
The practical middle ground for civil and structural engineers: where AI genuinely helps (observation reports, RFI responses, meeting minutes, plain-language explanations), the three non-negotiable rules — the adopted code is the authority, calculations get checked independently, your stamp is yours — five workflow recipes with exact prompts, a spot-the-danger judgment exercise, and the vendor questions that matter. No coding required.
The Embeddings Handbook.
Meaning as geometry: how text and images become vectors so that similar meaning lands nearby, why cosine similarity measures direction not length, how L2-normalization makes the dot product equal cosine (so vector databases just take dot products), the curse of dimensionality, and how it all powers semantic search and RAG — with worked math and runnable code.
The AI Cost Engineering Handbook.
AI spend is a sum over tokens: input-tokens × input-price + output-tokens × output-price, per million. Why output tokens dominate the bill (usually ~5× input), how prompt caching pays off from the very first reuse, and the full lever set — shorter outputs, caching, model routing, batching, context trimming — that cuts spend without cutting quality. With worked math and a runnable cost calculator.
The Structured Outputs Handbook.
How LLMs return guaranteed-valid JSON for function calling and tool use. Why prompting for JSON is unreliable, how constrained decoding masks illegal tokens to −∞ so output is valid by construction (not by hope), the spectrum from JSON mode to full schema enforcement, and the trade-offs — including why "valid" is not "correct". With worked math and runnable code.
The Model Routing Handbook.
Send each request to the cheapest model that can handle it. How a cheap-smart cascade works, why you pay the cheap model on everything so the escalation rate is the key lever, the break-even math (r* = 1 − c_cheap/c_big), predictive routers vs cascades, and the confidently-wrong pitfall. With worked math and a runnable cost model.
The Agent Memory Handbook.
A finite context window forces a memory strategy. Short-term (context) vs long-term (external store), how eviction (FIFO) and summarization (compression) keep a growing conversation in the token budget, and how retrieval recalls a fact long after it scrolled out of context — the memory-as-OS idea. With worked budget math and runnable code.
The Guardrails Engineering Handbook.
The input and output filters that keep an LLM system safe. Why no single filter is enough, how layering independent guardrails drives the combined miss rate down multiplicatively (defense in depth: ∏ miss_i), why false positives compound the other way (1 − ∏(1−fp_i)), the independence caveat, and where to place each layer. With worked math and runnable code.
The Synthetic Data Handbook.
Using LLMs to generate training and eval data. Why quality filtering beats raw volume (effective size = generated × pass rate), what model collapse is and why recursive training on unfiltered self-generated data shrinks diversity (Var_k = s^k · Var_0 → 0), and a safe generate-filter-mix pipeline. With worked math and runnable code.
The Harness Engineering Handbook.
The loop that wraps a model into an autonomous agent — plan, act, observe — and why its most important property is bounds. A stuck agent with no hard stop loops forever, burning money, so the harness enforces max steps AND a cost budget. Geometric success math (P(done ≤ k) = 1 − (1−p)^k, E[steps] = 1/p) and a bounded loop you can run — with worked math and runnable code.
The LLM Observability Handbook.
Tracing an AI request as a tree of spans. Why total latency is the critical path — the max end time, not the sum of durations, because parallel spans overlap — while cost is the sum across every span, how to find the bottleneck span, and what to log for every LLM call (including percentiles over averages). With worked math and runnable code.
The Prompt Caching Handbook.
How prompt caching actually works. Why caches key on the exact prefix and break at the first differing token, why cache-aware ordering (fixed content first, variable last) is the single biggest lever on hit rate, how TTL and cache breakpoints work, and the invisible mistakes (a timestamp up top, non-deterministic serialization) that silently kill caching. With worked math and runnable code.
The Evals in CI Handbook.
Turn LLM quality into a regression gate, like unit tests for code. A golden set scored on every change, and why the gate needs both an aggregate threshold AND per-case no-regression — because a healthy average can hide a broken case (mean stays up while one case collapses). How to wire it into the PR pipeline, handle non-determinism with a tolerance band, and avoid a flaky gate. With worked math and runnable code.
The Sandboxing Handbook.
Safely running untrusted or agent-generated code. Why deny-by-default beats a block-list (you can't enumerate all evil, so enumerate the little good), how least-privilege allowlists shrink the escape surface, why resource caps are needed on top of policy, and the layers of isolation from seccomp to microVMs. With worked policy math and runnable code.
The Local LLM Stack Handbook.
Running LLMs locally with ollama and llama.cpp. The one equation that decides what fits — weight memory = params × bits per weight ÷ 8 — how quantization shrinks a 7B model from 14GB (fp16) to 3.5GB (4-bit) to fit a consumer GPU, why 4-bit is the sweet spot, and the local stack (GGUF, ollama, llama.cpp). With worked memory math and a runnable fits-in-VRAM calculator.
The PII in LLM Pipelines Handbook.
Handling personal data safely with the redact-before-send pattern: detect PII, replace each value with a stable placeholder before the model sees it, restore the real values in the response — so personal data never crosses the trust boundary to the provider. The leak invariant, consistent placeholders, detection limits, and defense in depth (minimization, BAA/DPA, local models). With worked math and runnable code.
The Multi-Agent Orchestration Handbook.
Coordinating multiple LLM agents on one task — and when not to. Why coordination overhead grows quadratically (N(N−1)/2 pairs) while useful work divides only linearly, so past an optimal team size more agents make a system slower, pricier, and less reliable, how to find where the U-curve turns, and the patterns (orchestrator-workers, handoff, routing) that keep coordination near-linear. With worked math and a runnable optimal-team-size calculator.
The Data Engineering for AI Handbook.
The pipeline that turns raw documents into usable data for RAG and training — ingest, chunk, deduplicate, quality-filter. How overlapping chunking works, why deduplication restores diversity, and why the usable dataset is a compounding fraction of the raw pile (raw × dedup-rate × quality-rate) — because quality beats quantity for both retrieval and training. With worked yield math and a runnable pipeline.
The Browser & Computer-Use Agents Handbook.
LLM agents that operate a UI like a human — no API required. The observe-act-verify loop, why grounding (identifying which element to click on a cluttered, shifting page) is the dominant source of failure, and why grounding errors compound: task success is per-step accuracy to the power of the number of steps (0.9¹⁰ ≈ 35%), so long UI tasks are brittle. Plus the prompt-injection surface. With worked math and runnable code.
The A2A Agent Interop Handbook.
Letting heterogeneous agents from different teams work together. The two agreements A2A needs: capability discovery (agents advertise their skills so others can find and route to them) and a shared message schema (so one agent's output chains into another's input). Why both are required — a capable partner you can't talk to is useless — plus schema drift, capability lies, and how A2A relates to MCP. With worked math and runnable code.
The WebSockets & Real-Time Handbook.
Why "live" is hard on a protocol that can't push. Polling makes you wait on average half the interval to learn of an event (a 10s poll = ~5s staleness) and wastes a request every time nothing changed — and shrinking the interval only multiplies the waste. A WebSocket keeps one persistent full-duplex line open so the server pushes the instant something happens: latency ≈ one network hop, zero empty requests. The poll-vs-push latency math, when to use SSE instead, and the stateful-scaling pitfalls. With worked math and runnable code.
The Voice AI Real-Time Agents Handbook.
Why a voice agent is a stopwatch, not a chat box. It's a three-stage pipeline — speech-to-text → LLM → text-to-speech — and the user waits for all three, so end-to-end latency is the sum of the stages. Human turn-taking breaks down past ~800ms, so the whole game is keeping that sum under the conversational budget: find the bottleneck (usually the LLM), shave the slowest stage first, cut network hops, and stream so the stages overlap. Plus endpointing, interruption handling, and why time-to-first-audio beats the naive sum. With worked math and runnable code.
The Caching Patterns Handbook.
Why the fastest query is the one you never run. A cache serves requests from a fast store and falls back to a slow source on a miss, so average latency is a hit-rate-weighted blend of the two paths — h·t_cache + (1−h)·t_source, dominated by the miss term. That makes hit rate the one number that decides a cache's value. The patterns (cache-aside, write-through, write-back), the eviction policy, and the two famously hard problems — invalidation/staleness and the cache stampede — that turn a speedup into an outage if you get them wrong. With worked math and runnable code.
Cryptography for Engineers.
Encryption from XOR up. The one-time pad — XOR each byte with a random, message-length, single-use key — is the only provably unbreakable cipher, and its three rules teach the whole subject. XOR is its own inverse (a⊕k⊕k=a), so decrypt is the same op; a zero key is the identity (why keys must be random); and the fatal mistake: reuse the key on two messages and c₁⊕c₂=p₁⊕p₂ — the key cancels and secrecy dies (the VENONA blunder). Scales to symmetric (AES) + public-key + nonces + TLS, and the engineer's rules: never roll your own, never reuse a nonce, secure randomness, hash passwords slowly. With worked math and runnable code.
The OAuth & Auth Deep Dive.
How "Sign in with Google" lets an app act for you without ever seeing your password. OAuth swaps your credentials for a scoped, revocable token, delivered via a short-lived authorization code that's worthless on its own — turning it into a token needs a back-channel exchange the browser can't make. Two parameters guard the flow: state (a random value echoed back, blocking forged/CSRF responses) and PKCE (challenge = SHA-256(verifier), so a stolen code can't be redeemed without the secret). Plus authentication vs authorization, OIDC/ID tokens, and the traps (implicit flow, unvalidated tokens, wide scopes, token leaks). With worked math and runnable code.
The Operating Systems Fundamentals Handbook.
How your machine runs hundreds of programs on a few cores and a fixed slab of RAM — by sharing what isn't enough. Two tricks carry the weight: round-robin scheduling slices CPU time into quanta so no process starves (paying for fairness in context-switch overhead), and virtual memory pages hot data into physical frames, faulting to disk on a miss and evicting the least-recently-used page (LRU) — so more frames means fewer faults. Plus the vocabulary (process/thread/context switch/system call/page fault/kernel vs user mode) and the traps (thrashing, over-threading, the million-to-one memory hierarchy). With worked math and a runnable scheduler + pager simulation.
The Linux Internals Handbook.
Linux runs the world on one idea: everything is a file. A document, the keyboard, a socket, another program's output — all reached through a small integer (a file descriptor) with the same four calls: open, read, write, close. The descriptor table allocates the lowest free integer (0/1/2 = stdin/stdout/stderr), which is exactly how the shell redirects output; a pipe is a kernel FIFO whose two ends wire a | b so one tool's output becomes another's input; and fork/exec split process creation from program loading, opening the window where descriptors get wired. Plus the traps (fd leaks → EMFILE, pipe backpressure/deadlock, zombie processes). With worked math and a runnable fd-table + pipe.
The Compilers Basics Handbook.
How a flat string like "2 + 3 * 4" becomes the meaning 14 (not 20). A compiler works in stages: tokenize the text into atoms, parse the tokens by precedence, then evaluate. Built around a tiny arithmetic pipeline — tokenize → shunting-yard → RPN eval — where the single precedence comparison is exactly where "*" is encoded to bind tighter than "+", and parentheses override it. Then scale the same skeleton to real languages (AST, semantic analysis, optimization, IR/codegen, LLVM) and dodge the traps (parsing nested grammars with regexes, conflating stages, ignoring error positions). With worked math and a runnable end-to-end calculator.
The Browser Internals Handbook.
How a browser turns a tree of tags and a pile of CSS into a scrolling, animating picture at 60fps. The render pipeline — parse → style → layout → paint → composite — is ordered and dependent, so the cost of a visual change is how far back it reaches. Layout (reflow) is the expensive stage because boxes are interdependent (cost grows with node count); geometric changes (width, top, adding a node) force it, paint-only changes (color) skip it, and transform/opacity stay on the composite-only fast path. Plus layout thrashing (interleaved read/write forces a sync reflow each time — batch them), and virtualizing giant DOM trees. With worked math and a runnable reflow calculator.
The Rust Handbook.
Rust refuses the old memory trade-off (safe-but-slow GC vs fast-but-dangerous manual free) with one idea: ownership. Every value has exactly one owner, freed when the owner's scope ends — no garbage collector, no manual free, never freed twice. Assigning or passing a value moves it (invalidating the original, so no double-free/use-after-move); to share you borrow under one rule — any number of shared references XOR exactly one mutable — which makes data races impossible; and clone() deep-copies when you truly need two. All checked at compile time, so safety costs nothing at runtime. Plus the guarantees table and the traps (cloning to silence the checker, fighting instead of listening, reaching for unsafe/Rc/RefCell too early). With worked rules and a runnable borrow-checker model.
The Go Handbook.
Go makes concurrency approachable with one motto: don't communicate by sharing memory; share memory by communicating. Instead of threads poking at locked shared state, cheap goroutines (start with "go f()", run hundreds of thousands, multiplexed onto a few OS threads) pass data through channels — typed pipes that carry the synchronization. The whole model hinges on one rule: when does an operation block? An unbuffered channel (cap 0) blocks a send until a receiver is ready (a rendezvous); a buffered channel (cap N) blocks only when full/empty; and a blocked op with no partner is a deadlock (which Go's runtime detects and panics on). Plus goroutine leaks and when a mutex is still the right tool. With worked rules and a runnable channel model.
The TypeScript Handbook.
Why TypeScript surprises people from Java/C#: its type system is structural, not nominal — it matches by an object's shape, not a declared name. A value is assignable to a type if it has every property the type requires with a matching type ("if it walks like a duck…"), so a wider object (extra props) fits a narrower target but a missing property never does. Object literals get one extra rule — the excess-property check — that flags undeclared props to catch typos (which is why extracting to a variable can make a type error vanish). Plus structural vs nominal trade-offs, branded types, and the traps (any disables checking; types are erased so validate external data at the boundary). With worked math and a runnable assignability checker.
The React Handbook.
React lets you write UI declaratively — return a description of what it should look like — and makes it fast with reconciliation: it builds a lightweight virtual DOM, diffs it against the previous tree, and applies only the minimal real-DOM changes. For lists it matches items by key: a key in both old and new means reuse the element in place (keep its DOM node + state), a new key mounts, a gone key unmounts — so a pure reorder with stable keys costs zero. The famous bug: using the array index as a key breaks on reorder/insert, because an index is a position not an identity, so React reuses the wrong element and state leaks to the wrong row. Plus unnecessary re-renders, memo/useMemo/useCallback, and why the virtual DOM isn't automatically fast. With worked math and a runnable reconciler.
The Salary Negotiation Handbook.
The expected-value case for always countering an offer. A polite counter is accepted with some probability p and otherwise the employer just holds the original (they essentially never rescind over a reasonable ask), so EV = p·counter + (1−p)·original beats accepting for any p>0 — heads you win, tails you break even. Your BATNA (best alternative) is your real leverage and your accept-floor; improve it before the conversation with competing offers. And a base bump compounds — its lifetime value is a geometric series, ≈$55k for a $10k raise over 5 years at 5%, not $50k. Plus how to actually do it (research, let them anchor, counter in writing, negotiate the whole package and level) and the traps. With worked math and a runnable EV calculator.
The Code Review Culture Handbook.
The quantitative case for code review plus the human norms that make it pay off. A defect costs ~1× to fix in review, ~10× in test, ~100× in production — so review, the earliest human checkpoint, catches bugs at the cheapest stage and returns many times the reviewer's time (net = bugs-caught × the prod-vs-review gap − review cost). But the ROI is only realized when the culture is right: small PRs (a giant diff gets a rubber-stamp = negative value), automated style so humans never nit it, prompt reviews, blocking-vs-nit clarity, and the golden rule — critique the code, not the coder. Plus how to give/receive feedback and the traps. With worked math (defect-cost curve + review ROI) and a runnable calculator.
The EU AI Act Handbook.
The world's first comprehensive AI law, made legible for engineers. The key idea: it regulates AI by the risk of the use case, not the technology — the same model is unregulated in a spam filter and heavily regulated in a hiring tool. Every system sorts into one of four tiers: unacceptable (banned — social scoring, manipulation, most real-time public biometric ID), high-risk (hiring, credit, medical, education, law enforcement… → risk management, data governance, human oversight, conformity assessment, registration), limited-risk (transparency — chatbots disclose they're AI, deepfakes labelled), and minimal-risk (no obligations — the vast majority). Because tiering is a concrete rule, classification is deterministic. Plus the GPAI/foundation-model layer, what engineers should actually do, and the traps (optimistic self-classification, retrofitting compliance). With a worked classification model and runnable code.
The AI Product Engineering Handbook.
A demo isn't a product. Getting an impressive LLM demo takes an afternoon; turning it into something you can charge for at scale is the brutal last mile where most AI features die. Product engineering rests on two numbers a demo never shows: unit economics (every request costs tokens — cost = in·p_in + out·p_out per million, which sets your gross margin and whether you're profitable) and the eval gate (ship a change only if its measured quality clears a bar AND its margin clears a bar — blocking cheap-but-wrong and great-but-unprofitable alike). Plus the reliability stack (evals, structured outputs, retries/fallbacks, caching, guardrails, observability) that keeps a flaky, pricey, non-deterministic model dependable in production. With worked math and a runnable cost/margin/ship-decision calculator.
The Resume & Portfolio Handbook.
Your resume has two readers and the first isn't human. Most applications hit an ATS (applicant tracking system) that scores keyword coverage against the job — coverage = |resume ∩ required| / |required| — and auto-filters anything below a threshold, so a qualified engineer gets rejected on missing keywords. Step one: clear the machine by tailoring keywords in the posting's own words (for skills you have) in a clean single-column format that parses. Step two: win the human with quantified-impact bullets — a bullet with a number ("reduced latency 40%") beats a vague responsibility ("worked on the backend"). Plus what an engineer's portfolio needs (a few working, well-documented projects, curated not exhaustive) and the traps. With worked math (ATS coverage + gate, bullet impact) and a runnable resume scorer.
The Staff Engineer Behaviors Handbook.
The hardest promotion in engineering — senior to staff — trips people up because they aim at the wrong target: writing more/better code, when the level is a change in the unit of impact. Senior is measured by own output; staff+ by leverage — the output you create in others (an architecture that unblocks three teams, a standard that speeds everyone, a mentee who levels up). Total impact = own_output + Σ multipliers, a team-wide boost is worth team_size × per_person_boost, and staff-level is the threshold where leverage dominates personal output. Covers Larson's four archetypes (tech lead / architect / solver / right hand), glue work and why it's under-credited, how to operate (work on what matters, write relentlessly, influence without authority, multiply others, stay technically credible), and the traps (hero IC, architecture astronaut, invisible glue). With a worked leverage model and runnable code.
AI for Accountants.
The practical middle ground for accounting and tax professionals: where AI genuinely helps (first drafts, document summaries, reconciliation triage, plain-language client explanations), the three non-negotiable rules — client-data confidentiality (incl. IRC §7216), verify every number and authority, you sign it you own it — five workflow recipes with exact prompts, a spot-the-danger judgment exercise, and the five questions to ask any AI vendor. No coding required.
AI for Teachers.
The practical middle ground for educators: where AI genuinely helps (lesson plans, differentiating materials into reading levels, first-draft feedback and rubrics, quiz generation, parent emails), the three non-negotiable rules — student-data privacy (FERPA), verify every fact and answer key, you are still the teacher — five workflow recipes with exact prompts, how to handle AI in students' own work (detectors are unreliable), and the questions to ask any AI vendor. No coding required.
AI for Architects.
The practical middle ground for architectural practice: where AI genuinely helps (concept ideation, first-draft narratives and specs, document summaries, research starting points, early renderings), the three non-negotiable rules — you stamp it you own it, verify every code/zoning/structural claim against the adopted code, protect confidential client and site data — five workflow recipes with exact prompts, a spot-the-danger judgment exercise, and the questions to ask any AI vendor. No coding required.
AI for Real Estate.
The practical middle ground for agents and brokers: where AI genuinely helps (listing descriptions, client follow-ups, market-data summaries, process explanations, social content), the three non-negotiable rules — fair-housing compliance (AI easily generates illegal steering language), verify every fact and number, you are not giving legal/tax/appraisal advice — five workflow recipes with exact prompts, a spot-the-danger judgment exercise, and the questions to ask any AI vendor. No coding required.
AI for Marketers.
The practical middle ground for marketers: where AI genuinely helps (first-draft copy, ideation, repurposing one asset into many formats, briefs, research/analytics summaries), the three non-negotiable rules — never publish fabricated claims/stats/testimonials (FTC false-advertising risk), stay on-brand and recognizably human, verify facts and respect IP — five workflow recipes with exact prompts, a spot-the-danger judgment exercise, and the questions to ask any AI vendor. No coding required.
AI for HR.
The practical middle ground for HR and recruiting: where AI genuinely helps (job descriptions, first-draft policies, structured interview guides, internal comms, anonymized feedback summaries), the three non-negotiable rules — AI never makes a consequential decision about a person (a human decides), actively guard against discrimination/bias (EEOC + NYC Local Law 144 + EU AI Act high-risk), protect sensitive candidate/employee data — five workflow recipes with exact prompts, a spot-the-danger judgment exercise, and the questions to ask any AI vendor. No coding required.
AI for Financial Analysts.
The practical middle ground for financial analysis: where AI genuinely helps (summarizing filings and transcripts, first-draft memos and commentary, structuring/stress-testing model logic, first-pass qualitative research), the three non-negotiable rules — verify every number/calculation/source (models miscalculate and fabricate figures), MNPI and confidential data never touch an unapproved tool (information barriers, securities law), the analysis and recommendation and accountability are yours — five workflow recipes with exact prompts, a spot-the-danger judgment exercise, and the questions to ask any AI vendor. No coding required.
AI for Journalists.
The practical middle ground for reporters and editors: where AI genuinely helps (transcription, document/report summaries, headline and structure ideas, research starting points, plain-language explainers), the three non-negotiable rules — verify everything and never publish an unverified fact or quote (models fabricate quotes and sources), protect your sources and confidential material, be transparent and never pass AI text off as reporting (plagiarism/attribution) — five workflow recipes with exact prompts, a spot-the-danger judgment exercise, and the questions to ask any AI vendor. No coding required.
AI for Product Managers.
The practical middle ground for PMs: where AI genuinely helps (PRD/spec drafts, synthesizing research you actually gathered, competitive-scan starting points, pressure-testing your reasoning, stakeholder comms), the three non-negotiable rules — never let AI fabricate user data/metrics/findings (it invents plausible insights representing nobody), prioritization and product judgment stay human, protect confidential roadmap and customer data — five workflow recipes with exact prompts, a spot-the-danger judgment exercise, and the questions to ask any AI vendor. No coding required.
AI for Sales.
The practical middle ground for sales reps: where AI genuinely helps (personalized outreach from real research, follow-ups, call summaries from your notes, objection prep, CRM drafts), the three non-negotiable rules — never make a false product claim or over-promise (AI invents features/results = misrepresentation that breaks deals and trust), protect prospect data and follow call-recording/consent law, the relationship and discovery and close stay human — five workflow recipes with exact prompts, a spot-the-danger judgment exercise, and the questions to ask any AI vendor. No coding required.
RAG vs Long Context.
A 1M-token window makes it tempting to skip retrieval entirely — but bigger context doesn’t mean the model reads it evenly, and it isn’t cheap. The "lost in the middle" attention problem, cost-at-scale math, and the retrieve-then-go-long pattern that combines both.
LoRA vs Full Fine-Tuning.
LoRA freezes the base model and trains a tiny low-rank adapter; full fine-tuning updates every weight. Why a low-rank update can work at all, memory and storage trade-offs, multi-task adapter serving, and when the extra cost of full fine-tuning is worth it.
MCP vs A2A.
Different layers, not rivals: MCP connects an agent to its own tools and data; A2A connects one autonomous agent to another. Why one protocol wasn’t enough for both jobs, and how a single agent uses both — MCP as its hands, A2A as its voice to peers.
Agents vs Workflows.
Autonomy is a cost, not a default. Workflows hardcode the path in your own code; agents let the model decide its next step at runtime. Why it’s a spectrum, not a binary, and the decision rule for when unpredictability actually justifies an agent loop.
Embeddings vs Keyword Search.
Embeddings match meaning even with zero shared words; keyword search (BM25) matches exact terms with a precision embeddings can’t guarantee. Why the two fail in genuinely complementary ways, and why hybrid search with fusion is the modern RAG default.
Kafka vs Kinesis.
Same partitioned-log model underneath, different operational surface: Kafka is self-run and portable with a huge ecosystem; Kinesis is fully AWS-managed with a hard per-shard throughput ceiling. Retention, cost model, and the lock-in trade-off.
REST vs Webhooks vs SSE.
Three ways client and server move data, split by who exposes an endpoint and whether the connection stays open: REST pulls, webhooks flip who runs the server, SSE keeps one connection open for a live push. How real systems run all three at once.
Monolith vs Microservices.
Microservices don’t remove complexity, they relocate it from the codebase into the network. Why the real trigger to split is organizational (Conway’s Law), not code size, and why "monolith first" is the pattern behind most successful splits.
LLM vs SLM.
The choice is about deployment constraints, not just raw capability: LLMs run in the cloud with broad reasoning; SLMs run on-device with near-zero latency, cost, and full privacy. Why the capability gap is shrinking fast, and the model-routing pattern that uses both.
GPU vs TPU.
GPUs are flexible general-purpose processors with the CUDA ecosystem behind them; TPUs are ASICs purpose-built around the systolic array for matmul, on Google Cloud only. Why that specialization is efficient exactly where it fits, and a liability the moment it doesn’t.
Streaming vs Batch.
Batch processes on a schedule; streaming reacts per-event. The real engineering cost of streaming isn’t speed, it’s correctness under disorder — event time vs processing time, watermarks, exactly-once semantics. The Lambda and Kappa architectures that combine both.
OLTP vs OLAP.
One storage-layout decision explains the whole comparison: row-oriented OLTP makes fetching one record cheap, column-oriented OLAP makes aggregating one column across millions of rows cheap. Why you can’t run heavy analytics well on your production database.
Raft vs Paxos.
Provably equivalent in power, radically different to implement: Raft bets on a strong leader to make consensus reasoning-friendly; Paxos’s more general, leaderless formulation is more flexible and notoriously hard to get right. Why etcd and Kubernetes chose Raft.
CP vs AP Databases.
CAP theorem’s forced choice, precisely stated: CP systems refuse some requests to guarantee consistency during a partition; AP systems keep serving, possibly stale, data. Why this trade-off only bites during an actual partition, and how real systems pick per data type.
LLM API Pricing.
Every major provider’s API pricing in one comparable table, per million tokens — Anthropic Claude, OpenAI GPT, Google Gemini — pulled from official docs on 2026-07-21, not aggregators. Batch and prompt-caching discounts, a cross-provider tier map, and a fully worked chatbot cost example.
Tokenizer Efficiency Benchmark.
An original, reproducible benchmark of 9 real tokenizers across English prose, code, and non-English text — measuring characters-per-token and encode speed, with a fidelity check that catches the trap where a lossy tokenizer looks “efficient” only because it silently drops characters it can’t represent.
The Forward Deployed Engineer: Role & Mindset.
The fastest-growing engineering title in AI, demystified: what an FDE actually does (owns the customer outcome, not the ticket), how it differs from a software engineer, solutions engineer, and consultant, the mindset shifts it demands, a week in the life, and how to break in.
Customer Discovery & Scoping for FDEs.
How FDEs find the real problem before building the wrong one: the wrong-problem tax, watching users instead of asking, the questions that surface truth, defining success as one number, scoping the smallest slice that proves value, and the red flags that mean a deployment will stall.
Customer Integration Patterns for FDEs.
Integration is where POCs die. The FDE playbook: the five integration families (REST/GraphQL, webhooks, files/SFTP, database/CDC, queues), auth into customer systems (API keys, OAuth, mTLS), reliability at the edge (idempotency, retries with jitter, webhook verification, dead-letter), and mapping messy customer data.
Rapid Prototyping for FDEs.
How FDEs build a convincing prototype in days, not months: throwaway-first thinking, the smallest demoable vertical slice, choosing a boring fast stack, faking the non-core parts honestly (hardcode / stub / Wizard-of-Oz), demo-driven development, and knowing when to throw it away versus harden.
Deploying in Customer Environments.
Ship where the customer can actually run it: the four deployment targets (your SaaS, the customer’s cloud/VPC, on-prem, and air-gapped), what changes as you move right — data egress, updates, model hosting, secrets, observability, and your own access — plus packaging portably and the air-gapped update path.
The Demo & Storytelling Playbook.
A demo is a performance, not a code review. How FDEs prep (their data, rehearse, a fallback recording), structure the story (open with the problem, show-then-explain, land the "so what"), recover from a live failure without debugging on stage, read the audience (exec / IT / user), and follow up while it’s hot.
Security & Compliance for FDEs.
Enough security to earn a customer’s "yes": what SOC 2, HIPAA, GDPR and PCI actually ask, how to handle data and secrets, what a security review checks, and the AI-specific risks (prompt injection, data leakage to model providers, PII in prompts) an FDE has to manage.
Solutions Engineering & Stakeholder Management.
The non-code half of the FDE job: mapping the room (champion, blocker, decision-maker, user), managing scope creep with a visible later-list, saying no kindly, setting expectations and surfacing risk early, and multi-threading so one person can’t sink the deployment.
From POC to Production: Hardening.
The gap between "it demoed" and "people depend on it": how FDEs harden a proof of concept into a real system — reliability (sad-path handling, idempotency, backpressure, validation), observability (structured logs, metrics, health checks), security and config hygiene, and the harden-versus-rebuild decision.
Handoff & Enablement for FDEs.
How FDEs hand off a deployment without becoming a permanent, unpaid support team: why the exit is the goal, what to hand off (runbook, docs, architecture, who-to-call), how to write a runbook that survives 2 a.m., enabling the customer’s team hands-on, and defining the exit up front.
Learning a Customer’s Domain Fast.
How FDEs get dangerous in a new field in a week: why domain fluency is a superpower, learning from the customer’s real data, running SME interviews that teach you (the naive-question license), building a glossary of their terms, finding the 80/20 of a domain, and how fluency compounds trust.
AI App Patterns for FDEs.
The AI toolkit a modern FDE deploys: RAG over the customer’s documents, agents that drive their workflows, and evals as the acceptance test — plus how to choose between prompting, RAG, agents, and fine-tuning, and how to ship AI honestly with a good-enough bar and a human in the loop.
Test-Time Compute & Reasoning Models.
Why letting a model think longer at inference — long chain-of-thought, sampling with self-consistency, best-of-N with a verifier, and search — can beat a much larger model on hard problems. How o1/o3- and DeepSeek R1-style reasoning models are trained to use a thinking budget, the train-time vs test-time scaling trade, and when spending the extra compute actually pays.
RL from Verifiable Rewards (RLVR).
The training technique behind modern reasoning models: reinforcement learning where the reward comes from a programmatic check (a unit test passing, a math answer matching) instead of a gameable learned reward model. How it differs from RLHF, the GRPO/PPO loop, why reasoning behaviors emerge in DeepSeek R1-Zero, and where verifiable rewards run out.
World Models.
What it means for AI to learn a predictive model of an environment it can imagine inside — the basis of model-based RL, planning, and controllable simulation. The three families (latent control models like Dreamer, generative interactive video like Genie/Sora, and JEPA), how a latent world model learns and acts in imagination, and the debate over whether video generators really understand physics.
GraphQL vs REST.
GraphQL vs REST, decided by who chooses the shape of the response: REST exposes many fixed resource URLs and the server decides what each returns; GraphQL exposes one endpoint and the client asks for exactly the fields it needs. Over- and under-fetching, HTTP caching vs the N+1 problem, versioning, and when each wins — plus why "REST services behind a GraphQL gateway" is so common.
MoE vs Dense Models.
Mixture of Experts vs dense LLMs, decided by which parameters fire per token: a dense model runs every parameter on every token; an MoE routes each token to a few expert sub-networks, holding far more total parameters but activating only a fraction. The compute win, the memory tax (all experts must sit in VRAM), load balancing, and when each wins.
Encoder vs Decoder Models.
Encoder vs decoder Transformers, decided by which way attention flows: an encoder reads the whole input at once (bidirectional) to build representations — great for classification, NER and embeddings (BERT); a decoder generates left to right (causal) — great for chat, code and agents (GPT). Encoder-decoder models like T5 do both. When to reach for each, and why real systems chain them.
Quantization vs Distillation.
Quantization vs distillation for shrinking LLMs, decided by what you change: quantization keeps the same model but stores its weights in fewer bits (FP16 → INT8/INT4); distillation trains a smaller student model to imitate a bigger teacher. One compresses the representation, the other the architecture — the quality-vs-size frontier of each, and why teams often distill then quantize.
Cross-Encoder vs Bi-Encoder.
Cross-encoder vs bi-encoder for semantic search, decided by when the query meets the document: a bi-encoder embeds query and document separately so document vectors precompute and scale to millions; a cross-encoder feeds them together for a far more accurate relevance score, but runs per pair at query time. Why production retrieval uses a bi-encoder to retrieve and a cross-encoder to rerank.
SQL vs Vector Database.
SQL vs vector databases, decided by the kind of question you ask: a relational database answers exact, structured queries over rows (WHERE price < 50); a vector database answers similarity queries over embeddings (find the items most like this). Exact filters vs approximate nearest neighbors, B-tree vs HNSW, pgvector, and why most real systems need both.
Batch vs Real-Time Inference.
Batch vs real-time (online) inference, decided by whether a human is waiting: batch processes many inputs together offline for maximum throughput and lowest cost per token; real-time answers one request at a time with low latency. GPU utilization, continuous batching, and why most AI products run both.
Orchestration vs Choreography.
Orchestration vs choreography for coordinating microservices, decided by where control lives: orchestration puts one central coordinator in charge of a workflow; choreography lets services react to events with no central controller. Central visibility vs loose coupling, the saga pattern, and when to use each.
Optimistic vs Pessimistic Locking.
Optimistic vs pessimistic locking, decided by how likely two writers collide: pessimistic locks a row before editing so others wait; optimistic edits without a lock and checks a version on write, retrying on conflict. Contention, deadlocks, retry storms, and when each wins.
TCP vs UDP.
TCP vs UDP, decided by whether every byte must arrive: TCP is connection-oriented and guarantees reliable, in-order delivery with flow and congestion control; UDP is connectionless and fires packets with no guarantees and almost no overhead. Head-of-line blocking, why real-time uses UDP, how QUIC/HTTP-3 gets both, and when each wins.
Process vs Thread.
Process vs thread, decided by whether they share memory: a process is an independent program with its own isolated memory; a thread runs inside a process and shares its memory. Isolation and safety vs cheap, fast, shared-memory concurrency — creation and context-switch cost, crash blast radius, the Python GIL, and when to use each.
Mechanistic Interpretability.
The engineer's guide to reading a model — interpretability as a debugger, not a séance. Why features live in superposition (not one per neuron), how sparse autoencoders pull monosemantic features back out, how attribution and circuit tracing find why a model did something (contribution of input i to output = the summed path weight W2·W1, validated causally by ablation), feature steering as a direct intervention, and an honest map of what you can debug today versus what is still research. Worked math plus a runnable 2-layer circuit tracer.
Agentic Payments.
How to let an agent pay without letting it drain your account. The x402 machine-native checkout (HTTP 402: server returns payment terms, agent pays and retries with proof), signed MANDATES that scope spending like OAuth scopes for money (AP2), and spend caps enforced BEFORE execution — authorize ⟺ amount ≤ per-txn AND spent+amount ≤ total AND merchant ∈ allowed. The runaway-agent threat and why the cap belongs in the payment layer, not the prompt. Worked math plus a runnable mandate-and-cap enforcer that stops a looping agent cold at its budget.
Diffusion LLMs.
Text generation that isn't one token at a time. Why autoregressive decoding is latency-bound (N tokens = N sequential passes), how block diffusion denoises B tokens in K steps to emit B/K tokens per pass (⌈N/B⌉·K total passes, speedup B/K) for reported 1,000+ tokens/sec, the crucial image-vs-text split (continuous Gaussian noise over pixels vs a discrete masking corruption over tokens), and the speed-quality knob (fewer steps = faster but more parallel-commitment error). Worked math plus a runnable AR-vs-diffusion pass counter.
Agent Supply-Chain Security.
The other door into your agent — the one you open yourself. Every skill and MCP server you INSTALL is third-party code running with permissions, an install-time threat distinct from runtime prompt injection. Why compromise risk compounds with dependency count (1−(1−p)^N: 20 deps at 5% each ≈ 64%), how blast radius = the capabilities a compromised component holds and least-privilege (grant = needed ∩ offered) bounds it, and the two levers — vet to lower p, sandbox to bound damage. Worked math plus a runnable risk-and-blast-radius model.
RL Environments Engineering.
The build side of verifiable rewards — the reasoning models everyone celebrates are taught by the ENVIRONMENT, not the algorithm. Why RL learns only from reward variance p(1−p) (zero signal when every attempt passes or fails, peak at a 50% pass rate) so tasks must sit in the difficulty band, why a gameable verifier corrupts training (precision = correct ÷ all rewarded; every false positive is a lie the model learns), and how to engineer difficulty curricula and verifier soundness. The theory of reward hacking lives in the verifiable-rewards handbook; this is how to build around it. Worked math plus a runnable learning-signal and verifier-precision model.
MCP Apps.
Interactive UIs inside Claude and ChatGPT — the first official UI extension to the Model Context Protocol. How a third-party UI runs as a SANDBOXED IFRAME (no ambient authority — can't touch the host DOM, storage, or network), why every capability call crosses a postMessage JSON-RPC bridge (method + params + id, response with the same id), and how the HOST MEDIATES each request against an allowlist (method ∈ allowlist ? execute : error −32601) so the app can only do what the host chose to expose. Sandbox + bridge + allowlist = the whole security model. Distinct from the MCP-server backend. Worked protocol plus a runnable host-mediation gatekeeper.
Self-Improving Agents.
Agents that get better from their own production traces improve on exactly two axes, with opposite properties. MEMORY: store a solved trajectory/skill for exact recall — instant to add and forget, but no generalization (a notebook). WEIGHTS: fine-tune on FILTERED correct traces — generalizes to unseen similar tasks, but bakes in what you trained on and is hard to reverse (a habit). Why you filter traces before training (a loop trained on its own confident errors drifts or collapses — same what-you-reinforce-is-what-you-get rule as RL), and the safety rails that follow from permanence: filter first, prefer reversible, canary before rollout, watch for drift/gaming. Cites STaR, Voyager, Reflexion as the mechanism family. Worked math plus a runnable memory-vs-weights model.
Long-Horizon Agents.
Why a 10-step task the agent nails becomes a 100-step task it never finishes — reliability COMPOUNDS: a single run of k steps succeeds with probability p^k (95% per step, 100 steps = 0.6%). The fix is engineering, not a better model: CHECKPOINT progress so a failure doesn't restart from zero, and RESUME + retry the failed segment only — a c-step segment retried r times succeeds 1−(1−p^c)^r, so the whole task climbs to [1−(1−p^c)^r]^(k/c), turning that 0.6% into ~51% at the same per-step reliability. The METR time-horizon idea and how reliability engineering extends it. The pass@k-vs-pass^k measurement lives in the agent-evals handbook (linked, not re-derived). Worked math plus a runnable no-checkpoint-vs-checkpointed model.
AI-Assisted Interviews.
The 2026 technical-interview FORMAT (distinct from the content handbooks): AI is now allowed in the room, so the exam shifts from writing algorithms from memory to working WITH AI — code-comprehension rounds, AI-fluency rubrics, and frontier-lab eval-design rounds. The one equation behind the shift: when the AI is correct with probability p, a reviewing human's value is pure review skill — final = p·(1−p_falsepos) + (1−p)·p_catch — so a skilled reviewer lifts output above the AI alone while a careless one (breaks correct code, catches little) drags it BELOW raw AI (an unskilled AI user is net-negative). The new round types and how to prepare (read/audit/test, not just write). Worked math plus a runnable reviewer-value model.
Autoregressive vs Diffusion LLMs.
Autoregressive vs diffusion language models, decided by how text is generated: autoregressive models emit one token at a time left-to-right, each conditioned on all previous; diffusion LLMs refine every position in parallel over a fixed number of denoising steps. Decode latency, KV cache, revisability, the quality gap, and where block diffusion fits.
Agent Skills vs MCP.
Agent Skills vs the Model Context Protocol, decided by what each adds: a Skill is packaged knowledge and procedure loaded into the agent’s context to change how it behaves; MCP is a protocol that grants live tools and data over a wire at runtime. Portability, token cost, security surface, and why the two compose rather than compete.
Vibe Coding vs Spec-Driven Development.
Vibe coding vs spec-driven development, two ways to build with AI: vibe coding is conversational and exploratory — prompt, run, keep what works; spec-driven development writes a precise spec first and has the agent implement against it with tests as the contract. The spec→plan→tasks→implement loop, where each breaks, and how to combine them.
Claude Code vs Codex vs Gemini CLI.
Three terminal-native agentic coding tools from Anthropic, OpenAI and Google that share one loop — read the repo, plan, edit files, run commands, iterate. How they differ on model, extensibility, openness and permissions, what the reported mid-2026 market numbers say (handled with care), and how to actually choose.
vLLM vs TGI vs SGLang.
Three open-source LLM serving engines that all do continuous batching but differ in their signature KV-cache trick: vLLM’s PagedAttention (removes fragmentation), SGLang’s RadixAttention (shares repeated prefixes), and TGI’s production-hardened Hugging Face integration. Where each wins, why "fastest" is a workload question, and how to choose.
The AI-Era Backend Engineer.
How the backend-engineer job changes in the AI era — and how to be the one who gets more valuable, not less. Boilerplate, CRUD and first-draft tests get cheap; system design, debugging, security judgment and production ownership become the moat. The new stack (reviewing AI code, spec-driven development, evals + cost/latency for LLM features), five AI-augmented workflows, a judgment exercise, and a 90-day plan.
The AI-Era Frontend Engineer.
How the frontend-engineer job changes in the AI era — and how to be the one who gets more valuable. Component scaffolding, CSS and markup get cheap; interaction and UX judgment, accessibility, performance and perceived latency, state architecture, and building AI-native interfaces (streaming, chat, copilot) become the moat. The new stack, five AI-augmented workflows, a judgment exercise, and a 90-day plan.
The AI-Era Product Manager.
How the product-manager job changes in the AI era — and how to be the PM who gets more valuable. PRDs, research synthesis and comms get cheap; judgment, taste, user truth and accountability become the moat, plus a new stack: evals literacy, the unit economics of AI features, and agent/AI UX. Five AI-augmented workflows, a judgment exercise, and a 90-day plan. The career companion to AI for Product Managers (tool literacy).
The AI-Era DevOps Engineer.
How the DevOps / platform-engineer job changes in the AI era. Pipeline YAML, Dockerfiles, boilerplate IaC and scripts get cheap; reliability, incident response, security, cost/FinOps and platform-as-product become the moat — plus a new stack: reviewing AI-generated infrastructure for blast radius, AIOps signal-vs-noise, and golden paths. Five AI-augmented workflows, a judgment exercise, and a 90-day plan.
The AI-Era Data Engineer.
How the data-engineer job changes in the AI era. SQL, pipeline glue and connector code get cheap; data modeling, quality and contracts, cost, lineage and the semantic layer become the moat — plus a new high-demand specialty: building the data pipelines that feed AI (RAG ingestion, embeddings, eval datasets). Five AI-augmented workflows, a judgment exercise, and a 90-day plan.
The AI-Era QA Engineer.
How the QA / test-engineer job changes in the AI era. Writing test scripts, selectors and boilerplate cases gets cheap; test strategy, exploratory testing, risk-based judgment, and the new discipline of testing AI and nondeterministic systems (evals, not assertEquals) become the moat. Five AI-augmented workflows, a judgment exercise, and a 90-day plan.
The AI-Era Engineering Manager.
How the engineering-manager job changes in the AI era. Status reports, summaries and first-draft reviews get cheap; people leadership, technical judgment, hiring and setting direction become the moat — plus a new mandate: leading AI-augmented teams and measuring output, not activity. Five AI-augmented workflows, a judgment exercise, and a 90-day plan.
AI for Designers.
A practical handbook on using AI in design: where it genuinely helps (exploring variations, first-draft copy and assets, synthesizing research you gathered) and where it must not decide (taste, brand coherence, accessibility, real user empathy). The three rules, five workflow recipes, a judgment exercise on IP and bias, and how to choose tools. No coding, no hype.
The New Grad in the AI Era.
A straight answer to “AI is killing junior roles — what do I even learn?” The junior grind (boilerplate, glue, first-draft tests) is being automated, so the bar shifts to fundamentals, judgment, and working WITH AI earlier — and you need fundamentals more, not less. What to learn now, five moves for your first months, a judgment exercise, and a 90-day plan.
AI for Support Engineers.
Support automation is the #1 deployed AI use case, so this role is changing fast. What AI automates (tier-1 tickets, FAQs, routing) versus what becomes valuable (hard troubleshooting, escalation judgment, empathy, and improving the AI itself), the new support stack, and the high-value pivots — agent-ops, AI-support engineering, and forward-deployed engineering. Five moves, a judgment exercise, and a plan.
AI for Data Analysts.
Text-to-SQL and auto-dashboards are automating the mechanical half of analysis. What AI automates (writing SQL, basic dashboards, pulling numbers) versus what becomes valuable (asking the right question, judging whether data can be trusted, interpreting results in business context, and defining what the metrics mean), plus the analytics-engineering escape hatch. Five moves, a judgment exercise, and a plan.
AI for Technical Writers.
AI drafts docs, generates API reference from code, and answers user questions directly — so fewer people read the docs at all. But the twist most miss: your documentation is now the context layer AI assistants, agents, and RAG systems read from, and an AI that reads wrong or unstructured docs gives confident wrong answers at scale. What AI automates (first drafts, boilerplate, formatting) versus what becomes valuable (information architecture, docs-as-context, docs-as-evals, owning the source of truth), plus the pivots — docs/DX engineering, developer relations, and AI knowledge engineering. Five moves, a judgment exercise, and a plan.
AI for Business Analysts.
AI drafts requirements docs, turns meeting notes into user stories, summarizes stakeholder calls, and writes the SQL for your reports. But the hard part of business analysis was never the writing — it was asking the right questions, resolving conflicting requirements, and deciding what is actually worth building. What AI automates (documentation, first-draft stories, process diagrams, basic queries) versus what becomes valuable (problem definition, stakeholder judgment, process redesign, validating that requirements match reality), plus the pivots — analytics engineer, AI product manager, and product owner. Five moves, a judgment exercise, and a plan.
AI for Technical Program Managers.
AI writes your status reports, summarizes the meeting, updates the tracker, and drafts the project plan — the reporting layer of program management is being automated. But the job was never the reports; it was driving cross-team execution, killing the risks that matter, and forcing decisions when senior people disagree. What AI automates (status, notes, trackers, first-draft plans) versus what becomes valuable (cross-org coordination, risk judgment, technical depth to challenge estimates, unblocking), how the TPM role differs from product management, and the pivots — engineering manager, product manager, and AI-program leadership. Five moves, a judgment exercise, and a plan.
AI for Scrum Masters.
An honest handbook, because this role is under more pressure than most: standups, sprint analytics, backlog grooming, burndown reports, and retro summaries are exactly what AI automates — and much of the pure ceremony-facilitation scrum-master job goes with them. But coaching a team, removing organizational impediments, resolving conflict, and driving actual delivery do not automate. What AI takes over, what stays valuable, and the honest pivots — delivery lead, technical program manager, engineering manager, and org-level agile coaching. Five moves, a judgment exercise, and a plan.
AI for Developer Relations.
AI drafts your blog posts, scaffolds tutorials, writes the sample code, and answers routine developer questions — and, bigger, developers increasingly ask an AI instead of reading your content at all. But that same shift creates two new high-value jobs only DevRel can do: making your product the answer the AI gives (GEO, llms.txt, docs-as-agent-context) and building the authentic community and trust no model can fake. What AI automates versus what becomes valuable, and the pivots — product marketing, product management, docs/DX engineering, and AI-visibility (GEO) specialist. Five moves, a judgment exercise, and a plan.
AI for Founders.
AI collapses the cost of building — one person or a tiny team can now ship what used to take a whole engineering org. That is real leverage, but it cuts both ways: when everyone can build, building stops being the moat. What AI makes cheap (code, MVPs, first-draft everything, research) versus what becomes scarce and decisive (taste on what to build, distribution, a real wedge, customer truth, and judgment on what NOT to build), how to use AI leverage without fooling yourself, and where to place your bet. Five moves, a judgment exercise, and a plan.
AI for Game Developers.
AI generates concept art, textures, 3D assets, boilerplate gameplay code, dialogue drafts, and procedural content — and it is reshaping game production faster than almost any creative field, asset pipelines first. What AI automates (asset production, boilerplate, first-draft narrative, playtest analysis) versus what becomes valuable (game design and game feel, original creative vision, knowing what is actually fun, and building AI into the game itself), plus the pivots — technical game designer, AI-gameplay engineer, and AI-leveraged indie. Five moves, a judgment exercise, and a plan.
Career Switch to Tech.
Switching into tech got harder and easier at the same time, and pretending otherwise helps no one. Harder: AI now does a lot of the junior work, so the old learn-to-code-and-get-hired path is tighter and credentials count for less. Easier: AI lets a career-switcher build real, working things fast — and a portfolio of real things now beats a certificate. What changed, why your prior-career domain knowledge is an edge, how to aim above the fully-automatable entry rung, and a concrete plan. Five moves, a judgment exercise, and a realistic path.
The AI Consultant.
Every company wants to adopt AI and most don't know how — the opening for AI consultants and freelancers. But building a demo is cheap; the value is positioning yourself in a specific niche, scoping projects that actually deliver, pricing on value instead of hours, and shipping real outcomes rather than prototypes that die in production. What is cheap versus valuable in AI consulting, the rules of positioning and scoping, and how to price and deliver. Five moves, a judgment exercise, and a plan.
AI for Network Engineers.
AI and automation are eating the manual half of network engineering — per-device CLI config, routine changes, first-pass log analysis, and memorized command syntax. What gets automated versus what becomes valuable (network architecture and design, the hard cross-layer troubleshooting, security posture, and owning network-as-code), how AIOps changes operations, and the strong pivot into network automation and NetDevOps. Five moves, a judgment exercise, and a plan.
Blockchain to AI.
A skills-transfer map for blockchain and crypto engineers moving into AI. Far more transfers than you'd guess: distributed systems, rigorous correctness, cryptography, working at scale, and incentive design are exactly what AI infrastructure needs — and skills most ML-first engineers lack. What carries over and where it applies, what you genuinely need to learn (ML fundamentals, the LLM/RAG/agent stack), how to target the systems-and-infra overlap, and a concrete plan. Five moves, a judgment exercise, and a transition path.
What Is a Forward Deployed Engineer?
The pillar definition, with sources: an FDE owns the full arc of a deployment inside the customer’s environment. The three species of the role (builder / pre-sales-shaped / internal), why postings grew 729% in a year, who hires, what the bar really is, and whether the title survives its own hype.
FDE vs Every Adjacent Role.
One master table placing the Forward Deployed Engineer against eleven adjacent roles — software engineer, AI engineer, solutions engineer, architect, consultant, PM, DevOps, data engineer, SRE, TAM, customer success — on environment, ownership and comp shape, then the four deep comparisons and a four-check test for reading any job ad.
FDE vs Software Engineer.
Same code, different physics. The ownership asymmetry that rewrites everything, two calendars side by side, why FDE comp is higher but far wider, what transfers from product engineering and what has to be built new, and honest checklists for switching in either direction.
FDE vs AI Engineer.
Identical toolbox — RAG, agents, tool schemas, evals — but the AI engineer’s hard problem is the model and the FDE’s is the organisation around it. Where Applied AI Engineer and Agent Engineer land, negotiated evals as the skill that separates them, and how comp, ceiling and exits differ.
FDE vs Solutions Engineer & Architect.
One question separates all three: after signature, who is accountable for what runs in production? Includes the 30-second test that reveals a relabelled pre-sales posting, one enterprise deal followed phase by phase, and the production-engineering gap to close if you are moving over from pre-sales.
FDE vs Consultant.
Is forward deployed engineering just consulting with better branding? Three things genuinely separate them — running software, a product feedback loop, and equity — and each can quietly disappear. The services trap, four interview questions that detect it, and what FDEs should steal from consultants anyway.
Forward Deployed Engineer Salary, Explained.
Why the public numbers differ by seven times, reconciled: base versus total comp, six employer tiers from frontier labs to defense integrators, the level ladder and what earns each rung, six questions for reading an offer, and the equity structure that makes most of the package an estimate about the future.
How to Become a Forward Deployed Engineer.
The concrete route in: the real bar (staff-level judgement, not SWE-lite), six skills in dependency order, the one portfolio artefact that beats everything else, a 12-week plan, what to do coming from support / consulting / no degree, and an honest verdict on paid FDE courses and certifications.
Is Forward Deployed Engineering Worth It?
The honest version. Five named costs — coding atrophy, travel, accountability without control, the services trap, and a specific kind of burnout — each with the version of the job where it does not happen. Then the exits ranked by how naturally they follow, and eight questions that buy you out of the costs.
A Day in the Life of an FDE.
Hour by hour, built from the published first-hand accounts: a customer-site day, a remote build day, and a launch-week day — plus how the 40/30/30 split actually swings across discovery, prototype, hardening and handoff phases of a single deployment.
FDE Interview Prep: The 9 Rounds.
The complete Forward Deployed Engineer interview guide — decomposition, learning round, incremental coding, debugging/re-engineering, take-home + defence, client roleplay, values, customer-flavoured system design and behavioural ownership. What each scores, the five signals every company screens for, a four-week plan, and an interactive drill for every round.
The Palantir FDSE Interview.
The loop that every other company copied: the online assessment, the panel drawn from a pool of five round types, and the decomposition round minute by minute — what strong candidates do in the first five minutes versus what fails. Plus the FDSE / Deployment Strategist split and a two-week prep plan.
The OpenAI FDE Interview.
How the reported OpenAI forward deployed engineer loop works: the multi-hour API take-home, the required video walkthrough where it is actually graded, and the case/empathy rounds that carry roughly half the evaluation — with six habits that win the take-home.
The Anthropic Applied AI / FDE Interview.
The most agent-shaped FDE role at a frontier lab: the escalating-constraint coding assessment, the deployment case where negotiated evals win it, and the values round that candidate reports call the highest-failure stage — plus exactly how to prepare for it.
The Sierra Agent Engineer Interview.
Live incremental coding, a support agent you must build without an agent framework, and a debugging onsite with planted bugs. Why the no-framework constraint is the cleanest signal-extraction device in any published FDE loop — and the six decisions frameworks hide from you.
The Distyl AI Interview (AI Allowed).
One of the few companies that publishes its interview philosophy: use AI in the take-home, then defend everything it produced. The three anti-patterns they reject — Autopilot, Default and Demo — and a phase-by-phase split of what stays human when AI is permitted.
The FDE Take-Home Playbook.
Take-homes are the centre of gravity in modern FDE loops and they are graded on judgement, not volume. The five-phase method with time budgets, what graders actually weight, a deliberately ambiguous five-hour practice spec, a 30-point self-scoring rubric, and how to prepare the video defence.
Evals for Client Work.
The most-cited hard skill in frontier-lab FDE job descriptions and the least taught anywhere: turning “it should be accurate” into a gate. Measure inter-expert agreement before you promise a number, build a golden set that survives contact, calibrate an LLM judge against human grades, wire the CI gate (including the per-case regression check), and hand the whole thing over.
Proving Value & ROI.
Roughly 95% of enterprise AI pilots showed no measurable P&L impact — and “measurable” is doing the work in that sentence. Capture the baseline in week one, agree one number, instrument adoption and override rate, survive the three standard ROI objections, and run the 45-minute business review that decides the renewal.
Incidents, On-Call & SLAs for FDEs.
Production in an environment you do not own: negotiating an SLA whose clock starts when you are paged (not when a user noticed), surviving a one-person rotation, running an incident when logs cannot leave their network, writing a post-mortem with the renewal decision-maker in the room, and engineering your way out of the rotation in four milestones.
Enterprise Identity for FDEs.
The layer that blocks more enterprise deals than model quality ever will. SAML vs OIDC and when the customer decides for you, SCIM deprovisioning (a PATCH setting active to false, not a DELETE), group-to-role mapping that survives a reorg, workload identity instead of a static key, and the five artefacts a security reviewer will ask you for.
The Commercial Layer for FDEs.
The part nobody teaches: reading a SOW before you are bound by it, the six clauses that cause all the pain, four pricing models and what each does to your week, telling a customer need from a rep’s quota, the services-trap arithmetic, and the renewal that starts nine months early.
MCP for FDEs.
Anthropic’s FDE job description names MCP servers as a deliverable. Designing a tool surface a model can actually use, wrapping a 2009 SOAP service and a stored procedure as tools, putting the code-to-word vocabulary in the server, and the four trust-boundary questions between customer data and a model that reads anything.
Air-Gapped & Regulated Deployment.
Five things customers mean by “air-gapped”, FedRAMP and DoD impact levels explained for engineers, the eight-step path model weights take into a disconnected network, update cadences set by a change board rather than your CI, and why evals are the first thing that breaks when telemetry cannot leave.
IaC for Customer Environments.
Terraform and Helm when the account, the cluster and the change process all belong to someone else: who holds state, the seven things a no-egress VPC breaks at runtime, referencing secrets you must not read, and the clean-room rebuild that is the only honest test of a handover.
Applied AI Engineer, Explained.
“Applied” does not mean applied research — it means the model meets a real customer’s systems and you are standing where that happens. The published 40/30/30 split, how the title differs from AI engineer and ML engineer, the five badge variants in the family, and the two questions that identify any of them.
FDE vs FDSE vs Deployment Strategist.
Palantir split forward-deployed work into an engineering ladder and a strategy ladder; most companies copied the title and not the split, which is why one word now means two jobs. What each role owns, how the loops diverge, and the career mistake this comparison exists to prevent.
AI Solutions Engineer.
The engineer on the other side of the signature. Roughly a third of FDE-family postings are pre-sales-shaped: what that means across the deal cycle, how OTE changes which customers you spend time on, why “how accurate is it?” must not be answered with a number, and the four questions to ask before accepting.
The FDE Canon.
Ten sources that actually explain the role — first-hand accounts, job descriptions read as documents, the commercial argument, and the market data — each with what to take from it and what it is silent about. Read in this order, and note honestly what is missing: almost nothing good exists on identity, security review, the commercial layer or evals.
ML Fundamentals.
The seven concept pairs every practitioner is expected to have straight — how machines learn, what they predict, the two ways they miss, which mistake you can live with, how you validate, how you ensemble, and what a model is really modelling. Worked confusion matrices, real fold scores, and the failure mode behind each one.
How Programming Languages Actually Work.
Four questions of timing: when your code gets translated, when type errors get caught, what actually gets copied on a call, and what a stack frame costs. Compiled vs interpreted, static vs dynamic typing, pass by value vs reference, and recursion vs iteration — with the bug each one causes in real code.
Handbooks — frequently asked questions
Are the handbooks free to read?
Yes. Every handbook is free, full-length, and self-contained — no paywall, no sign-up, and no email required to read any of them.
Who writes these handbooks?
They are written by Saurabh Singh, a senior AI engineer, based on real production experience building agentic AI systems, evals, and large-scale services — not generic content.
What topics do the handbooks cover?
They span agentic AI and LLM engineering (prompting, RAG, evals, agent evaluation), AI-engineering interview prep, system-design fundamentals, and language-specific interview guides for Angular and Python.
Are these handbooks good for interview preparation?
Yes. Several are built specifically around what interviewers probe for at senior and staff level — the LLM, Senior AI Engineer, Angular, and Python handbooks are structured as the exact questions and reasoning those interviews test.
How long does each handbook take to read?
Most take between 40 and 75 minutes, shown as an estimated read time on each card. They are designed to be read in one focused sitting, with interactive widgets and quizzes to reinforce the material.
Something missing?
If there's a topic you'd like covered, send it through. Genuine requests shape what gets written next.