AI / AI Fluency Interview questions

AI Fluency is the ability to work with AI systems in ways that are effective, efficient, ethical and safe. It goes beyond writing good prompts. It covers deciding what to hand to AI, explaining it clearly, judging what comes back, and taking responsibility for the result.

Anthropic, working with Rick Dakan and Joseph Feller, packages this as the 4D Framework: Delegation, Description, Discernment and Diligence.

In an interview, stress that fluency is a set of habits you can apply to any tool. Products change every few months; the habits carry over.

The 4Ds are four interconnected competencies: Delegation, Description, Discernment and Diligence. Each answers a different question you should ask when working with AI.

They are not a strict sequence. In real work you loop between them, especially between Description and Discernment.

Delegation means setting goals and deciding whether, when and how to involve AI in your work. It is the planning competency: you choose the split between what you do and what AI does.

It has three facets: Problem Awareness (understand your goal), Platform Awareness (understand what AI systems can and cannot do) and Task Delegation (divide the work sensibly).

Example: a manager lets AI draft routine status emails but writes performance reviews herself. That split is a Delegation decision.

Description is effectively describing your goals so AI produces useful behavior and output. Anthropic's framing treats it as more than prompting: you communicate what you want, how to get there, and how the AI should act while helping.

Its three facets are Product Description (the output you want), Process Description (the approach to take) and Performance Description (the AI's behavior in the conversation).

Act as a patient tutor. Ask me one question at a time.
Explain the answer in under 100 words, then give one practice problem.

Discernment is accurately assessing the usefulness of AI outputs and behaviors. It is the counterbalance to Description: you describe, then you judge what came back.

It has three facets: Product Discernment (is the output good), Process Discernment (was the reasoning sound) and Performance Discernment (did the AI behave well in the interaction).

The core habit is refusing to treat fluent, confident language as evidence of truth. Models can sound certain while being wrong.

Diligence is taking responsibility for what we do with AI and how we do it. It is the ethics and accountability layer of the framework.

Its facets are Creation Diligence (choosing systems and methods responsibly), Transparency Diligence (being honest with others about AI's role) and Deployment Diligence (verifying and owning what you ship).

The practical rule: AI can help produce the work, but accountability stays with the person who uses it.

The framework describes three ways people interact with AI. Choosing the right one is part of Delegation.

In automation, the AI executes a specific task based on a specific human instruction. You define the task precisely and the output is the goal.

Typical examples are converting formats, extracting fields from documents, or translating a block of text. Because the task is narrow, quality is easy to check against a clear standard.

The main risk is skipping review because the task feels routine. Even simple jobs can produce silent errors, such as a mangled date or dropped row.

In augmentation, human and AI collaborate as thinking partners. The work is iterative: you propose, the AI responds, you push back, and the result improves over several turns.

Brainstorming, critiquing a draft, and exploring trade-offs are typical uses. The human keeps judgment and direction while the AI widens the option space.

This mode relies heavily on the Description-Discernment loop, since each reply shapes the next prompt.

In agency, humans configure AI to independently perform tasks on their behalf in the future. You are not present for each action, so the setup does the heavy lifting.

Good configuration includes the goal, constraints, available tools, permissions, and when to stop or escalate to a person. A support-ticket triage agent is a common example.

Because review happens after or around actions rather than before each one, guardrails and monitoring matter more here than in the other two modes.

Problem Awareness is clearly understanding your goal and what a good result looks like before you involve AI. If you cannot say what done looks like, you cannot delegate it well.

Compare 'I need a summary' with 'I need a five-bullet summary for executives who must choose a vendor by Friday'. The second names the audience, the format and the decision it supports.

Weak Problem Awareness is a common root cause of poor AI output, and no amount of prompt polish fixes it.

Platform Awareness is knowing what different AI systems can and cannot do. That includes strengths, limits, and available tools.

Examples of things to know: the model's knowledge cutoff, its context window, whether it can search the web or run code, which file types it handles, and how likely it is to invent details.

If you need today's exchange rate, a model without live data access will guess from old training data. Platform Awareness tells you to pick a tool that can look it up.

Task Delegation is deliberately dividing work between you and AI based on the strengths of each, the risk involved, and your ability to verify the result.

A practical approach is to break the project into tasks, then label each one: AI does it, you do it, or you do it together. Here is how that might look for a market-research project.

Product Description defines what you want the output to be: its content, format, length, audience, style and constraints. It answers 'what should the finished thing look like'.

Write a 150-word onboarding email for new workspace admins.
Tone: friendly and direct. End with one call to action.

Without these details the AI fills the gaps with generic guesses, which is why vague prompts give bland results.

• Content: what must be included or left out.
• Format: email, table, bullet list, JSON.
• Audience: who will read it and what they already know.
• Length and style: word count, tone, reading level.

A quick test: if two different people could read your prompt and imagine very different results, the Product Description is still too loose.

Process Description guides how the AI approaches the task: the steps, the method, the framework, or the order of thinking. It answers 'how should you get there'.

For example: 'First list your assumptions, then calculate the cost, then show the result in a table'. You can also ask it to consider alternatives or to ask clarifying questions before starting.

It matters most for multi-step work, where a wrong method ruins the answer even if the writing looks polished.

Performance Description defines how the AI should behave during the interaction: its role, tone, level of challenge, and whether it asks questions or just answers.

Be blunt. Challenge my assumptions and ask clarifying
questions before you propose a solution.

Notice that this says nothing about the content of the answer. It sets the working relationship: a skeptical reviewer behaves very differently from a cheerful assistant, even on the same task.

Typical levers are the role (tutor, editor, devil's advocate), the tone, how much the AI should push back, and whether it should ask questions first. Restate these if the conversation drifts, since long chats tend to slide back toward agreeable defaults.

Discernment has three types, each looking at a different layer of the AI interaction.

Most beginners only do the first. Skilled users also watch how the answer was reached.

Diligence covers responsibility at three points in the lifecycle of AI-assisted work.

A hallucination is output that sounds plausible but is false or unsupported. Common forms are invented citations, made-up statistics, and function names that do not exist in a library.

It matters because the text reads just as confidently as correct text. There is no visual cue that something is wrong.

The quick defense is Product Discernment: check names, numbers, quotes and links against a primary source before using them.

It is the repeated cycle of describing what you want, evaluating what the AI returns, and then improving your description based on what you found.

1. Describe the product, process and behavior you want.
2. Receive the AI's output.
3. Discern what is good, wrong or missing.
4. Refine the description and try again.

Skilled users treat the first answer as a draft, not a verdict. Each round teaches you what the AI needs to hear.

Because every later effort depends on it. If you have not decided whether AI belongs in the task, you may spend time writing prompts and reviewing output for work that needed human judgment, or hand off something risky without any checks.

Delegation sets the stakes, the mode (automation, augmentation or agency) and how much verification is required. Those choices then shape what you describe and how hard you scrutinize results.

It is not strictly one-way. Poor results in Discernment can send you back to rethink Delegation, for example by taking a task back from AI.

Product Discernment judges what the AI produced. Process Discernment judges how it got there.

A correct answer reached by a flawed method is fragile; it may fail on the next input. One caution: shown reasoning is useful evidence but may not perfectly mirror what happens inside the model, so treat it as a clue rather than proof.

Pick automation when you can write the spec up front. Pick augmentation when you will only understand the problem by discussing it.

Hold back when the cost of an error is high and you cannot reliably verify the output. A useful test is: can I evaluate this, and what happens if it is wrong?

• High-stakes decisions needing human accountability, such as hiring, firing, medical or legal calls.
• Confidential data when the tool is not approved to handle it.
• Unverifiable work where you lack the expertise to spot mistakes.
• Relationship-heavy moments that need genuine empathy, such as delivering bad news.
• Learning goals, where doing the work yourself is the point.

You can still use AI for support, for example to prepare questions, while keeping the decision human.

Context removes ambiguity and examples show the exact shape of the result. The AI cannot guess your audience, constraints or house style, so it falls back on generic defaults.

Context answers who and why: the reader, the purpose, the limits. Examples answer what: a sample of the format, tone or structure you expect. Giving a couple of examples is often called few-shot prompting.

Classify each ticket as Billing, Bug or Feature.
Example: 'I was charged twice' -> Billing
Example: 'App crashes on login' -> Bug
Ticket: 'Please add dark mode'

On multi-step problems, writing out intermediate steps lets the model build on its own earlier work instead of jumping to an answer. It tends to reduce skipped steps and arithmetic slips.

It also helps your Process Discernment, because the steps are visible and you can spot the exact point where logic breaks.

It is not magic. It does not guarantee a correct result, simple lookups do not need it, and some newer models reason internally anyway. Shown reasoning can also be a tidy story rather than a faithful trace, so still verify the final answer.

Models can generate references that look real, with believable authors, titles and DOIs, but do not exist or do not say what is claimed. A well-known 2023 case involved lawyers sanctioned after filing a brief that cited AI-invented court decisions.

1. Search for the exact title or case name yourself.
2. Open the actual source, not just a summary.
3. Confirm the passage really supports the claim.
4. Drop any reference you cannot locate.

Format is not evidence. A perfectly styled APA entry can still be fiction.

Description happens before or during the interaction; Discernment happens as you observe the result.

Together they form a small feedback loop focused on the AI's conduct rather than its content.

It means being honest with the people who need to know about AI's role in what you produced. That might be a manager, a client, a professor, or readers.

How much to disclose depends on context: workplace policy, contracts, publication rules, and who could be affected. A short note such as 'Draft prepared with AI assistance and reviewed by me' often works for internal documents.

What it rules out is hiding AI use where disclosure is expected, or implying you did work you did not. It also supports trust: people can calibrate how much to rely on the work.

Models differ in ways that change whether a task can succeed at all. Picking blindly means you may discover a limit only after wasting time or trusting a bad answer.

Example: analyzing a 400-page contract points you to a large context window, while a stock-price question points you to live data access.

Errors travel unchecked into real decisions. A made-up statistic ends up in a board deck, a flawed function ships to production, or a biased summary shapes a hiring choice.

Part of the cause is automation bias: people over-trust output that looks authoritative. In 2024 a Canadian tribunal held Air Canada responsible for wrong refund advice its website chatbot gave a customer, a reminder that the organization owns what its AI says.

In chained or agentic workflows it gets worse, since a small early mistake becomes the input for every later step.

This is Creation Diligence in practice: decide what goes into the tool before you type anything. Work through these steps.

1. Classify the data: public, internal, confidential or regulated.
2. Use approved tools whose data terms match that class, including retention and training settings.
3. Minimize: send only what the task needs.
4. Redact or anonymize names, IDs and account numbers when patterns are enough.
5. Never paste secrets such as passwords, API keys or tokens.
6. Check regulations like GDPR or HIPAA that may restrict processing.

If the tool is not approved for the data, the answer is to not use it, not to hope for the best.

First diagnose which D is the problem. Wrong content usually means a gap in Product Description. A wrong method points to Process Description. A tone or collaboration problem points to Performance Description.

Then give specific feedback rather than 'make it better'. Say what to keep, what to cut and what to add.

Keep section 1. Cut the intro to two sentences.
Add two figures from Q3. Replace the jargon in section 3.

If the conversation has become cluttered with earlier mistakes, start a fresh one and carry over only the improved prompt.

Transparency Diligence sits between them: being open with others about AI's role in both how the work was made and what you are delivering.

Sycophancy is a model's tendency to agree with or flatter the user. In augmentation mode this is dangerous because you may take praise for your idea as validation of it.

It can reinforce your mistakes, tilt answers toward the opinion you revealed, and weaken your own critical thinking.

• Ask for the strongest objections to your plan.
• Do not reveal which answer you prefer.
• Use Performance Description: 'Act as a skeptical reviewer'.
• Compare with an independent source or colleague.

Treat it as a short decision flow: define the problem, test whether AI can plausibly help, test whether you can verify the output, then pick a mode.

flowchart TD
  A["Define goal and success criteria"] --> B{Can AI plausibly help?}
  B -- No --> H["Do it yourself"]
  B -- Yes --> C{Can you verify the output?}
  C -- No --> D{Are stakes high?}
  D -- Yes --> H
  D -- No --> E["Delegate with spot checks"]
  C -- Yes --> F{Is the task well specified?}
  F -- Yes --> G["Automation or Agency"]
  F -- No --> I[Augmentation]

The first gate is Problem Awareness, the second is Platform Awareness, and the rest is Task Delegation. If the output cannot be verified and the stakes are high, the task stays with a person or gains an independent check.

Revisit the decision after the first results. Discernment often shows the split was wrong.

Start simple, inspect the weaknesses in the output, and change only what the evidence points to. Here is a worked example.

v1: Summarize this report.
  -> Output: long, generic, no numbers called out.

v2: Summarize this report for a CFO in 5 bullets.
    Flag any metric that changed more than 10% vs last quarter.
    If something is not stated in the report, write 'not stated'.

The audience and format fix the generic tone (Product Description). The 10% rule defines what matters. The 'not stated' rule discourages invented figures by giving the model a safe exit.

Change one or two things per round so you can see what worked, and keep a small set of test inputs to compare versions against.

Make it practical and role-based, not a one-off lecture. A workable plan looks like this.

1. Baseline how people use AI today, through a short survey and sample reviews.
2. Map the 4Ds to roles: for example, support leans on Description and Diligence, tech leads on Delegation and Discernment.
3. Set data rules: approved tools, what may be pasted, disclosure expectations.
4. Define review standards for AI-written code, tests and docs.
5. Build a shared library of tested prompts and example failures.
6. Practice on real tasks with feedback, not toy exercises.
7. Track outcomes such as defect rates, review time and incident reports.

One limit to note: the 4D Framework focuses on individual competence, so pair it with organizational governance and responsible-AI policy.

Do not argue with the tone. Work out what kind of claim is wrong, then change the setup so the model has something solid to stand on.

1. Classify the error: fact, number, citation, logic or code.
2. Check a primary source to confirm it is really wrong.
3. Ground the model: paste the source text and ask for answers backed by quotes from it.
4. Use tools for what models do poorly, such as search for fresh facts or code execution for arithmetic.
5. Add a safe exit: 'If the document does not say, answer unknown'.
6. Cross-check with an independent pass or source.
7. Record the failure as a test case for future prompts.

Asking 'are you sure?' is weak verification. The model may simply flip or repeat its answer without any new evidence.

In automation you see the output before it matters. In agency the AI acts on its own, so mistakes can compound or take effect before you look.

Roll out in stages: sandbox first, then limited scope, then wider use as evidence builds.

With an agent, the final answer is only the last line of a longer story. You need to inspect the plan, tool calls, intermediate results and decisions, not just the summary at the end.

Things to look for: tool results the agent invented instead of fetching, steps it quietly skipped, early stopping, and shortcuts that satisfy the check but not the goal, such as deleting a failing test so the suite passes.

• Review logs or traces, not only the final report.
• Add checkpoints where a person confirms before the next phase.
• Sample runs regularly instead of reviewing only failures.
• Compare claimed actions with what actually changed.

Green results are not proof of good process.

The reviewer stays accountable for the merge. AI findings are leads to verify, not verdicts.

Look for habits, not tool names. Strong candidates describe specific work and how they checked it.

• Ask for a recent real example and probe each D: what they delegated, how they described it, what they verified, what they disclosed.
• Give a flawed AI output and ask what they would check before using it.
• Ask about a time AI was wrong and what changed afterward.
• Ask how they handle confidential data in AI tools.

Green flags: verification habits, awareness of limits, clear iteration process. Red flags: blind trust, only listing tool names, no examples of failure.

Shaping a new strategy is augmentation. Triage of identical low-risk tickets is a candidate for agency. Many projects start as augmentation to learn the problem, then graduate to agency once the rules are clear.

Variation has several sources: sampling randomness, an ambiguous prompt, differences in the context supplied, and model version changes. Find which one you are dealing with.

1. Tighten the Product Description: give an exact output schema or template.
2. Add examples that show the expected format.
3. Lower randomness where the tool allows it, remembering that even then results may not be perfectly identical.
4. Use structured output options if available, and validate them in code.
5. Pin the model version in production.
6. Build a small evaluation set and score each prompt change against it.

The evaluation set matters most. Without it you are judging prompt changes by feel, based on whichever run you happened to see.

Literacy helps, but you can pass a vocabulary quiz and still trust a fabricated citation. Fluency shows up in behavior, which is why interviews should ask for examples.

Bias can come from training data, from how you frame the prompt, and from proxies hidden in the inputs. Work on it at every D.

• Delegation: keep high-impact decisions, such as hiring and lending, with accountable people.
• Description: state explicit, job-relevant criteria and avoid leading questions.
• Discernment: run counterfactual swap tests: change a name or protected attribute and see whether the output shifts.
• Diligence: document the process, comply with applicable law, and offer a way to appeal.

Framing matters. 'Why is this candidate probably a weak fit?' invites a negative story, while 'Score against these four criteria' does not.

For complex work a chain is usually better because it gives you places to apply Discernment. For a quick summary, a single prompt is enough. A hybrid works well: chain the stages, but keep each prompt focused.

A language model is trained to predict likely next tokens given the text so far. It produces fluent continuations, but nothing in that objective checks whether a statement is true.

1. Pattern completion: asked for a citation, the model generates something shaped like a citation.
2. Knowledge gaps: rare or niche facts appear few times in training, so the model's recall is weak.
3. Pressure to answer: training and evaluation can reward a confident guess over saying 'I do not know'.
4. Compounding: once a wrong token is generated, later tokens are conditioned on it and elaborate the error.
5. Missing grounding: without documents or tools, the model has only its internal memory.

This is why grounding in supplied sources, retrieval, calculators and permission to say 'unknown' reduce the problem. They do not eliminate it, so Discernment stays necessary.

Take a project such as writing a customer-churn summary for leadership. The 4Ds appear as a flow with loops, not a straight line.

flowchart TD
  A["Delegation: define goal and split tasks"] --> B["Description: product, process, performance"]
  B --> C["AI produces output"]
  C --> D{Discernment: good enough?}
  D -- No --> B
  D -- Rethink split --> A
  D -- Yes --> E["Diligence: verify, disclose, own"]
  E --> F["Deploy and share"]

1. Delegation: decide AI drafts the analysis, you choose the recommendations, and confirm the data tool is approved.
2. Description: specify audience, format, method and the AI's role as a critical reviewer.
3. Discernment: check numbers against the source, inspect the method, note how the AI responded to feedback.
4. Loop: refine the description or take a task back from the AI.
5. Diligence: verify before sharing, disclose AI help as required, and accept accountability.

Diligence is present throughout, but it carries the most weight right before deployment.