Skip to content

Interview Personas

Question banks for interviewing the people who build, operate, and oversee FCC-based systems. Organized by role. Use as a starting deck; adapt to your story.

Interviewing a principal engineer (the builder)

Goal: understand what was actually built, not what the marketing says.

  • "Which FCC version is the deployment pinned to?"
  • "How many personas are active in production?"
  • "Which persona carries the highest risk classification?"
  • "When did you last run the compliance audit? Can I see the ComplianceReport?"
  • "Which constellation-vertical, if any, do you consume?"
  • "Which workflow graph do you use — base-5, extended-20, or a larger one?"
  • "What changed between the last release and this one, in plain language?"
  • "Where does the system fail most often, and what does the Critique persona do then?"
  • "Is there a persona whose constraints you tightened after a near-miss?"
  • "What's the longest trace you've ever seen in production?"

Follow-up: ask to see one anonymized trace. Offer to look without quoting; it builds trust.

Interviewing a product manager or executive

Goal: understand the decision logic, not just the marketing.

  • "Who decided to adopt FCC, and what were the alternatives?"
  • "What measure of success are you using? How is it auditable?"
  • "Who inside your organization owns the compliance report?"
  • "What kind of failure would cause you to shut the system down?"
  • "What's your procurement clause for FCC-based vendors, if you have one?"
  • "Have you ever rejected a release because of a compliance finding?"
  • "How do you brief your board on the risk classification of AI deployments?"
  • "Do you publish anything about this deployment to citizens/customers/users?"

Follow-up: ask for the most recent board update mention of AI. If one does not exist, that is reportable.

Interviewing a deployment operator or SRE

Goal: understand real-world behaviour.

  • "What does a typical week of trace data look like?"
  • "How often does the Critique halt a run?"
  • "Have you ever seen a persona behave unexpectedly?"
  • "What dashboards do you look at each morning?"
  • "Has the risk heatmap changed over the last quarter?"
  • "How do you handle a compliance finding between releases?"
  • "What's the hardest thing to debug in an FCC trace?"
  • "Who gets paged at 3 a.m. if something goes wrong?"

Follow-up: ask for a redacted sample dashboard screenshot. Useful for long-form feature.

Interviewing a compliance officer or regulator

Goal: understand the regulatory frame without straying into legal advice.

  • "Which regulation(s) apply to this deployment?"
  • "How do you verify EU AI Act / NIST AI RMF crosswalks independently?"
  • "What evidence item, if missing, would be a blocker for sign-off?"
  • "What's your policy on evidence older than 180 days?"
  • "How are remediation timelines enforced?"
  • "What's the worst-case scenario you plan for?"
  • "Are there findings you have accepted-with-risk, and what's the rationale?"
  • "What's your process if you disagree with the engineering team's risk classification?"

Follow-up: regulators rarely speak about active matters. Ask about patterns across their portfolio.

Interviewing an affected user or constituent

Goal: understand real-world impact.

  • "How did you first encounter this system?"
  • "Were you told it was AI-powered? In what language?"
  • "What happened when you contested a decision?"
  • "Were you offered a human reviewer?"
  • "Did you receive a copy of any findings, remediation plan, or similar document?"
  • "If you could change one thing about how this system treats you, what would it be?"

Follow-up: if the user has documentation of their interaction, request permission to quote.

Interviewing a researcher or academic critic

Goal: sharpen your analytical frame.

  • "What's your argument for / against this deployment pattern?"
  • "Is there prior work that replicated or contradicted the vendor's claims?"
  • "What would count as evidence your criticism is wrong?"
  • "Are there FCC design decisions you consider underappreciated?"
  • "Where do you think the framework will be in five years?"

Follow-up: ask for the one reference that shaped their thinking most recently.

Cross-cutting questions

Four questions you can ask any source:

  • "What's the one thing you wish journalists would ask more often?"
  • "What's the one thing you wish journalists would stop asking?"
  • "Who else should I talk to?"
  • "What am I missing?"

The last question, asked late in an interview, is often the most productive.

Prepping the source

Before an interview, send a short note:

"For context: I'm planning to ask about the FCC version, the active persona set, the most recent ComplianceReport, and any recent changes. If any of this requires pre-approval on your side, let me know."

This signals seriousness and often surfaces the artifacts before the interview itself.

On-record / off-record protocol

FCC-world sources vary. Some are open-source maintainers who assume everything is on record; some are corporate counsel who assume nothing is. Negotiate ground rules early. A useful compromise:

  • Framework and architecture topics: on record.
  • Specific internal deployment details: background unless otherwise agreed.
  • Future-plan speculation: off record unless attributed to a published doc.

Verifying answers

Every technical answer should be checkable against an artifact. If your source says "our Critique persona halts 3% of the time," ask: "Is that in a dashboard? Can you send a screenshot?" If it isn't, treat the number as a claim, not a fact.

Where next

Interviews done, file your piece. Then return here for the next story: Citation Guide for bibliography; Further Reading for background; Reproducibility Primer if you are writing about a quantitative claim.