Coding in the AI era interview bank

I begin with the exact task contract: desired behavior, reproducer, allowed paths, required checks, and non-goals. Then I resolve applicable repository instructions and record the repository root, revision, worktree status, package directory, and runtime. The first code set comes from concrete signals such as a failing test, stack frame, named symbol, or diagnostic. I include the relevant implementation, contract, configuration, and closest tests, with a reason for each path. Generated output, dependencies, credentials, and unrelated logs remain excluded until specific evidence makes one necessary.

I put stable repository facts there: package boundaries, canonical commands and their working directories, generated paths, naming rules, and verification evidence expected before delivery. Each instruction has a clear scope and is concrete enough to review. A temporary ticket goal, a long tutorial, or information already obvious from code stays out because persistent text consumes context and becomes stale. I also record which agent hosts the repository supports. Shared guidance can remain canonical in AGENTS.md, while a small CLAUDE.md imports it and adds only Claude-specific behavior supported by current documentation.

I first rewrite the goal as observable delivery behavior, then record the repository baseline, allowed write scope, non-goals, and required acceptance checks. The first step is bounded exploration when ownership is unknown. Later steps follow evidence boundaries: reproduce the current behavior, make the narrowest implementation change, run the focused check, run broader risk-matched checks, and inspect the final diff. Each step names its dependencies, expected observation, and failure policy. I also define distinct complete, paused, failed, cancelled, and budget-exhausted states before execution begins.

I keep a task human-led when the desired outcome is disputed, the required action exposes sensitive data or has an irreversible external effect, the run has no credible cost ceiling, or nobody can verify the result independently. These are task properties, not judgments about whether the model sounds capable. I first try to split the work: an agent may perform read-only investigation or prepare a candidate diff, while an accountable person settles policy and performs the consequential action. Delegation becomes reasonable only after intent, permission scope, stop conditions, and completion evidence are explicit.

The distinction is the feedback loop, not the user interface. Completion predicts text near a cursor, while chat usually returns an answer for a developer to apply. A coding agent can request tools that inspect or change an environment, receive the resulting files, exit codes, and errors, then choose another action. Its real capability comes from the host that executes those calls. I therefore describe an agent by its available tools, permission policy, workspace, stop conditions, and verifier rather than by the model name or whether it appears in a CLI or IDE.

I turn the change into one observable question, then establish the repository, package, runtime, working directory, and current diff. I search for route strings, event names, command names, or failing-test text to find an executable entry point. From there I follow one call path, recording only branch-driving data, concrete dependency bindings, side effects, and enforced invariants. Each important claim gets a source location or focused observation, while uncertain edges stay labelled. I stop expanding when the model can predict the behavior and the failure case relevant to the change.

In a Node 24 agent session, I preserve four layers differently: task and permission constraints stay verbatim, active source is reacquired fresh, ledger entries retain provenance and status, and superseded exploration is discarded. A handoff records the baseline, dirty state, changed files, stale checks, unresolved assumptions, and next decision. Summaries remain navigation aids, not proof. The concrete pitfall is silent truncation or a polished recap that drops an approval boundary or failing tail. Before editing or completing, I reread mutable inputs and rerun every check invalidated by the current diff.

In the Node 24 planning model, a checkpoint is evidence tied to inputs, a plan version, and an acceptance rule—not a permanent green label. If a later edit changes code, configuration, dependencies, environment, or instructions on which that check depended, the step becomes superseded or pending and must run again before completion. The record includes command arguments, working directory, exit code, streams, timeout, and truncation. A common pitfall is caching “tests passed” after a subsequent patch touched their inputs. Dependency tracking costs bookkeeping, but prevents stale evidence from unlocking unrelated downstream work.

In a Python 3.14 host loop, success means every required acceptance criterion maps to fresh evidence for the current workspace state. The record identifies the baseline, changed resources, exact commands, working directories, exit codes, relevant output, skipped checks, and truncation. A deterministic controller—not the model’s summary—decides whether all gates passed. Blocked, cancelled, and budget-exhausted are separate terminal states. A concrete pitfall is stopping the model request while its child test or server keeps running; cancellation must terminate and reap child processes. This rigor costs orchestration, but makes resume and review trustworthy.

I attach mutable observations to a revision, digest, or exact-text precondition and record what invalidates them. Before editing, the agent rereads the target and any precise contract on which the patch depends. If current text differs from the snapshot used to compute the patch, it stops, refreshes related evidence, and recomputes rather than forcing the old change. After editing, it inspects the actual diff and reruns checks whose inputs changed. A digest proves only that bytes differ or match; it does not prove that the current content is correct or safe.

I begin with an exact reproduction, expected and actual behavior, runtime version, and unedited failure output. I ask the assistant for a small set of competing hypotheses, each with a mechanism, predicted observation, and result that would refute it. We then choose the cheapest safe check that separates those predictions and run it against the real program. I keep observations distinct from inference in an evidence ledger. I request a fix only after one explanation accounts for the failing and passing cases, then require a regression check to fail before the edit and pass afterward.

I begin with the baseline and changed-file list, because a fluent summary can omit configuration, lockfiles, generated output, or altered assertions. I separate formatting noise from semantic edits and inspect every hunk, including deletions. For renamed or changed public symbols, I use reference and text search to find static, dynamic, and string-based consumers. Then I run repository-owned format, static-analysis, test, and build commands from the correct package directory, recording exit status and skips. Any unexplained path or missing check keeps the change in review, even when the editor diagnostics are green.

I establish the exact baseline and compare the complete changed-file list with the task scope before reading the author summary. I inspect additions, deletions, renames, tests, configuration, lockfiles, and generated artifacts. Then I rewrite the request as observable acceptance criteria and classify each semantic edit: contract, control flow, mutation, persistence, permissions, or tooling. This exposes unrelated cleanup and missing companion changes early. Only after the scope and intent agree do I inspect each changed function in its full file context and begin tracing its callers and effects.

I write the old and new input, output, error, mutation, ordering, and side-effect contracts, then treat each changed definition as the start of an impact cone. Semantic reference search finds typed callers, implementations, and re-exports; text search finds route names, serializers, reflection, dependency-injection keys, fixtures, and scripts. I trace inputs upstream and observable effects downstream until I reach unchanged boundaries whose contracts still hold. External consumers and dynamic links that cannot be searched remain explicit risks, usually covered with contract tests, compatibility adapters, release coordination, or a staged rollout.

I treat test changes as security-sensitive evidence changes, not as an automatic part of implementation work. The task names which test files may change and why. During review I inspect deleted assertions, changed expected values, snapshot updates, broader mocks, new skips, discovery configuration, and test counts separately from source edits. Critical acceptance tests can live behind ownership rules or in a gate the task cannot modify. After the final edit, an independent runner executes fixed commands and records the revision, working directory, exit code, skipped tests, and truncated output. Any unexplained weakening keeps the patch unaccepted.

I start from the behavior’s entry point and list storage, network, event, cache, filesystem, log, metric, clock, random, and mutable module-state access in execution order. Dependency names are not enough, so I resolve each interface to the concrete adapter selected in the active configuration. For every effect I record its payload, earlier completed effects, and what happens if it fails. Then I run a narrow test with recording fakes and one injected failure. This exposes partial states, duplicate-work risks, and hidden retry assumptions that a successful return value or fluent generated summary can conceal.

On Node 24, debugger pauses, console output, profilers, and tracing hooks can change scheduling, backpressure, object lifetime, or timeout behavior. I record the active probes for every run and compare an instrumented control with the failing condition. If a heavy probe hides the symptom, I move to lighter signals such as existing span fields, bounded ring buffers, atomic counters, or sampled identifiers at the same boundary. Generated probes also need review: reading a getter, consuming an iterator, or logging a token can alter behavior or leak data. The trade-off is less detail in exchange for more faithful timing.

On Node 24, I classify every changed input domain, output shape, failure channel, mutation, effect, ordering, and timing observation before deciding that a refactor is internal. A contract delta needs consumer search, compatibility policy, and boundary tests; an implementation delta needs characterization evidence that protected observations remain equivalent. Visibility is not the test—private code can still change SQL, cache keys, emitted events, or shared objects. The pitfall is trusting a generated “no API change” summary because exported names stayed constant. This classification costs an up-front impact pass, but prevents cheap local tests from approving repository-wide behavior changes.

In the Node 24 workflow, I stop when I can predict the task-relevant success and failure behavior, connect an active entry point to material effects, trace branch-driving data, name enforced invariants, and survive focused counterexamples. Every remaining edge is labeled confirmed, inferred, contradicted, or unknown, with evidence that would change it. I do not need a tour of unrelated subsystems. The concrete pitfall is deeply explaining dead or unregistered code without proving runtime connectivity. This stopping rule trades global completeness for an auditable local model; I reopen it whenever the patch changes wiring, data representation, effect order, or an enforcement point.

I record the seed, concurrency level, scheduler controls, resource limits, probe configuration, and occurrence count over a stated number of trials. A run where the symptom does not appear is not a fix. I ask the AI to propose a contested ordering or lifecycle event, then replace arbitrary sleeps with barriers, fake clocks, controlled dependency responses, or resource ownership markers. Traces need request or task identifiers because collector arrival order may not be causal order. After isolating the mechanism, the regression test should force that ordering deterministically and verify both the failure behavior and cleanup path.

I trace each expected result to an independent product rule, protocol, reviewed fixture, or invariant; production code cannot be its own oracle. I group cases by input partition and check exact boundaries, rule interactions, missing values, repeated actions, and forbidden effects. Then I name a defect each case claims to catch and run it against the pre-change or deliberately altered implementation. A boundary test that stays green after changing <= to < is not discriminating. I also inspect whether the agent changed old expectations, because coordinated edits can erase regression evidence while leaving every generated check green.

I expect a reader to connect the check to an intended observable behavior without reverse-engineering private code. The case has a rule-oriented name, explicit setup and action, an approved expected result, and a clear boundary or partition. Its oracle is independent enough to reject a plausible wrong implementation, and its failure identifies the broken agreement. A low-level test may still be valuable, but if it only pins helper calls or current structure, it is not the product specification. I keep prose beside the check because executable assertions cannot explain unresolved decisions or the limits of their coverage.

The oracle is the authority that labels observed behavior correct or incorrect. If expected values come from the same production formula, generated lookup table, database query, or model response as the implementation, the same misunderstanding can appear on both sides and pass. Independence is therefore about data flow, not different filenames. I prefer literal outcomes approved by a policy owner, protocol examples from a pinned standard, or a small reference model built from different primitives. I also mutate a boundary or precedence branch and confirm a relevant check fails. A surviving mutation exposes a weak property or a missing case.

I start from product tasks and consequences, not prompts that already look good. I sample common request categories, then add costly incidents, boundaries, long-context cases, multilingual traffic, and adversarial inputs. Each case records its source, intended behavior, slice, and reason for inclusion. I remove near-duplicates so one template cannot dominate the score. Synthetic cases stay labeled and are compared with consented production patterns. I use a visible development set for iteration and a locked release set, then version both so score changes are never confused with case-set changes.

I write the policy before running the candidate. It names an absolute quality floor, the tolerated baseline delta, protected slice limits, minimum sample sizes, and non-compensable hard gates. Baseline and candidate run on identical inputs with symmetric retry rules and enough independent trials for the decision risk. I retain paired, trial-level results and report intervals rather than only point estimates. If an interval spans both allowed and forbidden regions, the result is inconclusive. Safety, privacy, and authorization failures remain outside averages even when the weighted quality score passes.

I start from credible failure modes in the requested change, not from a target coverage percentage. For each risk I name the stable observation and choose the narrowest honest test layer. A boundary edit gets values below, at, and above the threshold; authorization gets a second identity; a write path gets collaborator failure and a no-side-effect assertion. I keep implementation choices open unless an internal property is itself contractual. Finally, I record the focused command and the broader suite that must pass, while listing product or operational claims the tests cannot establish.

With Node 24 checks, I use an exact oracle for crisp policy values or protocol codes, a structural oracle when selected fields matter but irrelevant representation may vary, and a property oracle for relationships across many inputs. The allowed variation must be explicit: an overly permissive matcher can hide a missing field, while a weak property such as “non-negative” may accept realistic wrong algorithms. I often combine named exact boundaries with a schema and independently derived properties. Snapshot replacement is the concrete pitfall; automatically accepting generated output makes the candidate its own oracle. Broader coverage costs clarity and runtime, so every layer needs a distinct purpose.

In the Node 24 evaluation pipeline, I calibrate against human-labeled clear passes, clear failures, and boundary cases under a written rubric. For binary gates I inspect false-pass and false-fail rates, not accuracy alone; for pairwise judging I swap answer order and hide model identity to detect bias. The rubric, judge prompt, judge model, and case distribution are one versioned measurement instrument, so any change requires recalibration. Structured output includes an unable-to-grade state. The pitfall is averaging grader outages or malformed results into quality. Calibration costs labeled data, but an unmeasured judge cannot support a narrow release threshold.

With Node 24’s test runner, I connect the test to one credible fault, then run it against the pre-fix code or a disposable mutation such as reversing a boundary comparison, removing an authorization predicate, or emitting an event on failure. It must fail for the intended reason before passing on the final revision. A surviving mutant may mean missing coverage, a weak assertion, unreachable code, or an equivalent transformation, so mutation score is diagnostic rather than a target. The pitfall is accepting a newly generated test that was never red. Sensitivity checks add runtime, so I focus them on changed high-risk logic.

I first name the exact symbol or consumer boundary instead of saying “this code.” Then I describe one current observation and the desired replacement: accepted inputs, return shape, error channel, side effects, and ordering where relevant. I add invariants and compatibility dimensions that must survive, plus explicit non-goals. Negative examples expose ambiguity that a happy path hides. Finally, I attach evidence to each important claim: a focused test, a broader command, a call-site search, or a manual review item. The agent may choose implementation details inside that frame, but it must report unresolved product assumptions.

I require structure when it carries an evidenced design constraint: ownership, dependency direction, a security boundary, test substitution, measured performance, or an established repository convention. I describe the reason and the boundary, such as keeping network delivery behind an injected callable while deterministic policy stays in a pure helper. I do not request a class, factory, adapter, or repository merely because the term sounds architectural. If only observable behavior matters, I leave internals open. During review I check imports, side-effect traces, and consumers to prove the requested boundary exists without unnecessary layers.

I start with one observable outcome and name the caller or user who needs it. Then I cite the current behavior and relevant repository locations, set a narrow write scope, and list nearby changes that are explicitly out of scope. I identify compatibility by dimension, such as signature, error type, data shape, runtime, or side-effect order, instead of saying “do not break anything.” Finally I give exact test, lint, build, and diff commands with success conditions. If investigation proves another file or product decision is required, the prompt tells the agent to stop and report the evidence.

I define the protected consumer set and the observations each consumer relies on. For a function, that may include call shape, omitted and zero inputs, returned fields, exception classes, side effects, and async timing. I search call sites and use existing tests, schemas, fixtures, and automation to build a small matrix of old behavior, intended behavior, and evidence. Intentional changes get their own rows. Unknown plugins or external callers remain labelled as uncertainty, so I do not claim universal backward compatibility. If two required rows conflict, I escalate the smallest contradiction before editing rather than choosing one silently.

A useful counterexample targets a plausible wrong rule rather than merely looking unusual. I first state the generalization an implementer might make, then choose the smallest valid case where that rule and the intended rule produce different observable results. I keep unrelated fields fixed, name the distinction, and provide a literal expected value, stable failure, or forbidden side effect. For a threshold, equality or an adjacent value is usually decisive. For permissions, I combine rules to expose precedence. The case is successful when its failure explains which misunderstanding occurred.

In a Node 24 service, failure is a full contract branch. I name the trigger, representation channel, stable error identifier, retry rule, already committed effects, forbidden effects, and information safe to expose. I also state whether a dependency error is propagated unchanged or translated into a boundary-owned result, including how its cause is retained. “Handle errors” is the pitfall: it permits swallowing, logging, throwing, retrying, or returning incompatible outcomes. This precision makes prompts longer, but it gives tests concrete observations such as “no inventory write and no confirmation event” instead of merely checking that something failed.

In the Node 24 workflow, an acceptance command creates an evidence obligation; only an actual run against the final diff can satisfy it. I verify that the command still exists, runs from the named package directory, selects the intended files, and records exit status, output, timeout, skips, and truncation. “No tests found” is not success merely because the process returned zero. If a later edit changes the command’s inputs, its result becomes stale. This adds rerun cost, but prevents a prompt checklist or model claim from being mistaken for proof of behavior, scope, build health, or dependency stability.

In the Node 24 examples, I first list plausible competing rules, then choose one representative per required behavior and add controlled contrasts that reject the riskiest remaining interpretations. Each case changes one fact where possible, carries a literal or independently derived oracle, and names the defect it distinguishes. I run it against the pre-fix or a disposable mutation to prove it can turn red. The pitfall is adding many correlated happy paths that all occupy one equivalence class. A smaller set is easier to maintain, but it does not prove an unbounded domain; properties and integration checks cover remaining claims.

An instruction file is text in the model context. It can make a safe request more likely, but it cannot revoke credentials, block a network route, or stop a different client from calling the same server. MCP defines how tools are discovered and called; it does not turn descriptions or schemas into authorization. I enforce the boundary in deterministic code: expose only needed tools, validate arguments, authorize the current caller and resource on every call, limit output and runtime, and pause sensitive operations for scoped approval. The forbidden call must fail even when the model confidently asks for it.

I keep the model outside the execution boundary. It proposes a typed call, and a host validates the tool name, normalized arguments, working directory, network need, and expected write scope. Policy then allows, denies, or pauses for approval. Unknown tools are denied by default, and sensitive approval covers one exact call or a narrow rule. The executor returns structured status, exit code, stderr, truncation, and changed resources. For file paths I resolve links and prove containment; for commands I prefer argument arrays and purpose-built test or format tools over an unrestricted shell.

I first confirm the working directory, repository root, branch, baseline commit, and existing dirty files. I prefer an isolated branch or worktree so the session has one attributable diff. Then I write a small task contract: desired behavior, minimal reproduction, allowed paths, required commands, and non-goals. I expose only the implementation, tests, and stable project instructions needed to begin, keeping credentials, generated output, and unrelated data outside context. Finally, I check the active permission mode and make sure approval is narrow enough for the first step rather than the entire task.

I need a documented machine interface, not merely a prompt flag. The process must have bounded runtime, narrow filesystem and network permissions, a minimal environment, and predictable behavior when authentication, approval, tools, or the model fail. The wrapper uses fixed executable arguments rather than shell interpolation and records its working directory, exit status, stderr, timeout, and truncation state. A separate gate then compares changed paths with the task scope and runs named acceptance checks. If output cannot be parsed or evidence is missing, the job fails closed and produces a review artifact instead of merging or deploying.

An IDE owns the repository view, but each model request contains a bounded selection of that state. The current file, selection, diagnostics, explicit attachments, retrieved snippets, instructions, and conversation history compete for one context window. Retrieval may miss an indirect caller or return stale indexed text, and an open tab is not proof that the model received it. I ask the tool to name its source paths and assumptions, explicitly attach authoritative contracts, and reread current files before important edits. Language-service search and repository commands then verify relationships that model context only suggested.

On a Node 24 baseline, instruction discovery is a host-versioned contract, not a universal filename rule. I record the repository root, launch directory, recognized filenames, subtree scope, import behavior, size limits, and precedence. Then I use a fixture tree with a harmless root rule and a conflicting nested rule, launch from several directories, and assert which sources the host loads. The pitfall is assuming AGENTS.md and CLAUDE.md resolve identically across products. Pinning the host and maintaining fixtures adds work, but catches upgrades that silently drop or reorder constraints.

On the Python 3.14 baseline, I record the baseline commit, CLI and version, working directory, task contract, approved effects, and changed paths. Every command retains its argument boundaries, duration, exit status, relevant stdout and stderr, timeout or signal, and an explicit truncation flag; skipped checks get reasons. Host-captured facts stay separate from the model’s interpretation. The transcript must not dump the full environment or credentials, so structured redaction and retention controls are part of the design. A polished “all tests passed” summary is a concrete pitfall because it cannot prove which revision or command actually ran.

In the Node 24 workflow, I choose the least capable mode that can produce the needed artifact. Advice mode fits explanation with no workspace change; edit mode fits a bounded, reviewable text patch; agent mode is justified only when tool feedback and multi-step adaptation are necessary. Each escalation gets an explicit context set, writable scope, command policy, and acceptance evidence. The pitfall is treating editor undo as recovery: it reverses text buffers, not dependency installs, generated files, processes, database writes, or network effects. Lower capability reduces convenience, but also reduces approval surface and cleanup ambiguity.

I preserve the task contract and revise the route. The new plan version records the triggering observation, changed steps, and checkpoints made stale. If the discovery only corrects file ownership inside the authorized scope, the agent can refine the next steps and continue. If progress needs another path, dependency, migration, credential, network target, or product decision, it pauses with the smallest proposed expansion and supporting evidence. Replanning never grants authority by itself. After approval or rejection, the controller resumes from a valid checkpoint or ends in a distinct terminal state.

The controller should stop at a predefined trigger rather than let the model improvise broader authority. Triggers include discovering sensitive data, requesting an out-of-scope resource, needing an irreversible effect, finding contradictory tests, or reaching a time, step, or spend limit. The handoff should preserve the exact observation, denied call, inspected paths, candidate diff, completed effects, and smallest unresolved decision. A person can then narrow the task, grant one scoped approval, or keep the step human-led. After that decision, I classify the remaining work again instead of silently resuming under the original assumptions.

I treat them as separate release claims. Provenance describes where material came from and how it changed. Integrity says the bytes match a recorded digest. Authenticity connects a signed statement to an identity that policy trusts for a particular subject. Correctness says observable behavior satisfies requirements or invariants. None implies the others: a trusted builder can sign vulnerable code, and correct code can have unresolved origin. I give each claim its own evidence and decision, then require all release-critical decisions to pass instead of letting one green signature or test approve the whole artifact.

A valid signature only proves that one key or certificate signed the envelope. I also require the expected predicate type, an issuer and workload identity authorized for this repository, the approved workflow and source branch, and a subject digest equal to the artifact being released. Depending on policy, I check certificate freshness, transparency-log inclusion, parameters, and input materials. The evidence should come from a protected builder, not a JSON file the same workspace can rewrite. I test rejection by changing the digest and identity, and I keep behavioral, vulnerability, and license review as separate gates because attestation does not prove them.

I compare the proposed system with the pre-change system and ask what becomes newly reachable, trusted, or privileged. I name the assets, capable actors, entry points, identity source, trust-boundary crossings, privileged effects, and likely abuse cases introduced by that delta. Then I trace only the controls and consumers needed to establish the affected invariants. Each invariant becomes a denial or containment claim with evidence. Removed checks, broader defaults, retries, logs, and dependencies count as changes to the attack surface. Unknown production configuration stays explicit residual risk rather than becoming an inferred control.

Validation decides whether a value has an accepted type, size, grammar, encoding, or canonical form. Authorization decides whether a verified principal may perform one action on one resource in the current context. A perfectly formed invoice ID may still identify another tenant’s invoice. I derive tenant and user scope from the authenticated principal where possible, query within that scope, and enforce action policy at a stable server-side point. Tests use a valid cross-tenant ID, a principal missing the action scope, an inactive resource, and an unknown resource, while checking that denied requests produce no protected effect.

On a Node 24 toolchain, I choose a script when inputs, transformation, failure behavior, and verifier are already known: formatting a fixed file set or applying a schema-owned generation step does not need model judgment. An agent is useful when bounded exploration or adaptation is required. The mechanism matters because a script follows inspectable branches with predictable cost, while an agent adds probabilistic choices, context exposure, and supervision. A concrete pitfall is delegating a fixed transformation and then reviewing creative adjacent edits. The trade-off is less flexibility, which is desirable when variance has no product value.

On the Node 24 baseline, I compare manifest intent with the lockfile’s exact versions, sources, integrity material, transitive graph, optional branches, and install scripts, then reconcile those records with the built artifact or SBOM. Verification uses frozen resolution and records the package-manager version. A lockfile or vulnerability scan is not a verdict: neither proves intended publisher identity, license compatibility, absence of post-install downloads, or acceptable build authority. I inspect execution by phase and run untrusted installation with minimal credentials, network, and writes. The trade-off is slower admission, but direct-package review alone misses code actually shipped or executed.

In the Node 24 baseline, I map dependency execution by phase: resolution, installation scripts, build plugins, test discovery, runtime imports, and packaging. For each phase I record the identity, network routes, secrets, and writable paths available, then inspect manifest and lockfile changes with the repository’s pinned package manager. A vulnerability scan is only one input; it does not prove the intended publisher, acceptable provenance, required authority, or absence of lifecycle downloads. The concrete pitfall is running an unreviewed install script with developer credentials. Least-privilege disposable builds add friction, but contain both malicious and accidental package behavior.