17.2 — Behavioral and FDE Scenario Interviews

1. What is it?

This chapter covers the behavioral and scenario-based interview format specifically for AI FDE roles — questions probing how you've actually handled (or would handle) the customer-facing, judgment-heavy situations Part 12/13 taught, evaluated through specific past examples (behavioral) or hypothetical realistic scenarios (situational), rather than through a system design exercise.

2. Why does it exist?

Part 17.1 covered demonstrating technical/architectural judgment under interview conditions. This chapter exists because AI FDE work is defined as much by customer-facing judgment (Part 12's discovery discipline, Part 12.3's communication skill, Part 13's honest prototyping/demo practice) as by technical skill — and a candidate who can design a perfect architecture but has never demonstrated good judgment in an ambiguous, high-stakes customer conversation is missing a core, load-bearing part of the actual job.

3. What problem does it solve?

It solves "how do I demonstrate genuine customer-facing FDE judgment in an interview format that isn't a technical design exercise" — using the STAR framework (Situation, Task, Action, Result) applied specifically to the kinds of scenarios this handbook has built throughout (Part 12's discovery conversations, Part 13's honest demos, Part 9's security trade-offs communicated to stakeholders).

4. How does it work internally?

The STAR framework, applied to AI-FDE-specific scenarios

Situation: Brief context — what was the actual customer/project situation?
Task:      What was YOUR specific responsibility or the challenge you faced?
Action:    What did YOU specifically do (not "we" vaguely) — the reasoning
           process behind your choice matters as much as the choice itself
Result:    What happened, ideally with a concrete outcome or number,
           and what you learned (even from an imperfect outcome)

A strong answer's Action section should reveal the same kind of explicit reasoning this handbook has modeled throughout — e.g., "I asked three specific clarifying questions before proposing anything, because [Part 12.1's exact rationale]," not just "I talked to the customer and figured out what they needed."

Common AI-FDE-specific behavioral question categories, and what each is actually probing

• "Tell me about a time a customer's initial request wasn't what they actually needed." → probes Part 12.1's discovery discipline directly. A strong answer names the specific discovery technique used (not just "I asked questions") and the concrete gap it revealed.
• "Tell me about a time you had to explain a technical limitation to a non-technical stakeholder." → probes Part 12.3's layered-communication skill. A strong answer shows the specific translation, not just "I explained it clearly."
• "Tell me about a time a prototype/demo revealed a problem before full production investment." → probes Part 13.2's honest-prototyping discipline. A strong answer shows genuine value from the early discovery of a limitation, not a story where everything went smoothly.
• "Tell me about a time you had to push back on a customer's request." → probes judgment and the willingness to say no when warranted (Part 3.7/9.2's "don't build what wasn't actually needed/safe" instinct, applied interpersonally).
• "Tell me about a mistake you made in a customer-facing engagement, and what you learned." → probes genuine self-awareness and growth, not a disguised-brag "my weakness is I work too hard" non-answer.

The specific AI-FDE trap questions worth preparing for directly

"A customer wants you to build something you don't think will work well
— what do you do?"
  → Weak answer: "I'd just build what they asked."
  → Weak answer: "I'd refuse."
  → Strong answer: applies Part 12.2's feasibility-assessment discipline —
    propose a quick, cheap validation (Part 13.2) to get real evidence
    before either building the full thing or refusing outright, and use
    that evidence to have an honest, specific conversation with the
    customer about what's actually achievable.

"How do you handle a customer who wants an unrealistic timeline?"
  → Weak answer: "I'd just work harder."
  → Strong answer: proposes breaking the request into a fast, focused
    prototype validating the riskiest assumption first (Part 13.1's
    lifecycle, Part 13.2's prototyping), giving the customer real,
    early information to make a more informed timeline decision,
    rather than either accepting an unrealistic commitment or refusing
    without offering an alternative path forward.

5. Simple mental model

Behavioral interviews are like a reference check conducted directly with you instead of a former colleague — the interviewer is trying to predict your future behavior from your past behavior, and a credible, specific, honestly-detailed story (including imperfect outcomes and genuine lessons) is far more persuasive evidence than a polished, suspiciously-perfect anecdote that sounds rehearsed rather than real.

6. Real-world example

A candidate answering "tell me about a time a customer's request wasn't what they actually needed" with a specific, concrete story — "A customer asked for a fully autonomous agent for their document review process; I asked to see their actual process step by step first, which revealed 90% of it was a fixed, predictable sequence — I proposed a workflow instead, which ended up being both cheaper and more reliable, and I was upfront that I'd initially assumed an agent might be needed until the process mapping changed my mind" — directly and credibly demonstrates Part 3.7's core architectural judgment and Part 12.2's discovery discipline and genuine intellectual honesty (acknowledging an initial assumption that changed), all in one well-structured STAR answer, versus a vaguer "I always ask good questions" claim with no specific evidence behind it.

7. Architecture diagram

Not applicable — this chapter's content is interview strategy, not technical architecture.

8. Production considerations

• Prepare 5-7 specific, real stories in advance, each mappable to multiple possible question categories (section 4) — a well-chosen story about a discovery conversation might also serve a "pushed back on a customer" question or a "handled ambiguity" question with minor reframing.
• Practice the STAR structure explicitly, especially compressing the Situation/Task sections to leave more time for the Action/Result sections, which carry the most evaluative signal.
• Include at least one story with a genuinely imperfect outcome and a real lesson learned — an interviewer who only hears suspiciously perfect stories reasonably discounts their credibility.
• Rehearse the specific AI-FDE trap questions (section 4) explicitly — these come up frequently enough in this specific role's interviews to warrant dedicated preparation, not improvisation.

9. Common mistakes

• Answering with vague generalities ("I'm good at communication") instead of a specific, concrete story with real details.
• Using "we" throughout instead of clearly identifying your own specific contribution and reasoning.
• Only preparing success stories, with no genuine, honestly-examined mistake or imperfect outcome in the repertoire.
• Not connecting the story's Action section back to a specific, named technique or principle (Part 12/13's discovery/prototyping disciplines) — a story that could apply to any generic professional skill, not specifically AI FDE judgment.

10. Security considerations

Not directly applicable — though a strong behavioral answer to a security-adjacent scenario ("tell me about a time you had to balance customer convenience against a security risk") should reference the specific reasoning frameworks from Part 9 (excessive agency, least privilege, calibrated human-in-the-loop) rather than a generic "I take security seriously" claim.

11. Performance considerations

Not directly applicable to this chapter's content.

12. Cost considerations

A strong answer to "tell me about a time you had to manage a project's cost/budget" should reference specific techniques from Part 7.10/15 (model routing, caching, the ROI-netting discipline), not a vague "I was budget-conscious" claim.

13. When to use it

Any AI FDE interview process, which near-universally includes a behavioral/scenario component alongside technical and system design rounds.

14. When NOT to over-apply it

A purely technical, hands-on coding interview round doesn't need this preparation — match your preparation investment to the actual interview format you're facing.

15. Alternatives and trade-offs

The "alternative" to prepared, specific stories is improvising in the moment — riskier, since a genuinely strong, well-structured story under interview pressure is hard to construct from scratch, versus recalling and adapting a story you've already thought through carefully in advance.

16. Practical example — a prepared story bank template

from dataclasses import dataclass

@dataclass
class BehavioralStory:
    """A prepared STAR story, mapped to the question categories it can serve."""
    title: str
    situation: str
    task: str
    action: str          # should reference a SPECIFIC technique/chapter's principle
    result: str
    applicable_question_categories: list[str]
    lesson_learned: str  # even for a success story — what would you do differently

STORY_BANK = [
    BehavioralStory(
        title="Underwriting agent → workflow redesign",
        situation="Customer initially requested a fully autonomous agent for document review.",
        task="Determine the right architecture before committing engineering effort.",
        action="Mapped the actual process step-by-step (Part 12.2); discovered ~90% was fixed, predictable steps.",
        result="Proposed a workflow instead of an agent; delivered a more reliable, cheaper system.",
        applicable_question_categories=["discovery", "pushback", "architecture_judgment"],
        lesson_learned="I now explicitly map the process before agreeing to any architecture framing a customer proposes.",
    ),
]

17. Production-quality example

A mock-interview self-review checklist, directly extending Part 17.1's self-assessment rubric to the behavioral format:

# Behavioral Answer Self-Review

- [ ] Did I use a SPECIFIC, real example (not a generic claim)?
- [ ] Did I clearly identify MY OWN action and reasoning, not "we"?
- [ ] Did I reference a specific technique/principle (Part 12/13's
      frameworks) rather than a vague professional virtue?
- [ ] Did I include a concrete result, ideally with a number?
- [ ] Did I show genuine reflection/learning, even for a success story?

18. Short exercise

Using the STAR framework (section 4), write out a full answer to "tell me about a time you had to explain a technical limitation to a non-technical stakeholder," drawing on either a real experience or a plausible scenario based on this handbook's Part 12.3 examples — then review it against the section 17 checklist.

19. Interview questions

This chapter's content is itself a bank of interview questions (section 4) — practice each one explicitly, out loud, using a prepared story from your own experience or a well-reasoned hypothetical grounded in this handbook's frameworks.

20. FDE/customer scenario

Every behavioral question in this chapter is itself framed as an FDE/customer scenario — that's the entire point of this interview format, and the preparation discipline in this chapter (specific stories, STAR structure, technique-grounded reasoning) is directly transferable to how you'd actually reflect on and improve your real customer-facing judgment over a career, not just how you'd perform in an interview.

---

Key takeaways

• Behavioral interviews for AI FDE roles specifically probe the customer-facing judgment this handbook's Parts 12-13 taught — discovery discipline, honest communication, calibrated prototyping — not technical skill alone.
• Strong STAR answers reference specific techniques and reasoning (Part 12.1's discovery questions, Part 13.2's prototyping discipline) rather than vague professional virtues.
• Prepare a bank of 5-7 specific, real stories in advance, including at least one honest, reflective story about an imperfect outcome.

Things you should be able to explain

• The STAR framework and why the Action/Result sections carry the most evaluative weight.
• The specific AI-FDE trap questions and what strong versus weak answers to them look like.

Things you should be able to build

• A prepared story bank mapped to multiple question categories, and a self-review checklist for practicing answers.

Common mistakes

• Vague, generic answers with no specific real example.
• Using "we" instead of clearly identifying your own contribution.
• Only preparing success stories with no genuine, reflective lesson learned.

Recommended next chapter

03-technical-question-bank.md