Interview Questions

AI-assisted development now comes up in interviews the way version control did a decade ago: every candidate is expected to have an opinion on it, even if it isn’t their specialty. Whether or not the company uses Kiro specifically, these thirty-six questions exercise the vocabulary of agentic development (specs, steering, agent autonomy, tool protocols), and they also work as a self-test for everything else on this site. If a term in an answer is new to you, the Glossary defines every one of them in a sentence.

Beginner questions

These test vocabulary and basic orientation: the questions a screener asks to check you’ve actually used the tool.

Q1: What is Kiro?

Kiro is AWS’s agentic AI development tool: an environment where an AI agent plans and performs multi-step coding work (editing files, running commands, checking results) while you direct and review. Its signature ideas are specs (plan before code), steering (persistent project knowledge), and hooks (event-driven automation). It launched in public preview in July 2025 and reached general availability in November 2025.

Q2: What are Kiro’s surfaces?

Five, as of September 2026:

• IDE: a desktop app built on Code OSS, the open-source base of VS Code.
• CLI: kiro-cli, which brings Kiro agents to the terminal.
• Web: a browser agent at app.kiro.dev, generally available since 1 September 2026, that works against GitHub and GitLab and creates PRs/MRs.
• Mobile: a native iOS app in preview, which steers cloud sessions and syncs with Kiro Web.
• Crew: an open-source persistent agent, Apache 2.0 since August 2026, that runs locally or on your own hardware.

The core concepts (specs, steering, hooks, MCP) carry across all of them. A strong follow-up answer adds cloud sessions: the agent runs in a managed AWS sandbox and every surface can attach to and resume the same session, so the surfaces are increasingly windows onto one running agent rather than separate places to work. If the interviewer’s material says “three surfaces”, that was true until August 2026 and saying so politely is itself a good answer.

Q3: What three files make up a Kiro spec?

• requirements.md: what to build, as user stories with acceptance criteria in EARS notation. (Bugfix specs use bugfix.md here instead.)
• design.md: how to build it (architecture and technical approach).
• tasks.md: the steps (discrete, trackable implementation tasks).

They’re plain Markdown in your repository, so they get reviewed and versioned like code. Full detail: Specs.

Q4: What is steering?

Steering files are Markdown documents that give the agent persistent project knowledge so you don’t repeat conventions in every prompt. They live in .kiro/steering/ (workspace) or ~/.kiro/steering/ (global), with workspace winning on conflict. The foundational files are product.md, tech.md, and structure.md, and YAML front matter controls inclusion: always (default), fileMatch, manual, or auto.

Q5: What’s the difference between Autopilot and Supervised mode?

In Autopilot the agent works end-to-end (creating files, modifying code, running commands) with everything viewable and revertible afterward. In Supervised mode it pauses after each turn that edits files, and you accept or reject changes hunk by hunk. You toggle between them in the chat UI, or set the default under Settings, Agent, Agent Autonomy; Autopilot trades review friction for speed, Supervised trades speed for control. See Agentic development. Worth adding: permission deny rules still apply in Autopilot, so autonomy and boundaries are separate settings, not the same dial.

Q6: What’s the difference between vibe coding and spec-driven development?

Vibe coding is conversational: you chat, the agent builds, you iterate. It’s great for exploration and quick prototypes. Spec-driven development writes requirements, design, and tasks before code, which suits complex features, risky bug fixes, and anything teammates need to understand later. The honest answer is “both, chosen by stakes”: prototype in vibe, switch to a spec when the work becomes load-bearing. Use Cases has the split in a table.

Q7: What is MCP?

MCP (Model Context Protocol) is the protocol Kiro uses to connect agents to external tools and data: databases, APIs, search, documentation. Servers are configured in JSON at .kiro/settings/mcp.json (workspace) or ~/.kiro/settings/mcp.json (user), and once connected, their tools become actions the agent can take.

Q8: What is the .kiro folder in a project?

It’s the workspace home for everything that shapes Kiro’s behavior in that repository: .kiro/steering/ (persistent project knowledge), .kiro/settings/mcp.json (external tool configuration), .kiro/agents/ (custom agent definitions), and .kiro/skills/ (shared skills). Teams commit it to version control so everyone’s agent follows the same rules. It’s reviewed and maintained like code, and it has a global twin at ~/.kiro/ for your personal defaults. Core Concepts walks through each folder.

Practical workflow questions

These probe judgment: when and how you reach for a feature, rather than what the feature is.

Q9: How do you decide between starting a spec and just chatting?

I ask three things: is the change complex, is it risky, and will someone else need to understand it later? Any “yes” points to a spec; all “no” means a vibe session is faster and fine. I also escalate mid-stream: if a quick prototype starts growing real scope, I stop and formalize it into a spec rather than letting an unplanned feature sprawl.

Q10: How would you use steering to keep a team consistent?

Commit .kiro/steering/ to the repository so every teammate’s agent loads the same conventions automatically. Keep one domain per file, explain the why behind each rule, include real code examples, and never put secrets in steering. Use fileMatch inclusion for area-specific rules (say, API conventions that only load when API files are touched) so context stays lean. Since August 2026 Kiro also loads AGENTS.md files as steering from anywhere in the workspace tree; they are always included and have no inclusion modes, so they suit universal house rules (and are portable to other AI tools), while .kiro/steering/ remains the place for anything conditional.

Q11: Give some examples of hooks you’d actually set up.

Hooks run agent prompts or shell commands on events: file save/create/delete, prompt submission, agent turn complete, before/after tool invocation, before/after spec tasks, or manually on demand. Practical examples:

• On save of a source file, run the matching test suite.
• On file create, add the license header and a starter test file.
• After a spec task completes, update the affected documentation.
• A manual on-demand hook that walks the release checklist.

You create them in natural language or through a form, so the setup cost is minutes.

Q12: How do you review agent output before trusting it?

Treat it like a pull request from a new teammate: read the diff, run the tests, question anything you don’t understand. Kiro gives you three levers for this:

• Supervised mode: accept or reject each change, hunk by hunk.
• Checkpoints: roll the session back when a turn goes wrong.
• Property-based testing: for spec work, verify the code matches the spec.

The non-negotiable is that I never merge what I couldn’t explain.

Q13: What are checkpoints and when do they matter?

Checkpoints are restore points Kiro keeps so you can roll agent work back to an earlier state; they shipped with general availability and are created automatically on every prompt. They matter most in Autopilot, where the agent may take many actions between your reviews. The nuance that separates a good answer from a great one: only files the agent changed with its built-in file tools are tracked, so manual edits, formatters, MCP tool writes, and bash edits sit outside the snapshot. Checkpoints are a seatbelt, not a backup; git is still the source of truth.

Q14: What are context providers and which do you reach for?

They’re # commands that attach precise context to chat: #file, #folder, #codebase, #git diff, #terminal, #problems, #url, #code, #repository, #current, #steering, #docs, #spec, and #mcp. My defaults:

• #file for targeted edits, the precision tool.
• #git diff when discussing or reviewing in-flight changes.
• #problems to hand the agent current diagnostics directly.
• #codebase only when I genuinely don’t know where something lives.

Precise context beats dumping everything: it focuses the agent and wastes fewer credits.

Advanced / architecture questions

These come up in senior-level conversations, where the interviewer wants design reasoning, not feature recall.

Q15: What is EARS notation, and why do structured requirements help an AI agent?

EARS (Easy Approach to Requirements Syntax) writes requirements as “WHEN condition THE SYSTEM SHALL behavior”, with IF/THEN for error cases and WHILE for ongoing states. The structure forces testability and removes ambiguity, which matters doubly with an agent: vague requirements produce plausible-but-wrong code at machine speed. Structured statements also enable Kiro’s optional requirements analysis (which flags ambiguity, contradictions, and gaps) and give property-based testing something concrete to verify against.

Q16: How do custom agents work, and why restrict their tools?

A custom agent lives in .kiro/agents/ (workspace) or ~/.kiro/agents/ (global). In the CLI it’s a JSON config with fields like name, description, tools, allowedTools, resources, prompt, and model; you scaffold one with /agent create and switch with /agent swap. In the IDE, since the 1.0 release, it’s a Markdown file with tools and permissions in YAML front matter and the system prompt as the body. Restricting tools is least privilege: a reviewer agent that can read but not write cannot damage the codebase no matter how it misfires, and a smaller tool surface also keeps the agent focused. Kiro 0.9 first brought custom subagents to the IDE; IDE 1.0 added a capability-based permissions system on top.

Q17: Distinguish skills, steering, and powers.

• Steering is persistent project knowledge: conventions and context, included always or conditionally.
• Skills are portable instruction packages for procedures: a SKILL.md (name + description in YAML frontmatter) plus optional scripts/templates. They activate automatically on matching requests or can be invoked as /skill-name.
• Powers are technology bundles: a POWER.md plus MCP server config (and optional steering/hooks) that teach the agent a tool like Stripe or Supabase. They load on demand when keywords match, with less context overhead than always-on MCP, and since August 2026 they ship in the open Agent Plugin format.

Shorthand: steering = how this project works, skills = how to do a task, powers = how to use a technology.

Q18: How does MCP configuration work across scopes, and what’s the risk with autoApprove?

There are two config files (workspace .kiro/settings/mcp.json and user ~/.kiro/settings/mcp.json), and workspace takes precedence, so projects can override personal defaults. Server entries take command, args, env (with ${VAR} expansion so secrets stay out of the file), disabled, disabledTools, and autoApprove; remote servers use url, headers, and oauth. autoApprove (especially "*") lets tools run without confirmation: fine for trusted read-only tools, dangerous for anything that writes or deletes, because the agent acts with no human in the loop.

Q19: What are task waves in spec execution?

When Kiro executes tasks.md, independent tasks run concurrently in “waves”: tasks with no dependencies between them execute at the same time, and dependent tasks wait for their wave. The practical implication is to write tasks that are genuinely independent: small, decoupled tasks parallelize; one giant intertwined task serializes everything.

Q20: What would you consider before running Kiro headless in CI/CD?

Kiro CLI supports headless use with API-key auth, so agents can run in pipelines. With no human in the loop, I’d compensate at the edges:

• Run a custom agent with tightly restricted tools, not a general-purpose one.
• Commit steering to the repo so pipeline behavior is reproducible across runs.
• Gate every agent result behind tests and human review before merge.
• Watch credit consumption; automation multiplies usage quietly.

The principle: removing supervision from execution means adding it back at the boundaries.

Data engineering focused

If the role involves pipelines and warehouses, expect the interviewer to translate every Kiro feature into a data scenario. Kiro for Data Engineers is the long version of everything below.

Q21: How would you use specs for a data pipeline change?

EARS maps naturally onto data behavior: “WHEN a record fails schema validation THE SYSTEM SHALL route it to the quarantine table and log the failure reason.” The design.md captures the parts reviewers actually argue about (backfill strategy, idempotency, ordering), and tasks.md sequences the migration safely. Pipeline changes are exactly the “risky, hard to undo, others depend on it” category where specs earn their overhead.

Q22: How would steering encode warehouse conventions?

I’d write a steering file per domain: naming conventions (staging vs. mart layers, column casing), SQL style, partitioning and clustering rules, and which patterns are banned and why. Scope it with fileMatch so it loads only when SQL or model files are in play, and commit it so every engineer’s agent generates conforming code. Credentials never go in steering; those belong in environment variables.

Q23: Where does MCP fit in a data stack?

MCP servers can connect the agent to databases, warehouses, and catalogs so it can inspect real schemas instead of hallucinating column names. I’d pass secrets via env with ${VAR} expansion, auto-approve only read-only tools, and leave write operations behind confirmation prompts. AWS Aurora is among the launch partners for Kiro powers, which bundle exactly this kind of MCP setup with usage instructions.

Q24: How can Kiro help document datasets?

The spec files also work as living documentation: requirements.md records what a dataset is supposed to mean (acceptance criteria for freshness, grain, and quality), and it lives in the repo next to the pipeline code rather than in a wiki that drifts. Steering captures the conventions and known gotchas new teammates always trip over. A file-save hook can prompt the agent to update the dataset doc whenever the corresponding model changes, which attacks the real problem: docs going stale silently.

Q25: How would you test data transformations with Kiro?

Write the invariants as EARS acceptance criteria so they’re testable statements rather than wishes:

• Row counts in equal row counts out (or the filter is explicit).
• No nulls in key columns after the join.
• Totals reconcile with the source within tolerance.

Kiro’s property-based testing, a GA feature, checks that the implementation matches the spec. Properties suit data work especially well because they assert over whole distributions of inputs, not a few hand-picked rows. A hook that runs the test suite on file save closes the loop.

Software engineering focused

These map Kiro onto the situations engineers are actually graded on: refactors, bugfixes, reviews, migrations, and restraint.

Q26: How do you refactor safely with an agent?

Supervised mode plus checkpoints: I review every hunk as it lands, and if a turn goes sideways I roll back instead of untangling. I state the invariant explicitly (“behavior must not change; tests must stay green”) and keep steps small with tests run between them. The agent provides speed; the safety still comes from the same discipline as human refactoring, just enforced through review gates.

Q27: When do you write a bugfix spec instead of just hotfixing?

Kiro has bugfix specs, where the analysis goes in bugfix.md. I reach for one when the bug is risky or poorly understood: the written analysis forces root-cause thinking, so I fix the disease instead of the symptom, and the artifact documents the reasoning for the next person. For a trivial, well-understood fix, a quick supervised chat session is proportionate; process should scale with risk.

Q28: How would you build code review into Kiro?

Define a reviewer custom agent with read-but-not-write tools, a prompt encoding the team’s checklist, and resources pointing at the standards it should enforce (skills can be referenced via skill:// URIs). Kiro’s own tooling has moved this direction: CLI v2.5.0 added subagent review loops, and Kiro 0.9 introduced more granular code review. The key design choice is the tool restriction: a reviewer that cannot edit can be trusted to run liberally.

Q29: What happens when migrating from Amazon Q Developer CLI to Kiro?

Amazon Q Developer CLI was upgraded into Kiro CLI, and the transition is deliberately gentle: the q and q chat entry points keep working, and configuration auto-migrates from ~/.aws/amazonq to ~/.kiro. AWS publishes an official migration page in the Q Developer documentation. So existing muscle memory survives while you gain Kiro’s spec, steering, and agent features. Know the dates too: Kiro CLI succeeded Q Developer CLI on 17 November 2025, new Q signups closed on 15 May 2026, and plugins and paid subscriptions reach end of support on 30 April 2027. The per-IDE steps are in Migrate from Amazon Q Developer.

Q30: When would you NOT use an agent?

When I can’t competently review the output: high-stakes work in a domain I don’t understand is exactly where confident-looking wrong code hurts most. Also: one-line edits faster to type than to prompt, learning exercises where the struggle is the point, and problems where I haven’t formed the requirements yet, because an agent amplifies whatever clarity or confusion I feed it. Kiro’s checkpoints and Supervised mode reduce the cost of mistakes, but they don’t replace my judgment, which is precisely the answer interviewers are listening for.

Current as of 2026

These are the questions an interviewer asks to find out whether you have used Kiro recently or read about it two years ago.

Q31: What changed when Kiro Web became generally available?

Kiro Web left preview on 1 September 2026. It is available on Pro, Pro+, Pro Max, and Power, but not on Free. It works with GitHub and GitLab, and with AWS Identity Center sign-in it runs in us-east-1 only. Credits are consumed the same regardless of which surface does the work, so there is one pool across IDE, CLI, and Web. The features worth naming are autonomous mode (clarification, then planning, then execution by specialised sub-agents in an isolated sandbox, ending in a pull request) and Automations, which run a task hourly, daily, or on CRON, up to five schedules each, and open a PR. See Web.

Q32: What is Kiro Crew?

Kiro Crew is Kiro’s fifth surface: an open-source personal AI agent, Apache 2.0, that runs locally or remotely on your own hardware and is persistent, self-learning, and self-evolving. It complements the IDE, CLI, and Web rather than replacing them, and it uses the same building blocks: agents, integrations over MCP, skills, steering, hooks, and prompts.

What makes it a different kind of thing is persistence. It runs as a service (systemd on Linux, launchd on macOS), it keeps memory across sessions, it schedules recurring and reactive jobs, and it reaches you through chat channels rather than only a terminal. It has its own security model too: a governance ceiling where the tightest policy wins, denied-command patterns, sandbox modes, output redaction, an encrypted secrets vault, and a signed audit log. Model calls still go through kiro-cli, so credits apply.

Q33: How does Kiro’s permission system work?

It is capability-based. Rules are written against capabilities such as fs_read, fs_write, shell, web_fetch, web_search, mcp, subagent, skill, power, context, diagnostics, and sandbox_network, with all, builtin, and filesystem as meta-capabilities. Each rule has an effect: deny beats ask, and ask beats allow. Deny always wins regardless of scope, which is the sentence interviewers are listening for.

Rules live in ~/.kiro/settings/permissions.yaml for the user and in a workspace file kept outside the repository, across six scopes: Kiro’s own hardcoded rules, administration, user, workspace, agent, and session. A rule takes a match glob and an optional exclude. When the agent hits something unapproved, the prompt offers Allow, Deny, Always allow, or Always deny, persisted to all workspaces, this workspace, or this session. Recipe: permissions.yaml.

Q34: What is compaction, and what does it cost you?

Compaction is what Kiro does when the context window fills: it summarises older history so the session can continue. It keeps task status, file paths, decisions, and next steps, and it summarises tool output, old code snippets, and resolved errors. It runs automatically in the IDE, CLI, Web, and Mobile, and /compact triggers it manually in the CLI only.

The cost is that it is one-way. History before the compaction point is not recoverable. The practical implication, and the answer that shows judgment: anything that must survive belongs in a file (a spec, a steering rule, a commit message), not in the conversation. In the CLI you can tune compaction.excludeMessages (default 2) and compaction.excludeContextWindowPercent (default 2); the more conservative of the two wins.

Q35: What is the difference between a checkpoint and a rewind?

A checkpoint snapshots the files the agent changed with its built-in file tools, created automatically on every prompt. Restoring one puts the files and the agent’s context back and discards the later chat. A rewind forks the conversation at an earlier turn into a new session and leaves your files alone.

So: checkpoints change files, rewind changes only the conversation. Availability differs too, which is a fair follow-up: checkpoints are supported in the IDE and experimental in CLI V3, rewind is CLI-only, and “revert last turn” is IDE-only. Neither is available in Web or Mobile. And neither is a substitute for git, because manual edits, formatters, MCP tool writes, and bash edits are not tracked. Recipe: checkpoints and rewind.

Q36: How do Kiro’s configuration scopes work?

Two main scopes plus agent-level fields, and the closer scope wins. Global configuration lives in ~/.kiro/ and project configuration in .kiro/: MCP servers in settings/mcp.json, agents in agents/, steering in steering/, skills in skills/, hooks in hooks/, powers in ~/.kiro/powers/, and specs in .kiro/specs/.

The precedence rules differ by type, which is the detail that separates a rehearsed answer from real use. MCP goes agent, then project, then global. A project agent supersedes a global one of the same name, with a warning. Steering, skills, and hooks merge across scopes rather than overriding. Permissions use deny-overrides. KIRO_HOME relocates the global directory, which is how you keep separate profiles on one machine. Since September 2026, cloud configuration also syncs down into local IDE and CLI sessions as read-only previews; it does not overwrite local files, and you edit it in Kiro Web.