How They Will Test You

Dissecting Grok Build · 30 Soul-Searching Questions

Chapter 6 dissects real source code, and its questions are the most demanding. If you say you understand Coding Agents, these 30 questions are the litmus test — try answering aloud first, then check the framework.

How to Use This Page
Each question is labeled with the questioner. This chapter leans toward low-level engineering — technical colleagues have the biggest role, and their questions are the most unforgiving.
🎙 InterviewerWants to verify whether you truly understand or are just reciting buzzwords
👔 BossWants explanations and commitments
🛠 Technical ColleagueTesting whether you are worth trusting
Each question has three layers: What the questioner is examining → Answer framework → Bonus points. For any part you can't answer, click the linked lesson pages at the end to review.
Q1Technical Colleague
"You keep talking about Coding Agents — what exactly happens in one loop cycle? Don't give me the PowerPoint version."
🎯 What they're assessing
Testing whether you treat the Agent as a black box or truly understand the runtime. A one-liner like "it's just an LLM + tool loop" gives you away. The questioner wants to hear you trace the call chain and clearly explain the roles of the key components.
🧭 Answer framework
  1. Start from the entry point: Using Grok Build as an example, the real entry is main(), dispatching to run branches (headless, stdio, leader, interactive TUI), all converging in the same Agent host.
  2. Three Actor roles: SessionActor handles turn orchestration — receiving commands, starting pending turns, handling completion notifications; ChatStateActor exclusively owns conversation state; SamplerActor manages streaming model requests.
  3. Isolation unit: Each Session runs on a dedicated OS thread with its own current-thread Tokio runtime and LocalSet. Sessions are naturally isolated — one hanging cannot drag down another.
  4. Teardown mechanism: When the user hits Stop, CancellationToken enables cooperative termination; each Actor exits in order. This is the cancellation boundary.
⭐ Bonus point If you can say "conversation state is serially owned by ChatStateActor via a message queue, so no shared locks are needed," your technical colleague will immediately know you've really read the architecture — and their attitude toward collaboration will change.
Organize your answer using these lesson pages → From main() to the First Sampling Round Session Actor & Cancellation Boundary 79 Workspace Members
Q2Interviewer
"Coding Agents easily run dozens of turns and the context fills up fast. How does a production product handle that?"
🎯 What they're assessing
Testing your engineering understanding of context budgeting. Someone who can only say "compress the history" gives themselves away — the questioner wants to hear about trigger thresholds, decision logic, and budget control: the mechanisms that separate a demo from a real product.
🧭 Answer framework
  1. Start with the trigger mechanism: In Grok Build, automatic compaction is allowed by default when context usage reaches 85%. The decision formula is used × 100 >= context_window × threshold_percent — pure integer comparison.
  2. Compaction itself must be time-limited: A single compaction has a 300-second wall-clock budget. Compaction is meant to save the session; if compaction itself spirals out of control, that defeats the purpose.
  3. Explain optional capabilities: memory flush and two-pass are both off by default. With two-pass enabled, the system speculatively summarizes the historical prefix in the background as it approaches the threshold, then merges that summary with the recent tail during formal compaction.
  4. Elevate one level: All of this is contained in a single explicit configuration object, CompactionPolicy — threshold, compaction model, and budget are all tunable. Production systems make policy configurable; demos hard-code policy into the code.
⭐ Bonus point Proactively note that Token usage is an estimate, the threshold comparison uses saturating multiplication to prevent overflow, and the function returns false directly when the window is 0. Being able to discuss these edge cases shows you've read the real implementation — extremely rare among PMs.
Organize your answer using these lesson pages → Compaction: 85% Threshold & Two-Pass Estimation, Percentages & Strict Thresholds
Q3Interviewer
"If you were designing a tool set for a Coding Agent with dozens of tools, how would you manage them? Which ones can run automatically, and which ones need user approval?"
🎯 What they're assessing
Testing tool system design capability. Someone who immediately says "configure permissions for each tool individually" gives themselves away — that's completely unworkable with dozens of tools. The questioner wants to hear about taxonomy, default semantics, and layered control as a systematic approach.
🧭 Answer framework
  1. Start with taxonomy: Grok Build uses a ToolKind enum to assign semantic categories to tools. Categories like read file, search, and web scraping are read-only by default; edit, delete, and execute command have side effects by default.
  2. Defaults are overridable: is_read_only() is just the category-level default semantic; individual tools can override it with their own metadata — category and instance are decoupled.
  3. Clarify the key boundary: A read-only category does not imply "auto-execute." Final authorization also passes through command rules, sandbox, Hook, and user-interaction approval — the category is just the first input to the decision.
  4. Add the registration mechanism: Built-in tools use a static registry; external Toolsets use process-level Preset registration; MCP tools are dynamically discovered at runtime. All three sources converge at a single point — that's how management costs stay manageable.
⭐ Bonus point Cite Task as a counterexample: sub-tasks sound harmless, but the source code marks them as non-read-only because child Agents can execute write operations. Being able to articulate this boundary case shows you really went through the classification table.
Organize your answer using these lesson pages → ToolKind & Read-Only Semantics Toolset Preset Registry Implementation Families, Registry & Dynamic MCP
Q4Technical Colleague
"Agent memory is basically just storing chat history in a file and grepping it when needed, right?"
🎯 What they're assessing
A provocative question testing how much you know about retrieval engineering. Agreeing with "pretty much" is a trap. The questioner wants to hear about the recall pipeline, fallback strategy, and ranking details — these determine whether a memory system is actually useful.
🧭 Answer framework
  1. First correct the premise: Production-grade memory is a retrieval pipeline. In Grok Build, dirty files are synced before querying: a watcher monitors Markdown changes and rebuilds the relevant index when search begins, so external edits are not lost.
  2. Dual-path recall: FTS5 BM25 keyword search is always available; vector KNN (sqlite-vec) is layered on when embedding is available. If embedding fails, only a warning is logged and the system automatically degrades to FTS-only — the search returns normally.
  3. Ranking matters: Scores from both paths are independently normalized, then merged with weights, multiplied by time decay (session memories decay by half-life; global and workspace memories are treated as evergreen), source weight, and access boost.
  4. Optional diversity: MMR re-ranking is off by default; when enabled, a greedy re-rank by relevance and snippet diversity is applied, then truncated to max_results.
⭐ Bonus point Add: "There's also a background Dream mechanism: triggered by idle gating, using DreamLock to prevent concurrency, consolidating memories in the background and writing them back." This shows the memory system has both reads and write maintenance — you see the complete closed loop.
Organize your answer using these lesson pages → From File Changes to Hybrid Ranking The Real Mechanism of Dream Token Estimation & Thresholds
Q5Boss
"You want to roll out Coding Agents company-wide? If it deletes the codebase or leaks the source code, who is responsible?"
🎯 What they're assessing
Testing expectation management plus mechanism understanding. Those who promise "absolutely safe" are the most dangerous; just saying "there's a sandbox" isn't enough either. The questioner wants to hear a concrete layered defense plan and whether you dare to honestly disclose the limits.
🧭 Answer framework
  1. Lead with the conclusion: Risk is manageable — the core is kernel-level sandboxing. Grok Build includes five built-in Profiles: workspace (default), devbox, read-only, strict, and off, each defining capability sets for file read/write and subprocess networking.
  2. Explain the mechanism: Constraints are enforced at the OS level — macOS uses Seatbelt, Linux uses Landlock. The real boundary is the parsed capability set; the Profile name is just a direction.
  3. Provide a rollout plan: Assign Profiles by role. Use read-only for code review, strict for highly sensitive repositories, and custom profiles to additionally deny directories like ~/.ssh. Project config cannot silently override a global policy of the same name — the security floor is in the administrator's hands.
  4. Be honest about limits: When the platform does not support sandboxing or application fails, the sandbox logs a warning and continues. Therefore, layered defense requires stacking permission approval and Hook auditing — no single silver bullet; responsibility is shared through policies and mechanisms.
⭐ Bonus point Proactively distinguish the two layers: Hooks are fail-open — if a Hook itself crashes, the tool keeps running, so Hooks are only suitable for alerts and auditing; hard guarantees must go in the permission layer and sandbox. Very few people can articulate this clearly.
Organize your answer using these lesson pages → Five Sandbox Profiles From Tool Request to Restricted Execution Hooks: Only an Explicit deny Blocks
Q6Technical Colleague
"Integrating an MCP Server is just adding two lines of config, right? Why did you schedule a whole iteration for this?"
🎯 What they're assessing
A reverse probe testing your judgment of ecosystem integration engineering effort. A PM who thinks "the protocol works, we're done" will inevitably blow their schedule. The questioner wants to hear about all the messy work surrounding the protocol — the more specific you are, the more convincing your schedule.
🧭 Answer framework
  1. First align on the role: Grok Build is an MCP client that must support both stdio and Streamable HTTP transports, plus OAuth: credentials are stored in a local JSON file, and file locking with atomic writes prevents multi-process conflicts.
  2. Naming and conflicts: Tool registration names follow the pattern server__tool with exactly one double underscore. When two servers each have a tool with the same name, each gets a different ToolId — preventing collisions on the model side.
  3. Visibility routing: Too many tools cannot all be stuffed into the Prompt. Disabled tools, UI-only tools, and model-visible tools are handled in three separate paths; a snapshot plus BM25 index lets the model search for tools on demand.
  4. Reconnection recovery: State events are coalesced within a 50 ms window; stdio reconnects with 1s, 4s, 16s backoff; a client_id guard prevents disconnect events from stale connections from accidentally removing new connections.
⭐ Bonus point One-sentence close: the engineering effort in MCP integration is concentrated around the protocol periphery — naming, visibility, identity, state coalescing, and recovery strategy determine whether a connection is long-term stable. That is why it takes a full iteration; your technical colleague will spontaneously add detail after hearing this.
Organize your answer using these lesson pages → MCP Connection, Discovery & Recovery Dynamic MCP Tools Plugin Marketplace & Trust
Q7Interviewer
"You've studied Grok Build's source? Then tell me, why did xAI choose Rust? Give me a definitive answer."
🎯 What they're assessing
This question has a trap: a "definitive answer" simply doesn't exist. The questioner is watching whether you have evidence-boundary awareness — whether you'll package a reasonable explanation as official fact. Anyone who immediately speaks for xAI's motives will water down competitive analysis the same way.
🧭 Answer framework
  1. Set the rules first: Split conclusions into two labels — "source-code facts" and "course inferences." What the source can prove: edition set to 2024, Tokio 1 with the full feature enabled, a native bin target named xai-grok-pager, and the LTO and panic settings in release-dist.
  2. Then give the inferences: A native binary makes it easy to ship the CLI and runtime together; ownership and Send boundaries help manage multi-threaded sessions; strong typing fits complex protocols and state transitions. These are explanations based on the shape of the code — mark them as inferences.
  3. Call it out directly: The organizational motive behind the choice is not written into the source. A line like "xAI chose Rust for performance" has no repository evidence, so I won't say it.
  4. Elevate one level: This chapter's comparison table uses a four-level evidence grading: source code, repository docs, official public docs, and local snapshot observation. Cells without enough evidence stay blank — we don't fill them with speculation.
⭐ Bonus point What the interviewer wants is exactly step 3. Daring to say under pressure "the source code cannot answer this" is worth far more than inventing a pretty answer — that's a PM's evidence literacy.
Organize your answer using these lesson pages → Rust Selection: Facts and Inferences Evidence-Based Comparison Engineering Retrospective & Evidence Boundaries
Q8Technical Colleague
"What's the point of writing an Agent in Rust? Compiles forever, and hiring is hard. I can slap one together in TypeScript in two weeks."
🎯 What they're assessing
Testing whether you're cheerleading Rust because it's trendy, or can name verifiable engineering gains. Also watching whether you dare to admit the costs — a PM who only praises and never discusses trade-offs will not get genuine cooperation from the engineering team.
🧭 Answer framework
  1. Own the costs first: Compile time, lifetime constraints, and the learning curve are all real costs. The source-code lessons label them that way too — no need to bluff.
  2. Give verifiable gains: Each Session runs on a dedicated OS thread plus a current-thread runtime; ownership and Send boundaries keep multi-threaded session state from depending on discipline; enum plus Result builds the domain boundaries of Agent, Session, and Sampler into the types.
  3. Give a hard example: ALL_TOOL_KINDS has a compile-time assertion — if the length doesn't match the ToolKind enum count, compilation fails. Adding a new tool kind forces you to re-walk the permission-routing decisions. That kind of constraint is very hard to catch with code review alone.
  4. Close: A native binary ships the CLI and runtime together — users don't install dependencies. What you slap together in two weeks is a demo; this is a product.
⭐ Bonus point Add that claims like "multi-threading is necessarily faster" lack repository evidence and belong in the inference column. Once your technical colleague sees you holding the evidence boundary even on your own position, their attitude changes immediately.
Organize your answer using these lesson pages → Rust Selection: Facts and Inferences Session Actor & Cancellation Boundary Engineering Retrospective & Evidence Boundaries
Q9Interviewer
"The same read-file tool has several implementations in your code. You call this architecture? How many times do I have to fix the same bug?"
🎯 What they're assessing
Testing code organization for multi-protocol compatibility. The questioner deliberately frames "implementation families" as duplicated code, to see whether you can explain this as namespace isolation, plus the full pipeline from tool definition to execution.
🧭 Answer framework
  1. First set the record straight: These are implementation families split by protocol. xai-grok-tools holds in parallel the grok_build main product family, the grok_build_concise compact family, grok_build_hashline, and the codex and opencode compatibility families; memory, lsp, and skills are split into their own modules by capability; the namespace enum also has MCP reserved for runtime external tools.
  2. Assembly has a pipeline: ToolRegistryBuilder handles implementation selection and parameter renaming; finalize(config, context) produces a FinalizedToolset containing definitions, resources, and dispatch.
  3. Sessions connect through one door: ToolBridge holds the registry, supplies tool definitions to the model, and returns results to the session as ToolOutput. MCP tools are registered into the same registry at runtime via register_mcp_tools, sharing the execution channel with built-in tools.
  4. Answer the challenge: Compatibility with another harness is a configuration problem of swapping one implementation family. If every protocol truly shared one copy of the code, the compatibility logic would turn every tool into a forest of ifs — that is when you'd fix the same bug several times.
⭐ Bonus point Distill one layering line: implementation families solve code organization across protocol sets; the registry handles composition and runtime registration; ToolBridge connects the session. Each of the three layers owns one job. When you add support for a new protocol family, the execution path doesn't move a single line.
Organize your answer using these lesson pages → Implementation Families & Dynamic MCP ToolKind & Read-Only Semantics
Q10Boss
"The subscription costs tens of thousands a year — why don't we just write our own Coding Agent? Give me an assessment: can we ship in two months?"
🎯 What they're assessing
Testing engineering-effort judgment and expectation management. Chest-thumping "yes we can" and a flat refusal both fail. The boss wants an assessment with numbers, dimensions, and alternatives.
🧭 Answer framework
  1. Start with the scale: Grok Build's Cargo Workspace alone has 79 members, 62 of them under the codegen directory. That's the real volume xAI reached at production grade. Two months gets you a demo.
  2. Break it into nine dimensions: The finale workbench lists nine decision dimensions: entry point, state concurrency, model streaming, tool contracts, context and memory, security, recovery, observability, and the extension ecosystem. Each dimension needs a contract, a failure path, and a verification method.
  3. Give the decision criteria: Pick two of the five hard constraints and ask yourself: After a crash, can it recover in an explainable way? Can you account for where sensitive data lands? If you can't answer, it shouldn't ship.
  4. Give a recommendation: Run a mature product for six months first, crystallize our real permission, audit, and recovery needs, then evaluate which layer to build in-house. Full-stack in-house is rarely worth it; in-housing one layer might be.
⭐ Bonus point Proactively note that the Grok Build repo is Apache 2.0 — you can study and build from it. But it is periodically one-way synced from an internal monorepo and does not accept external PRs. Don't treat it as a ready-made community base.
Organize your answer using these lesson pages → 79 Workspace Members Coding Agent Design Workbench Engineering Retrospective & Evidence Boundaries
Q11Interviewer
"How do you manage your product's system prompt? When weird behavior shows up in production, how do you figure out which instruction caused it?"
🎯 What they're assessing
Testing engineering management of the prompt. Anyone who answers "we maintain one big string template" is still at the workshop stage. The questioner wants a structured, inspectable, replayable approach.
🧭 Answer framework
  1. Give a structured answer: Grok Build uses a PromptContext struct to hold all rendering inputs, with Serialize and Deserialize derives, so it can be serialized as a whole for inspection. What you debug is data — less guessing.
  2. Fields come in three groups: Version and template (version, prompt_mode, audience, build_timestamp_utc); configuration and identity (agents_md_files, persona_summaries, role_instructions, memory_enabled); user runtime environment (os_name, shell_path, working_directory, current_date).
  3. Rendering responsibilities: TemplateOverride decides the base template; ToolBridge supplies tool state and descriptions; TemplateRenderer composes the sections and outputs the final system prompt.
  4. Update boundary: After the Agent is built, a source comment calls it "effectively immutable," but finalize_prompt is kept as an explicit entry point — it updates the build timestamp and re-renders.
⭐ Bonus point Point out that "serializable rendering input" is the key to debugging prompt incidents: any session's prompt can be restored as a structured document, so replay and diff both have a handle.
Organize your answer using these lesson pages → PromptContext Rendering Input Agent Field Boundaries
Q12Interviewer
"The main session has one Prompt, sub-Agents have another, and you also need to stay compatible with other tools' formats. How do you design the template system so it doesn't spiral out of control?"
🎯 What they're assessing
Testing a productized approach to multiple templates. Anyone who answers "just write a few more template files" hasn't thought about the runaway problem. The questioner wants a design that converges on a finite enum plus an escape hatch.
🧭 Answer framework
  1. Give the enum: Grok Build's TemplateOverride has only three variants: None, Codex, Custom(String), defaulting to None. Template selection is collapsed into a single enum field.
  2. None still has two sets: Primary sessions use the standard base template; Subagents use the corresponding compact template, saving tokens for child sessions.
  3. Codex is a compatibility slot: The source comment defines it as the apply-patch profile template, paired with the compatibility implementations in the codex family — apply_patch, read_file, list_dir — serving another tool protocol.
  4. Custom is the escape hatch: The caller supplies a complete template string directly, covering cases the enum can't.
⭐ Bonus point Point out that templates and tools switch as a pair: when you switch to the Codex template, tools switch to the matching compatibility implementations. Swap only the Prompt half and what you get is a Frankenstein.
Organize your answer using these lesson pages → TemplateOverride's Three Variants Implementation Families & Dynamic MCP
Q13Technical Colleague
"I registered a custom toolset preset exactly as the docs say, and the current session still can't find it. Your platform design has a bug, right?"
🎯 What they're assessing
A blame-shifting question. Testing whether you understand the registry's timing semantics and visibility design — whether you can recast the other person's "bug" as a design with a clear reason, and give a debugging path.
🧭 Answer framework
  1. Give the structure first: The registry is process-level: OnceLock plus Mutex wrapping a HashMap, storing a mapping from name to builder function and visibility. The builder is a function pointer fn() that returns ToolServerConfig, invoked only at parse time to produce the config.
  2. Explain the timing: Already-parsed configs are not written back. If you register after a session's config has been parsed, that session won't see the new preset; only configs parsed afterward will. The source comment explicitly recommends finishing registration before the first parse.
  3. Check visibility: register_toolset_preset registers as Public and enters the preset_names public enum; register_internal_toolset_preset is Internal — it can only be resolved by name and doesn't show up in the enum. Validating an Internal preset via the enum will be misread as "it never registered."
  4. Give the conclusion: This is a startup-consistency design. If late registration could silently mutate already-parsed session config, that would be the real bug.
⭐ Bonus point Give the debugging mantra directly: first confirm which registration function was called, then confirm whether registration happened before or after config parse. Nine out of ten problems sit in those two places. Technical colleagues eat up answers that sound like "you know this better than I do."
Organize your answer using these lesson pages → Toolset Preset Registry
Q14Interviewer
"Different tools have all kinds of parameter names — file_path, path, directory mixed together. If you need cross-tool display and data analysis, what do you do?"
🎯 What they're assessing
Testing normalized-contract design. "Write a mapping table" is only the start. The questioner wants to hear how the stable projection and the raw data divide the work, and how the contract evolves.
🧭 Answer framework
  1. Give the approach: Grok Build projects a small set of stable semantics into x.ai/tool metadata. There are only eight canonical fields: path, offset, limit, command, description, cwd, directory, pattern.
  2. Give the contract: CanonicalToolMeta has seven fields: version, name, kind, namespace, label, read_only, input. TOOL_META_VERSION is the number 1. Display, telemetry, and cross-tool analysis share this vocabulary.
  3. Draw the boundary: input is a projection — fields can be missing, or the whole thing omitted. Non-shared fields like grep flags and replace_all are dropped; large fields like before/after edit text don't enter the projection. Full data stays in raw_input.
  4. Explain the trade-off: The projection layer aims to be stable and lightweight — better fewer fields than inconsistent semantics across tools. If you need the full payload, go back to raw_input.
⭐ Bonus point The version field is a door left open for contract evolution: today it's 1; when field semantics change later, consumers can branch by version. That's basic data-contract craft — saying it is a dimensional advantage.
Organize your answer using these lesson pages → Canonical input Stable Projection ToolKind & Read-Only Semantics
Q15Interviewer
"Compaction only triggers at 85% — what if a single tool output blows the context in one shot? What backs your budget mechanism?"
🎯 What they're assessing
Testing boundary thinking beyond the threshold. Anyone who only remembers the number 85% can't answer this. The questioner wants reserved headroom, estimate sources, and defensive details.
🧭 Answer framework
  1. Give the three primitives first: xai-token-estimation provides usage_percentage (returns 0 when total is 0, capped at 100), exceeds_threshold (integer cross-multiply: used × 100 >= window × percent, equality triggers), and exceeds_threshold_with_headroom.
  2. headroom is the backstop: Reserve a fixed token space before the percentage threshold. With a 100,000 window, 85% threshold, and 4,000 headroom, the trigger moves from 85,000 forward to 81,000, leaving buffer for large outputs.
  3. Estimates come from two paths: Before the request, a local rough estimate — UTF-8 byte count divided by 4, a single low-resolution image fixed at 765 token; after the request completes, calibrate with server-side usage. The percentage function doesn't care about the source — it only computes on the numbers the caller passes in.
  4. Defensive details: Multiplication uses saturating multiply to prevent overflow; headroom subtraction uses saturating_sub; a window of 0 always returns false.
⭐ Bonus point Do the arithmetic on the spot: window 128,000, threshold 85%, no headroom — earliest trigger at 108,800; with headroom 4,000 it moves forward to 104,800. If you can compute it, the questioner believes you actually understand the formula.
Organize your answer using these lesson pages → Estimation, Percentages & Strict Thresholds Compaction 85% Threshold
Q16Interviewer
"An Agent's long-term memory gets messier the more it accumulates. When do you plan to tidy it? Run a cron job in the middle of the night?"
🎯 What they're assessing
Testing engineering design of background maintenance tasks: trigger conditions, concurrency control, idempotency, and failure recovery. "Just run a cron job" is exactly the answer most likely to blow up.
🧭 Answer framework
  1. Get the trigger right: Grok Build's Dream merges recent session logs and MEMORY.md into long-term memory. There are three entry points: session end, the /dream manual command, and an optional periodic check. check_interval_secs defaults to None — periodic checks are off by default. You cannot say "it necessarily runs automatically on idle."
  2. Three gates: enabled defaults to true but sub-Agent sessions skip entirely; min_hours defaults to 4, using the lock file's mtime to record last success; min_sessions defaults to 3, counting session files modified since the last tidy and excluding the current session.
  3. Concurrency and budget: DreamLock stores a PID in .dream-lock. It's a best-effort lock — the source comment explicitly says it does not guarantee strict mutual exclusion, so the tidy process must tolerate duplicates. Input is truncated at 32K; the model call has a 30-minute timeout.
  4. Failure recovery: If the model returns empty or has no Markdown heading, nothing is written or deleted; if writing MEMORY.md fails, rollback restores the old lock state; only on write success are sessions cleaned, skipping files still active within 5 minutes; the index only removes paths that were actually deleted.
⭐ Bonus point Distill one line: "the success boundary determines the cleanup boundary" — until a write is confirmed successful, not a single original session is deleted, so you can always retry after failure. That's a universal design rule for every background tidy job.
Organize your answer using these lesson pages → The Real Mechanism of Dream From File Changes to Hybrid Ranking
Q17Boss
"That refactor we had the Agent run last week died halfway. Starting over is another round of money and time. Can't it just pick up where it left off?"
🎯 What they're assessing
Testing product understanding of recovery plus expectation management. The boss wants a three-part answer: "it can resume, how it resumes, and when it can't." A vague "it should be able to" means you own the next blow-up.
🧭 Answer framework
  1. Lead with the conclusion: It can resume. Sub-Agents support resuming from a completed task. ContextSource::Resumed copies the original transcript and tool state; a worktree already mid-edit is reused first; if the directory was wiped, snapshot_ref can rebuild from a persistent git ref.
  2. Explain identity protection: Resume has checks — subagent_type must match the original; if Persona is given explicitly it must match too. The model is pinned back to the original; a mid-flight model-change request is soft-ignored to avoid context mismatch.
  3. Disclose when it can't: If the original transcript exceeds 80% of the target model's context window, resume is refused; if transcript copy fails, it also fail-closes. The system will not hand you a session that only pretends to have resumed.
  4. Manage expectations: Plan state and signals are not in the copy scope. After you take over, the plan needs to be reconfirmed. This is reliable continuation, not seamless playback.
⭐ Bonus point Explain the intent of the 80% cap: after resume it still has to keep working. If context is nearly full from the start, two more turns and you're compacting again — the experience is worse. Refusal is protecting task quality.
Organize your answer using these lesson pages → Four Isolation Dimensions of Sub-Agents
Q18Interviewer
"How many levels of isolation do your sub-Agents have? Low, medium, high?"
🎯 What they're assessing
A trap question. If you follow "how many levels" down the path, you've already lost. The questioner is watching whether you'll crush orthogonal dimensions onto a single axis. Someone who actually read the source will first correct the question itself.
🧭 Answer framework
  1. First correct the model: Isolation is four orthogonal dimensions — a single "low / medium / high" axis cannot hold them: context source, identity continuity, working directory, and file-change space must be judged separately.
  2. Give each enum: Context is ContextSource's New or Resumed; change space is SubagentIsolationMode's None or Worktree — the enum has no "sandbox" member; working directory is resolved by priority: worktree, override, then parent directory.
  3. Give a combination counterexample: Resumed plus None is fully legal — inherit context but use the parent workspace; New also does not imply an independent file space — a new session still edits files in the parent cwd by default.
  4. Add the boundary: The public enum only has New and Resumed. Internally, shell has a separate Forked branch for mirroring context from the parent session — don't call it a public enum member.
⭐ Bonus point Break the most common confusion: None describes the file workspace, and has nothing to do with conversation history. A sub-Agent in None mode still has an independent context window. Very few people can tell these two apart.
Organize your answer using these lesson pages → Four Isolation Dimensions of Sub-Agents AgentDefinition & Persona Merge
Q19Interviewer
"spawn parameters, role defaults, and persona defaults can all set the model. Whose value wins?"
🎯 What they're assessing
Testing a precise understanding of config merge. Giving a vague overall priority ranking gives you away. The real design is per-field cascade — and you first have to confirm whether the field even exists on that structure.
🧭 Answer framework
  1. Give the cascade order: Per-field cascade: spawn's explicit override is highest, then role defaults, then persona defaults; if none of them has it, leave None and inherit from the parent.
  2. Stress "per-field": This priority walks each field on its own. model can come from spawn while reasoning_effort comes from persona. And first ask whether the field exists: persona doesn't even provide capability_mode.
  3. Give the result structure: The parse product is EffectiveRuntimeConfig, with fields including model, reasoning_effort, capability_mode, persona, persona_instructions, role_prompt, isolation. The source has no temperature, max_tokens, or tools fields.
  4. Add the fallback: After parse, shell has another layer: if reasoning_effort is still empty it reads AgentDefinition.effort. The full model order is runtime override, per-agent pin, AgentDefinition.model, then parent-model inheritance.
⭐ Bonus point State the method: "Before you ask a field's priority, first ask whether the field exists." Plenty of people memorize one overall ranking, then fall apart the moment you ask where capability comes from.
Organize your answer using these lesson pages → AgentDefinition & Persona Merge
Q20Technical Colleague
"I set up a PreToolUse hook to block dangerous commands. Yesterday the script crashed on its own — and the command still ran! Is your security mechanism just for show?"
🎯 What they're assessing
Testing fail-open semantics. You need to explain this is an intentional trade-off, state the exact block conditions, then say where hard guarantees belong. A PM who rushes to apologize will be judged as not understanding the system.
🧭 Answer framework
  1. First make the semantics clear: This is designed fail-open. If a Hook crashes, times out, exits with a code that is neither 0 nor 2, or produces invalid stdout, the dispatcher logs a warning and lets it through. The source comment explicitly requires that Hook failure must not break tool availability.
  2. There are only two block paths: Return valid JSON with decision set to deny; or no valid JSON but exit code 2. Note that JSON wins: valid JSON that says allow will not block even if the exit code is 2 — it only logs a conflict warning.
  3. Give the correct usage: Hooks are for alerts, auditing, and recoverable pre-checks. For hard guarantees, put rules in the permission layer (deny > ask > allow) and system boundaries in the sandbox. Those two layers are not fail-open.
  4. Help them debug: Of the 15 events, only PreToolUse has is_blocking true; matcher is regex plus compatibility aliases — writing Bash in the config can hit the internal name run_terminal_command. First confirm the matcher actually hit.
⭐ Bonus point Ask back: "If Hook failure blocked every tool, one broken script could stall the whole company's Agents — which failure mode do you pick?" Put both risks on the table and the other person will see the trade-off.
Organize your answer using these lesson pages → Hooks: Only an Explicit deny Blocks From Tool Request to Restricted Execution
Q21Interviewer
"If a Persona file can't be read, spawn aborts immediately; if a role's prompt file can't be read, it keeps going. Why the different treatment?"
🎯 What they're assessing
An ultra-detail question, testing whether you read the divergent design of failure semantics. People who memorize feature lists don't even know these two paths exist. Being able to explain the design reason is what counts as truly having digested it.
🧭 Answer framework
  1. Give the facts: After a Persona is requested, not found, empty content, or a file-read failure all write persona_error; the spawn side sees the error and aborts creation — fail-closed.
  2. Contrast with role: A role's prompt_file read failure only produces role_prompt_warning; model, reasoning, capability, and isolation still parse — soft degrade.
  3. Explain the design reason: Persona is a behavior contract the user named explicitly, with instructions and I/O contracts. Silently dropping it is like swapping in a different personality — high risk. A role prompt is a type-level enhancement; without it the sub-Agent is still that type.
  4. Add the merge detail: Persona's inline instructions are merged before the file content, and finally enter the prompt as a persona block.
⭐ Bonus point Abstract it into a portable method: failure semantics should follow the intensity of user intent. Things the user specified explicitly should fail loudly; default fallbacks can fail softly. That sentence can be used in any product review of your own.
Organize your answer using these lesson pages → AgentDefinition & Persona Merge
Q22Interviewer
"A dozen sub-Agents hanging under the main session, running in parallel — how do you manage their life, death, and results?"
🎯 What they're assessing
Testing the concrete mechanisms of the multi-Agent coordination layer. "Just spin up several" is a consumer's view. The questioner wants the producer's view: lifecycle registration, result waiting, and the cancellation path.
🧭 Answer framework
  1. Give the component: Grok Build has a real coordination component, SubagentCoordinator. start_subagent_coordinator starts the drain task only once; all coordination events funnel to one place.
  2. Give the event surface: SubagentEvent has Spawn, Query, Cancel, ListActive, Completions, Outstanding. Each Spawn goes into its own spawn_local async task calling handle_subagent_request; the coordinator registers three states: pending, active, completed.
  3. Results and cancellation: Query can take an instant snapshot or register a block wait slot until completion; Completions drains pending completion notifications and filters by suppress_ids; Cancel supports subagent ID or parent prompt ID; expired completed records are evicted.
  4. Elevate to organization strategy: Parallelism comes from async tasks. Choosing a single Agent, a main session plus subagents, or multi-member shared tasks depends on the task graph: parallel gains, dependencies, context-copy cost, file conflicts, and who is responsible for the summary.
⭐ Bonus point Distill the pattern: "the coordinator is a single event-driven funnel." Life-and-death state has only one owner; queries and cancels all go through messages — that eliminates races from mutating state in multiple places at the root.
Organize your answer using these lesson pages → How Multi-Agents Are Organized Four Isolation Dimensions of Sub-Agents
Q23Technical Colleague
"Permission checks just look at the first command, right? I do ls && rm -rf in one shot — can your system stop that?"
🎯 What they're assessing
Half joke, half provocation — testing depth of command parsing. Not many people know about per-segment checks; even fewer can name the parser and the conservative fallback. Answer this well and they won't tease you with this kind of question again.
🧭 Answer framework
  1. Take it head-on: It can. Grok Build uses tree-sitter-bash to split safely decomposable scripts into plain commands, recognizing &&, ||, semicolons, and pipes. Every non-setup segment must independently pass the safe-command, policy, or authorization check. Letting ls through does not save the rm that follows.
  2. Wrappers count too: Parsing recursively strips wrapper layers to get the actual command. The dangerous-prefix list includes rm, chmod, chown, kill, and git push.
  3. If it can't be split, be conservative: Command substitution and complex control flow — scripts that can't be reliably decomposed — go into a conservative prompt as a whole; the user confirms the complete script once.
  4. Add the backstop: Even after approval, the sandbox capability set is still there. Under a read-only profile the workspace is not writable — even at the OS layer, rm cannot write.
⭐ Bonus point Point out the most underestimated part of this design: permission decisions follow script structure. Schemes that regex-match the command string are full of holes in the face of shell syntax. Parsing the syntax tree is the right answer.
Organize your answer using these lesson pages → From Tool Request to Restricted Execution Five Sandbox Profiles
Q24Interviewer
"The user approved rm once — can this session delete files freely after that? Walk me through your authorization model in full."
🎯 What they're assessing
Testing the full authorization chain and the two-layer boundary. Anyone who only answers "a confirmation popup" understands security at the UI layer. The questioner wants to hear how decision inputs, rule priority, and the sandbox backstop stack.
🧭 Answer framework
  1. Answer the question itself first: Approval only releases this request. The input to the authorization decision is AccessKind — tool input is parsed into access intents like Read, Edit, Bash, MCPTool, carrying concrete paths and commands, finer than ToolKind.
  2. Walk the chain: The plan gate blocks edits first; a PreToolUse hook can explicitly deny; then the permission manager evaluates the merged rules. Rule priority is deny > ask > allow, independent of config-source order.
  3. Decision fast paths are ordered: A management-policy deny short-circuits first; only then come yolo pin, session grants, Auto judgment, sandbox Bash auto, and read-only safe items. If none of those conclude, the user is prompted.
  4. Add the second layer: Allow at the permission layer does not expand OS capabilities. When the sandbox is active, the process is still boxed by the capability set and subprocess network policy. The permission layer decides "whether you may try"; the sandbox layer limits "what you can actually do." Stacked, that's the complete boundary.
⭐ Bonus point Proactively correct a widely circulated claim: "all writes inside the sandbox are auto-approved" is wrong. The sandbox fast path only checks Bash, and is still constrained by policy_forced_prompt and auto_forced_prompt.
Organize your answer using these lesson pages → From Tool Request to Restricted Execution ToolKind & Read-Only Semantics Five Sandbox Profiles
Q25Interviewer
"Security wants a company-wide unified sandbox policy; project teams want to add their own rules. How do you design the config system so they don't fight?"
🎯 What they're assessing
Testing layered config governance: who can change what, whose side wins a conflict, and how you stop a project team from quietly lowering the security floor. This is a design question no enterprise product can dodge.
🧭 Answer framework
  1. Give the merge rule: Grok Build reads the global ~/.grok/sandbox.toml first, then the project .grok/sandbox.toml, merging with entry.or_insert. A project can only add new profile names. If it declares a profile with the same name as a global one, the global definition stays in effect — the project cannot change it.
  2. Give the extension method: Project customization goes through a custom profile, starting from workspace by default. extends can only pick the four built-in bases: workspace, devbox, read-only, strict. read_only, read_write, and deny are appended onto the base.
  3. Give two prohibitions: You cannot extends off or none, and you cannot extends another custom. Chained inheritance is banned so a security audit can see the final capabilities along a single line.
  4. Remind about defaults: For a custom to restrict subprocess networking you must explicitly set restrict_network to true — don't assume it inherits from the base.
⭐ Bonus point Point out that the one line entry.or_insert is the governance model: whoever loads first wins. Encoding "global wins" as merge semantics is far more reliable than encoding it as an approval process — a textbook case of mechanism replacing process.
Organize your answer using these lesson pages → Five Sandbox Profiles
Q26Boss
"The team wants to install a bunch of community plugins from the marketplace for productivity. What if one of them is malicious and exfiltrates our code?"
🎯 What they're assessing
Testing trust design for a plugin ecosystem. Anyone who only says "review before install" won't survive follow-ups. The boss wants to hear how many gates exist at the system level, and what happens when a gate fails.
🧭 Answer framework
  1. Give three gates: Installed does not mean it can run. Gate one is source and path: MarketplaceRelativePath rejects absolute paths and parent-directory traversal; remote entries can lock content with a git ref or SHA. Gate two is enablement: plugins discovered at project and user scope default into the disabled list. Gate three is execution trust: authorized per plugin root, with records written to ~/.grok/trusted-plugins.
  2. Explain the untrusted treatment: skills and agents can only expose metadata; hooks don't load, MCP servers don't start, scripts don't execute. The most dangerous executable surface is held down.
  3. Give the failure semantics: If canonicalize on the plugin root fails, it is treated as untrusted — fail-closed. A path problem will not accidentally allow it through.
  4. Land it in process: High-risk plugins get their content reviewed in a read-only sandbox before trust is granted; remote installs pin the version with a SHA so upstream can't silently swap the package.
⭐ Bonus point Give the boss a one-liner they can remember: discovery, installation, and execution are three layers, each with its own threshold. A malicious plugin has to clear three gates, and the third is closed by default.
Organize your answer using these lesson pages → Plugin Marketplace & Trust Five Sandbox Profiles
Q27Interviewer
"A user connected hundreds of MCP tools, stuffed them all into the Prompt, and the context blew up. How would you design this?"
🎯 What they're assessing
Testing a solution for tool scale. "Add a switch and have users turn fewer on" is dumping the problem on the user. The questioner wants the system solution: deferred discovery.
🧭 Answer framework
  1. Give the core idea: Tool metadata goes into a ToolMetadataSnapshot (three fields: tools, servers, mcp_initialized), paired with a BM25 index, so hundreds of definitions don't live in the Prompt.
  2. Give two stable entry points: The model side only exposes SearchTool and UseTool. SearchTool searches by keyword; parameters are query plus limit (default 5); results are grouped by server, with description and input_schema. UseTool takes tool_name and tool_input and dispatches execution against the discovered schema.
  3. Explain the stability gain: The model's tool list stays constant across turns. Adding or removing hundreds of tools doesn't flush the context, and Prompt caching stays friendly.
  4. Add dispatch details: Once UseTool receives a valid tool name, it calls MCP via InnerDispatch or a managed gateway. The model's usage is: search first to get input_schema, construct tool_input from the schema, then call. Discovery and execution are fully separated.
⭐ Bonus point Mention the small mcp_initialized field: when capability discovery isn't finished, the search layer knows "not found" and "not ready yet" are two different things — it won't hand the model a false empty result. Detail at this level and nobody doubts you anymore.
Organize your answer using these lesson pages → Implementation Families & Dynamic MCP MCP Connection, Discovery & Recovery
Q28Boss
"Since xAI open-sourced the code, why don't we fork a copy and turn it into an internal edition, so we don't have to write from scratch. Can we?"
🎯 What they're assessing
Testing judgment of open-source governance boundaries. Anyone who only looks at the license and not the release model will walk the company into a pit. The boss wants a complete ledger: what you can do, and what it costs.
🧭 Answer framework
  1. First give what you can do: Apache 2.0 license — reading, building, and internal modification all have room. The README also gives a source-build entry point.
  2. Give three boundaries: The repo is periodically one-way synced from xAI's internal monorepo, so the public tree may lag the internal trunk; CONTRIBUTING explicitly does not accept external PRs — our changes will not merge back upstream; the root Cargo.toml is a generated read-only file, and editing it directly will be overwritten on the next sync — change each crate's own manifest instead.
  3. Give the platform ledger: Supported build hosts are macOS and Linux; Windows is best-effort and is not currently tested from this source tree. If the company is mostly on Windows dev machines, the cost has to be re-estimated.
  4. Give the conclusion: A fork is feasible, but you have to price it as "long-term maintenance of a fork." Every upstream sync is a merge cost. That is a different thing from picking up a product for free.
⭐ Bonus point Add that the local snapshot has no .git metadata — you can't even verify "which commit we have." In a technical diligence write-up, honestly write "unable to confirm." The boss will remember that rigor for a long time.
Organize your answer using these lesson pages → Engineering Retrospective & Evidence Boundaries Evidence-Based Comparison
Q29Interviewer
"If you were the interviewer, and someone handed you a Coding Agent design, how would you score it?"
🎯 What they're assessing
A reverse probe. Your review criteria expose your own knowledge structure: what you value, what you ignore, and whether you have a system. Anyone who only picks at feature flaws has a scoring system that won't survive three follow-ups.
🧭 Answer framework
  1. Give the rubric: Use the finale review's 100-point weights: boundaries and ADRs 20, contracts and state machines 20, security and recovery 25, testing and observability 20, demo and evidence 15. Security and recovery weigh the most.
  2. Give the veto items: Four one-vote vetoes: no account of where sensitive data lands; high-risk tools missing a permission path; claiming crash recovery without tests; citing source without a file path. Score as high as you like — trip one and you still fail.
  3. Give the inspection method: Walk the nine-dimension decision cards: entry, state concurrency, model stream, tool contracts, context and memory, security, recovery, observability, extension. Each dimension needs a clear decision, a contract, a failure path, and a verification method.
  4. Explain the weight: Features are what you see on ordinary days; security and recovery are what you see when something goes wrong. Review should put the weight on the things you only see when something goes wrong.
⭐ Bonus point Close by citing a review philosophy: every design decision should be able to return to a real failure branch. A design that cannot name its failure default (stop, degrade, or ask the user) is still at the PowerPoint stage.
Organize your answer using these lesson pages → Coding Agent Design Workbench
Q30Boss
"You spent so much time chewing through someone else's source. Tell me — what's the most valuable takeaway? Give me one sentence."
🎯 What they're assessing
Testing the ability to distill. If you can pull a reusable product judgment out of twenty thousand lines of detail, the investment paid off. Listing technical nouns is admitting you studied for nothing.
🧭 Answer framework
  1. Give the one sentence first: The gap between a production-grade Agent and a demo is not in the model call — it's in failure semantics. Every layer of this source has a clear answer to "what happens when this breaks."
  2. Unfold three examples: Hook failure fail-opens to keep tools available; missing Persona fail-closes to protect user intent; plugin path-parse failure is treated as untrusted to protect security. Three failures, three answers, all chosen by risk — no one-size-fits-all.
  3. Second takeaway: Policy is all made into explicit configuration objects. CompactionPolicy has five fields with defaults; the sandbox is a parseable Profile; threshold, budget, and compaction model are all tunable. Demos hard-code policy in the code; products hand policy to configuration.
  4. Land it in your own work: From now on, when I review any Agent feature, I add two required questions: What is this feature's failure default? Does changing this policy require a release?
⭐ Bonus point Close with concrete numbers: 85% compaction threshold, 300-second compaction budget, 1s / 4s / 16s reconnect backoff — these values all sit in config and constants, always inspectable and tunable. Auditable magic numbers are themselves a sign of engineering maturity.
Organize your answer using these lesson pages → Coding Agent Design Workbench Compaction 85% Threshold Hooks: Only an Explicit deny Blocks Plugin Marketplace & Trust
One Last Piece of Advice
The right way to use these 30 questions is to say the answers aloud — to a colleague, a friend, or a recording. This chapter's questions are the best litmus test for real understanding: if you can speak the details, you truly understand; if you can't, you're just reciting conclusions. For anything that doesn't flow smoothly, click the linked lesson pages and review.