Interview Prep 2026: AI, Agile-AI, and ICAgile roles

Start by identifying the riskiest assumption (customer value, technical feasibility, or unit economics) and design the cheapest experiment that falsifies it within 2 weeks. Most candidates over-scope. I prefer the smallest test that produces a decisive signal: fake-door test for value, hardcoded prompt for feasibility, usage-cost model for economics.

Three layers. (1) Agent success rate, did the multi-step task complete without human override. (2) User trust score, NPS-style, did the user trust the output. (3) Downstream business KPI, revenue, churn, time-to-resolution. Agent success alone is a vanity metric. Trust is the leading indicator of retention.

Same framework as any prioritisation: RICE-weighted by confidence band. The AI tax is real (unit costs, latency variance, hallucination risk), so I discount AI-feature confidence by 30-50% versus a well-understood non-AI feature. If the AI feature still wins, it's the right call. If it only wins because the confidence numbers are guesses, ship the non-AI feature first.

Three categories. (1) Deterministic compliance work, regulators reject probabilistic answers. (2) Sub-10ms latency requirements, agentic inference adds variance most real-time products cannot absorb. (3) Cases where the human-readable explanation matters more than the answer, most legal, medical, and financial advice. The right framing isn't "should we use AI?" but "is the variance acceptable for the stakes?"

Two layers: structural and surface. Structurally, I ground every user-facing answer in retrieved documents (RAG) with citation and an explicit confidence threshold below which the agent declines. At the surface, I show the user the source and a "I'm not sure" affordance instead of pretending certainty. Confidence calibration matters more than raw accuracy in production.

Best answers acknowledge a real failure, name the leading indicator that was missing, and describe the post-mortem that produced a system change. Worst answers blame the model. Hiring managers test whether you own the operating model around the agent, not just the agent.

3-axis decision. (1) Is the capability differentiating? If yes, build the orchestration; buy the base model. (2) Can your team operate it for 3 years? If not, buy. (3) Does your unit economics survive vendor markup? If not, build inference. Most B2B SaaS should buy 80% of the stack and build the 20% that's actually their wedge.

A traditional PRD describes what the feature does. An agent PRD describes the policy the agent operates under. I write: agent goal, tools available, decision boundaries (what requires human approval), escalation paths, success metric, failure modes. The agent is a contract, not a feature.

It's the only honest measure in the agentic era. Story points and velocity assumed team capacity was the constraint. Agents made capacity elastic. The new constraint is clarity of intent, and Concept-to-Cash time measures clarity directly. I push leadership to adopt it because it strips away the easy gaming velocity invites.

Agent registry + policy library. Every named agent has an owner, a documented goal, a kill switch, a usage log, and an annual review. Without this, you wake up 12 months in with 40 agents nobody can explain and a customer-data leak you can't trace.

Hiring managers want a specific story with a clear reason and a number. "We killed X because metric Y stayed flat after Z weeks." Vague answers fail this. Sharp answers, even from junior PMs, pass.

Honestly, with the data, in a 1:1 not a meeting. The PM's job is to be the customer in the room. If the architecture doesn't serve customer outcome, you say so. Diplomacy matters but capitulation costs trust faster.

Coaching is asking questions that produce the coachee's own answer. Mentoring is sharing what worked for you. Teaching is transferring a curriculum. The difference matters because each requires permission. I always ask "what would be most useful right now: coaching, mentoring, or teaching?" Bad coaches conflate the three and end up telling when they should be asking.

I don't. I make myself useful in a non-coaching capacity for 4-6 weeks (facilitating, removing blockers, sharing patterns) until they ask for coaching. Pushed coaching damages the relationship. Earned coaching changes behaviour.

The traditional coach optimises team interactions among humans. The AI-Enabled coach also designs the team's human-agent collaboration: who decides what, when agents escalate, the policy for agent use of customer data, the team's working memory across humans and agents. The job got bigger, not smaller.

Honest answer names the structural reason, not the people. The pattern I've seen most: leadership wanted Agile but kept measuring teams by output volume. That misalignment kills every transformation. Strong candidates name it as a failure of the operating model, not a failure of the teams.

Three signals: (1) Decisions delegated downward, fewer decisions escalate to leadership over time. (2) Retro quality, retros produce specific committed changes, not generic complaints. (3) Coachee independence, they're not asking you the same question twice.

For pure flow work (support, ops, incident response), Kanban is better. For pure exploratory work (research, design discovery), Lean Startup loops outperform sprints. Scrum is excellent for delivery work with stable requirements. Bad coaches push Scrum into every context. Good coaches match the framework to the work.

Slowly, with a contract. Senior leaders don't want process, they want clarity on a decision they're avoiding. My first 60 minutes is always finding the decision underneath the decision. Once we name it, the rest is structure.

"What would you do if you couldn't blame anyone?", strips out the defensiveness and gets to the constraint people actually own. Bonus: "What's the smallest thing you could do this week that would prove this works?"

I check whether I was coaching or mentoring (I might have crossed the line without permission). If coaching, the answer is theirs not mine. If mentoring, I name that I gave advice they're rejecting and ask what they would do instead. Rejection is data, not insult.

Hiring managers ask this to test whether you actually understand the ICAgile pathway. The honest answer covers: which credentials you hold, which you're working toward, which engagement gave you the lived experience that complemented the credential. Vague answers signal credential collecting without practice. See the ICP-ACC pathway →

Layer-by-layer triage. (1) Observability first, is the agent's reasoning trace captured? (2) Input distribution drift, has the user input changed since deploy? (3) Model behaviour drift, has the base model been silently updated? (4) Tool failure, is an API the agent uses silently 5xxing? (5) Prompt drift, has someone edited a prompt without a regression test? Most production agent failures are at layer 1: nobody captured the trace.

MCP is the protocol that lets one agent talk to many tools through a standard interface. Before MCP, every integration was bespoke. After MCP, integrations compose. I treat MCP as the USB of agent tooling, the moment a tool has an MCP server, I prefer it over bespoke API integration. Released 2024 by Anthropic.

When the answer needs cross-document synthesis the retriever cannot perform, when the context is small enough to fit in the prompt directly, or when latency budget is tight and retrieval round-trips break the SLA. RAG is a tool, not a religion.

Four levers. (1) Smaller model for routing, the cheapest model decides whether the expensive model needs to think. (2) Aggressive caching, same input gets same output without re-inference. (3) Streaming + early stopping, kill generations the user has already dismissed. (4) Batch where possible. Most production AI costs are 5x what they need to be because nobody pulled the levers.

LLM-as-judge for most subjective dimensions (politeness, tone, completeness), with a regularly-sampled human review gold set as the calibration. Synthetic evaluation alone drifts. Human review alone doesn't scale. The pairing works.

Architecturally, not via prompt engineering. (1) Treat untrusted input as data, never as instruction. (2) Sandbox tool execution, agents cannot call destructive tools without human approval. (3) Output sanitisation for anything the agent writes back to your system. Defending against injection in the prompt itself loses the cat-and-mouse game.

Decompose: intent capture → constraint elicitation → search → user-facing shortlist → booking action → confirmation. Tools needed: OpenTable API, calendar API, payment if required. Failure modes: ambiguous time, location specificity, dietary requirements not in the API. The right answer maps the entire user journey and identifies which steps the human controls vs which the agent handles.

Prompt until you can't. Fine-tune when the same prompt pattern is consumed millions of times (cost), when latency matters (smaller fine-tuned model beats prompted large one), or when the task requires consistency a base model can't sustain. Most teams fine-tune too early.

Honest answers vary, but strong AI engineers spend 25-40% reading (papers, model release notes, weekly engineering posts) because the field moves too fast otherwise. Engineers who code 80% of the time without reading become obsolete within 12 months.

Specific stories beat generic enthusiasm. The story should include: the original time estimate, the AI-augmented time, what the AI did, what the human did, the failure mode the AI introduced. Hiring managers want to see honest accounting, not hype.

4Ls (Liked, Learned, Lacked, Longed for) for tactical retros. 5 Whys for incident retros. For AI-augmented teams I add an Agent Audit step: which agents shipped value, which slowed us down, which need redesign. The honest output is what changes next sprint.

Not by mediating. I work with the PO 1:1 first to identify the source of the trust gap (decision opacity, lack of context-sharing, perceived favouritism). Then I structure a Working Agreement session where the team names what they need from the PO. Mediating in real-time without preparation amplifies the problem.

From process-runner to designer of human-agent collaboration. The new work: facilitating role-identity shifts for engineers who feel displaced, designing the team's AI use policy at the team level, coaching the PO through what curation looks like when agents do the drafting. See: The quiet death of story points →

Not by velocity. By decisions delegated downward (more), retros producing specific shipped improvements (yes/no), and blockers resolved within the team versus escalated (lower escalation rate is better). Hiring managers know velocity is dead. Strong candidates know what replaced it.

Pre-work matters more than the session. I send a one-pager 48 hours ahead with: the goal, the decision needed, the options, the input we want from each role. In session, I time-box, surface dissent explicitly, and force a decision by the end. Most planning fails because facilitators wait for consensus to emerge.

DoD is a team contract. I add an AI verification clause for AI-augmented work: any agent-generated output ships only after the human owner reviewed the reasoning, not just the result. Without this, agent output silently rots the codebase.

1:1 first, usually the cause is a context they haven't shared (estimation pressure, blockers they're hiding, ambiguous acceptance criteria). I don't escalate to the manager until I've helped them name and ship the underlying problem.

Negotiate at the sprint goal level. If the new work serves the sprint goal, swap items. If it doesn't, defer to next sprint. The sprint goal is the protection, not Scrum theology, but the team's commitment to a meaningful chunk of value.

The work doesn't change, but the Definition of Done expands to include compliance artefacts. I work backwards from the regulator's acceptance criteria and build them into the team's sprint workflow rather than treating compliance as a separate phase. Most regulated-industry Agile failures come from treating compliance as a tax instead of a design constraint.

Scope. Scrum Master is accountable for the team's Scrum process. Agile Coach works across multiple teams, leadership, and operating model. The career path generally moves from SM to Coach as you build pattern recognition across many teams. See: Scrum Master vs Agile Coach →

Honest answer: only if you have a concrete situation at work where the curriculum applies within 90 days. Standalone credentials decorate LinkedIn. Sequenced credentials applied to real work change careers.

ICAgile is a lifetime credential across the entire agile space (coaching, leadership, product, AI). Scrum.org credentials require renewal and focus narrowly on Scrum framework knowledge. ICAgile is better for breadth and career flexibility. Scrum.org is better for proof of specific Scrum knowledge to gate-keepers.

If you're new to Agile: ICP (Agile Fundamentals). If you have Agile experience and want to coach: ICP-ACC. If you want the AI-Agile angle: ICP-FAI (AI Foundations) after ICP. Don't start with ICP-ENT, it requires the pattern recognition that only comes after coaching real transformations.

ICP-ACC is harder content. ICP-ENT is harder context. ICP-ACC tests your coaching toolkit. ICP-ENT tests whether you can apply it at organisation scale, which requires several years of lived experience. Don't take ICP-ENT until you've coached at least 2 multi-team engagements.

6 to 12 months of applied practice between each. Stacking credentials without time to apply produces certification collectors, not capable practitioners. The pathway only works if you ship the work between each step.

Read Lyssa Adkins' Coaching Agile Teams before the cohort. Identify one team you currently work with where you'd like to coach differently. Bring real situations to the role-plays. The cohort is more valuable when you arrive with specific pattern questions, not generic curiosity.

Yes if you're going to apply it within 90 days. The AI-Agile space is moving fast enough that a credential without applied practice ages out quickly. ICP-FAI plus shipping one AI-augmented workflow in your current role is the right pairing.

Not technically, many strong coaches have no ICAgile credential. But it shortens the screening conversation, especially for enterprise roles. Treat it as a hiring-friction reducer, not as proof of capability.

Three gaps: (1) political navigation in senior leadership rooms, (2) hard contract negotiation as a consultant, (3) operating-model design across organisations. ICP-ENT touches the third but lightly. The first two you learn from doing the work, not from training.

Founder-led by Prashant Shinde, with selected co-trainers for capacity. Every flagship cohort is taught by an instructor who has personally led the work being taught. See: About the founder →