How They Will Test You

Dissecting Grok Build · 6 Core Questions

Chapter 6 dissects real source code, and its questions are the most demanding. If you say you understand Coding Agents, these 6 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 the Questioner Is Examining
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.
Use these lesson pages to organize your answer → 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 the Questioner Is Examining
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.
Use these lesson pages to organize your answer → 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 the Questioner Is Examining
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.
Use these lesson pages to organize your answer → 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 the Questioner Is Examining
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.
Use these lesson pages to organize your answer → 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 the Questioner Is Examining
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.
Use these lesson pages to organize your answer → 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 the Questioner Is Examining
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.
Use these lesson pages to organize your answer → MCP Connection, Discovery & Recovery Dynamic MCP Tools Plugin Marketplace & Trust
One Last Piece of Advice
The right way to use these 6 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.