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 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.

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 three surfaces?

• IDE: a desktop app forked from 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 (in preview) that works against GitHub and GitLab and can create PRs/MRs.

The core concepts (specs, steering, hooks, MCP) carry across all three.

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.

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; Autopilot trades review friction for speed, Supervised trades speed for control.

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.

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.

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.

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. They matter most in Autopilot, where the agent may take many actions between your reviews. Knowing every step is revertible is what makes granting that autonomy reasonable.

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 is a JSON config (in .kiro/agents/ for the workspace or ~/.kiro/agents/ globally) with fields like name, description, tools, allowedTools, resources, prompt, and model; in the CLI you scaffold one with /agent create and switch with /agent swap. 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 brought custom subagents to the IDE as well.

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.

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.

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.

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.