Anthropic Applied AI and FDE delivery practice: 15 evidence-based questions

Customer delivery requires an explicit owner

The following 15 inferred practice questions are original editorial exercises, not an official Anthropic question list or scorecard. Their fact IDs point to the verified role reference, checked 2026-10-05. Tokyo Engineer, pre-sales Architect and Partner Architect own different work. The US Technical Deployment Lead and New York Manager sections are labeled separately; their SOW, ROI or staffing ownership must not be silently assigned to every FDE.

Use actual decisions, artifacts and outcomes, identifying your contribution and other owners. A good answer can include an unsuccessful pilot if it shows how evidence changed the plan. Do not replace an unrecorded result with a polished number. The AI-use policy, last-updated 2025-07-10, permits preparation and refinement while reserving take-home/live assistance for explicit permission (A010–A014). Write your first application draft yourself and practice explaining the same evidence unaided.

Input contracts, evaluation, recovery and stakeholder decisions are shared practices across companies. The role facts determine which responsibility to emphasize; these exercises do not invent proprietary Anthropic methods.

1. 1Customer objective
2. 2workflow and stakeholders
3. 3scope, owner and success measure

1. 1Engineer or Architect or Partner
2. 2role-specific contribution
3. 3delivery evidence

1. 1US TDL scope and value ownership
2. 2FDE technical implementation
3. 3joint decision and handoff

1. 1Observed result
2. 2sponsor review
3. 3product feedback or next engagement

Original responsibility-and-evidence flow. The US TDL/FDE row represents a split stated in A067–A071; the other rows organize preparation, not an official universal engagement process. The useful question at each arrow is “who could decide, what evidence did they receive, and what changed?”

AN-DQ01: Why Anthropic, and why this particular role?

Scope and evidence: Tokyo Engineer or pre-sales Architect; choose one target role — A004, A006, A007, A014, A018, A027, A028; All roles; technical roles where stated, All candidates, Applied AI Engineer, Applied AI Architect.

Inferred practice question: How would you connect your motivation for Anthropic with the concrete work of the role you are applying for?

What it may test — editorial inference: Whether motivation is supported by authentic experience and an understanding of the chosen role, rather than a general enthusiasm for AI.

Evidence and decisions to explain: Choose one real decision in which you learned something about useful, reliable or safe systems. State your contribution, the tension you faced and what changed your view. Connect it to one or two verified duties: Engineer pilot/implementation work or Architect pre-sales guidance. Explain the work you want to own and a capability you still need to build. The public application’s 200–400-word suggestion is not a required spoken-answer duration.

Deep dives:

1. A customer wants a short-term result that conflicts with your stated safety concern. What do you do? Name the actual consequence and evidence, propose a narrower way to create value and involve the authorized owner. Show how the mission affects a decision, without inventing a universal company rule or claiming that every disagreement must end in refusal.
2. Why not the adjacent Engineer or Architect role? Compare the ownership you seek with the neighboring role’s published responsibilities. Use your actual contribution to explain the fit and acknowledge gaps. Avoid ranking roles or claiming their interviews are identical.

Avoid a shallow answer: “Anthropic is a leading AI company and I share its values.” Add a personal decision, a verified responsibility and a specific reason for this role.

AN-DQ02: Which customer problem deserves the first pilot?

Scope and evidence: Tokyo Applied AI Engineer; AE collaboration and customized pilot — A019, A020, A025; Applied AI Engineer.

Inferred practice question: An AE brings several possible Claude use cases from a Japanese enterprise. How would you choose a pilot and align customer expectations?

What it may test — editorial inference: Whether technical discovery produces a justified priority and an achievable customer commitment.

Evidence and decisions to explain: Describe a real prioritization decision. Compare the current workflow, value owner, user pain, available evidence, integration effort and failure cost across the candidates. Identify one testable value hypothesis and the sponsor who can validate it. Agree what the pilot will prove, what it will not prove and which contribution comes from AE, customer and Engineer. Use actual business measures where available; not every prioritization needs a latency statistic.

Deep dives:

1. The easiest demo has little business value. Should you choose it? Explain whether it resolves a necessary uncertainty or merely looks impressive. Compare it with a harder but decision-relevant pilot, including time and dependencies. A small pilot earns its place by changing an adoption decision.
2. The AE has already promised capabilities you have not verified. What do you do? Clarify the exact promise, evidence and customer expectation promptly with the AE. Provide a verification plan and feasible scope, then align the customer-facing correction. Do not quietly absorb an unsupported commitment into engineering work.

Avoid a shallow answer: “We prioritize high ROI use cases.” State the value hypothesis, feasibility evidence, owner and agreed pilot boundary.

AN-DQ03: How do you move a technically interested enterprise toward a decision?

Scope and evidence: Tokyo Applied AI Architect; pre-sales and complex enterprise buying cycles — A028, A030, A033; Applied AI Architect.

Inferred practice question: Engineering likes a Claude evaluation, but IT, the business sponsor and procurement need different evidence. How would you structure technical discovery and the buying decision?

What it may test — editorial inference: Whether pre-sales advice identifies decision-makers, blockers and the evidence each party needs without pretending technical approval is a purchase.

Evidence and decisions to explain: Use a real stakeholder map: user, technical evaluator, platform owner, sponsor, buyer and approval functions. Identify each person’s decision, concern and evidence, then sequence the evaluation dependencies. Explain your responsibility with the AE and the customer’s authority. Record why a meeting or artifact changed the decision. Do not infer contract terms, pricing or approval rights from this job description.

Deep dives:

1. The technical champion cannot obtain a sponsor. What changes? Validate the business problem and identify who owns its outcome. Provide a concise decision artifact for that owner and clarify whether more technical work would resolve the commercial blocker. Pause work that has no accountable adoption decision.
2. Procurement enters late and changes the schedule. How do you respond? Make the dependency and impact visible, find what evidence is required and revise the plan with the customer and AE. Distinguish a technical milestone from a purchase commitment; avoid promising a procurement outcome you cannot control.

Avoid a shallow answer: “We build relationships with all stakeholders.” State the decision each relationship supports and the sequence of evidence.

AN-DQ04: Can you explain one technical setback to two audiences?

Scope and evidence: Tokyo Engineer and Architect; required Japanese/English proficiency, audience-specific communication — A023, A031, A034; Applied AI Engineer, Applied AI Architect.

Inferred practice question: Explain the same deployment setback to a customer executive and an engineering lead, then prepare a consistent Japanese/English handoff.

What it may test — editorial inference: Whether communication changes detail while preserving facts, uncertainty and the next decision. Language requirements do not establish actual interview language or format.

Evidence and decisions to explain: Choose a real setback and keep a shared factual core: observed behavior, impact, what is known, what remains uncertain, options and owner. For executives, explain the business consequence and decision needed; for engineers, include the failing boundary and reproduction. Prepare a short bilingual terminology list and check that risk, dates and commitments retain the same meaning. Do not make the English version sound more certain than the Japanese one.

Deep dives:

1. The executive asks for a completion date you cannot support. What do you say? State what is known, the dependency preventing an estimate and the next evidence checkpoint. Offer conditional options with owners. Do not invent a date to appear confident.
2. The engineering lead disagrees with your explanation in the meeting. What do you do? Distinguish disagreement about observations, cause and priority. Check the evidence, correct a mistaken claim plainly and record unresolved hypotheses for follow-up. Maintain the same customer-facing facts after the meeting.

Avoid a shallow answer: Using a simpler story that omits material uncertainty, or claiming that fluent language alone resolves the technical disagreement.

AN-DQ05: How do you resolve incompatible success expectations?

Scope and evidence: Tokyo Engineer/Architect; cross-functional trade-offs and customer advice — A025, A030, A031; Applied AI Engineer, Applied AI Architect.

Inferred practice question: The business sponsor wants rapid adoption, IT wants a narrow approved architecture and the users want changes beyond the pilot scope. How do you move the work forward?

What it may test — editorial inference: Whether you make competing priorities explicit and obtain an accountable decision instead of promising all outcomes simultaneously.

Evidence and decisions to explain: Describe a real conflict with each party’s objective, non-negotiable constraint and decision authority. Identify which disagreement is factual and which is a preference. Present viable options with consequences for scope, effort and risk; show the decision record and what was deferred. Explain your role in coordination without claiming authority over the customer’s policy or every stakeholder.

Deep dives:

1. No one will accept the reduced scope. What then? Identify whether the value hypothesis still holds. Escalate the specific unresolved choice to an owner and propose a time-bounded discovery step if it can change the decision. A clear pause can be better than an unsupported promise.
2. A compromise satisfies the sponsor but makes the workflow unusable. How do you detect it? Bring operator feedback or a workflow trial to the decision, and distinguish adoption pressure from useful completion. Explain the evidence that reopens the compromise and how affected users are represented.

Avoid a shallow answer: “I align stakeholders.” Name the unresolved choice, decision owner, accepted consequence and deferred work.

AN-DQ06: What makes go-live become sustained adoption?

Scope and evidence: Tokyo Applied AI Engineer; onboarding and ongoing advice beyond go-live — A020, A021, A025; Applied AI Engineer.

Inferred practice question: A pilot passes its evaluation and reaches go-live, but users keep returning to their old workflow. What do you investigate and change?

What it may test — editorial inference: Whether you distinguish technical launch from useful customer adoption and work with the owners of the operating process.

Evidence and decisions to explain: Use an actual rollout or a labeled plan. Trace how a user enters the workflow, reviews results, handles errors and obtains support. Compare evaluation success with usage, task completion, manual rework and user reasons for avoiding it. Identify training, fit, access or ownership gaps rather than immediately tuning the model. Agree the customer operating owner, support boundary and review cadence, and report adoption only with a meaningful population and period.

Deep dives:

1. Usage grows but manual rework also grows. Is that success? Compare completed useful work and total human effort with the baseline. Review the failure categories and incentives driving usage. Explain whether the workflow, support or evaluation needs changing; adoption volume alone does not establish value.
2. The customer expects indefinite personal support. How do you respond? Clarify the actual support agreement and responsible teams, document operating procedures and open issues, and plan a handoff with the customer owner. Do not invent contractual service levels or abruptly remove a dependency you created.

Avoid a shallow answer: “We trained users and increased adoption.” Show the workflow problem, operating owner and evidence of useful completion.

AN-DQ07: How do you keep an agent engagement within an agreed scope?

Scope and evidence: US Technical Deployment Lead and FDE collaboration; SOW ownership belongs to TDL — A067, A068, A071; Technical Deployment Lead.

Inferred practice question: In the US TDL/FDE delivery split, how would you turn an engagement’s SOW into a sequenced implementation plan and handle a new customer requirement?

What it may test — editorial inference: Whether you understand scope/change ownership and can connect technical work to an agreement without assigning all contracting responsibility to FDEs.

Evidence and decisions to explain: For TDL experience, show the agreed outcome, exclusions, milestones, dependencies, success criteria and decision authority. For FDE experience, show the technical estimates and risks you supplied to that owner. Trace one requirement to a deliverable and acceptance evidence. Explain how a new request affects the critical path, scope and approvals. Describe actual contract-change handling only if you participated; do not claim TDL responsibilities merely because you implemented code.

Deep dives:

1. The new requirement is small in code but changes an external approval. How do you assess it? Include the approval dependency, test scope and customer decision in the estimate. Present the schedule and risk change to the TDL rather than accepting it as a harmless coding task. Size is not only lines of code.
2. The milestone date is fixed and the implementation estimate increases. What changes? Offer explicit alternatives: narrower accepted scope, another sequence or a revised date, with technical consequences. Let the authorized lead/customer owner decide. Record deferred work and the revised acceptance evidence.

Avoid a shallow answer: “The FDE owns everything end-to-end.” The source explicitly separates technical implementation from TDL scope, stakeholders and value ownership.

AN-DQ08: How do you measure value without overstating ROI?

Scope and evidence: US TDL owns value measurement; FDE provides implementation/evaluation evidence — A067, A069; Technical Deployment Lead.

Inferred practice question: A sponsor asks whether an agent deployment paid off. How would you define the baseline, measure the change and report uncertainty?

What it may test — editorial inference: Whether business value is a defensible measurement rather than an accuracy improvement translated into invented savings.

Evidence and decisions to explain: Describe the value owner, baseline workflow, workload, observation period and total human/operating effort, including review and exceptions. Separate a value hypothesis from observed impact and from a causal claim. A hypothetical worksheet with 80 reviews/day changing from 12 minutes to 8 minutes plus 2 minutes of new review yields 80 × (12 − 10) = 160 minutes/day before other costs; these are invented exercise inputs, not customer results or company targets. Explain what would verify the workload and whether freed time was used.

Deep dives:

1. Throughput rises but staffing does not change. Can you call it cost savings? Distinguish capacity, elapsed time, cash savings and quality. Describe the realized outcome and its value owner; do not turn theoretical hours into eliminated cost without evidence of how the organization used them.
2. Another process change occurred at the same time. How do you attribute value? Compare relevant cohorts or periods where feasible, record confounders and report the limited inference. State which observation is reliable and which causal claim needs more evidence. A transparent range can be more useful than an unsupported precise ROI.

Avoid a shallow answer: “We saved 30% because the model was more accurate.” Explain the baseline, review effort, realized outcome and uncertainty.

AN-DQ09: What does a delayed security review change?

Scope and evidence: US TDL/FDE collaboration; security, legal, procurement and compliance dependencies — A068, A070, A071; Technical Deployment Lead.

Inferred practice question: An agent implementation is technically ready but a security or procurement review is unresolved. How do you adjust the delivery plan?

What it may test — editorial inference: Whether enterprise constraints are treated as part of delivery, with clear authority and technical evidence. This is preparation, not legal advice.

Evidence and decisions to explain: Identify the exact pending decision, owner, required evidence, affected environment and critical-path dependency. As FDE, describe the technical boundary, permitted data/actions and proposed test evidence; as TDL, describe sequencing, scope and stakeholder decisions. Compare a restricted demonstration, reduced deployment or delayed milestone only if those options meet the customer’s requirements. No job posting establishes specific data-residency, retention or compliance rules.

Deep dives:

1. The sponsor asks you to bypass the review for a small pilot. What do you do? Clarify which policy and authority apply to that environment. Offer a properly approved restricted scope or synthetic demonstration where valid. Do not label a smaller deployment compliant without the responsible owner’s decision.
2. The reviewer requests a control that the planned design lacks. How do you proceed? Translate the request into a testable requirement, determine whether a design change or clarification is needed and give the TDL an impact assessment. Track the resolution evidence and acceptance owner rather than substituting assurances for the missing control.

Avoid a shallow answer: “We passed compliance” without stating the actual review, scope, owner and evidence.

AN-DQ10: How would you strengthen a partner’s AI delivery capability?

Scope and evidence: Tokyo Applied AI Architects, Partner; partner-facing pre-sales — A037, A038, A039, A041, A042; Applied AI Architects, Partner; body: Partners Solutions Architect.

Inferred practice question: A GSI or cloud partner wants to build a Claude practice. How would you choose technical enablement and joint-solution work that survives beyond one deal?

What it may test — editorial inference: Whether partner work develops an indirect delivery channel and capability, not just an individual customer prototype.

Evidence and decisions to explain: Describe the partner’s target customers, current technical skills, delivery gaps and joint opportunity. Choose a bounded industry use case, reference architecture and enablement exercise with named partner owners. Explain which capability is transferred, how independent delivery is observed and what feedback returns to Product. Separate partner-driven revenue goals from technical enablement evidence; the posting does not disclose an FDE IC quota.

Deep dives:

1. A partner asks for certification-style attendance counts as proof of capability. What do you add? Keep attendance as an activity metric and require a customer-relevant implementation, review or independently completed exercise as capability evidence. Record the role assessed and the gaps still requiring support.
2. The partner has many opportunities but little delivery capacity. What do you prioritize? Compare customer value, technical readiness, delivery ownership and reusable learning across opportunities. Agree a realistic sequence with partner/GTM owners. Explain why overcommitting the channel can undermine both delivery and enablement.

Avoid a shallow answer: “We trained partners and generated revenue.” Explain the capability changed, evidence of independent delivery and your contribution.

AN-DQ11: How far should you intervene in a partner-led customer deal?

Scope and evidence: Tokyo Partner Architect; strategic deals primarily delivered by partners — A039, A040, A042; Applied AI Architects, Partner; body: Partners Solutions Architect.

Inferred practice question: A partner-led strategic deal has a technical blocker close to a customer deadline. How would you intervene without making the partner dependent on you for all delivery?

What it may test — editorial inference: Whether direct troubleshooting and long-term partner ownership can be held together.

Evidence and decisions to explain: Use a real intervention or a labeled scenario. Identify the blocker, customer impact, partner’s delivery responsibility and your escalation mandate. Choose the smallest direct contribution that unblocks the decision, pair with the partner’s technical owner and leave a testable explanation or reference artifact. Record what remains theirs, the customer-facing commitment and the return to ordinary support. Avoid implying the Architect becomes the permanent implementation owner.

Deep dives:

1. The partner wants you to take over the entire implementation. What do you do? Assess the customer risk and the actual delivery agreement with the responsible owners. Explain the options, resourcing and handoff consequences; seek an explicit revised ownership decision. Do not accept a hidden transfer because the deadline is close.
2. Your fix works but the partner cannot explain it. Is the deal unblocked? Distinguish immediate technical restoration from maintainable delivery. Walk through the cause and verification with the partner, have them reproduce a relevant test and document remaining support. Completion includes a usable handoff, not only your successful run.

Avoid a shallow answer: “I solved it for the partner.” Explain the bounded intervention and what the partner can now own.

AN-DQ12: What field evidence should reach Product or Engineering?

Scope and evidence: Tokyo Architect and London FDE; field feedback duties — A032, A046; Applied AI Architect, Forward Deployed Engineer.

Inferred practice question: You observe a recurring integration problem across engagements. How would you turn it into useful product feedback rather than a list of customer requests?

What it may test — editorial inference: Whether field experience becomes a scoped, reproducible signal that helps another team make a decision.

Evidence and decisions to explain: Describe the affected workflow, observed behavior, environment, frequency and consequence, with permitted reproductions and counterexamples. Separate a product gap from customer configuration or a missing pattern. Present the opportunity, existing workaround, its cost and the uncertainty, then identify the receiving team and feedback owner. Do not promise a roadmap change to the customer before that team decides.

Deep dives:

1. A large customer requests a feature no one else needs. Is it a product priority? Explain the evidence for that customer’s value and the uncertainty about general demand. Compare a scoped field solution with product work and state who owns prioritization. Size alone does not prove a reusable product requirement.
2. Product rejects the request. How do you respond to the customer? Communicate the actual decision and reasons you may share, clarify feasible alternatives and keep the field workaround’s limits explicit. Record which new evidence would justify reopening the question rather than implying the request was approved.

Avoid a shallow answer: “I passed feedback to Product.” State the evidence, decision requested, receiving owner and resulting action or unresolved outcome.

AN-DQ13: How do you allocate a scarce FDE skill across engagements?

Scope and evidence: New York FDE Manager only; technical staffing and team growth — A063, A064, A065, A066; Manager, Forward Deployed Engineering.

Inferred practice question: Two strategic customers need the same experienced FDE. How would you allocate people while protecting technical quality and team development?

What it may test — editorial inference: Whether a Manager makes organizational decisions with quality and growth in view, rather than simply sending the strongest person to every urgent request.

Evidence and decisions to explain: Use actual management experience, naming engagement risk, required skills, continuity, learning needs and available support. Explain the allocation options, decision authority and review cadence. Coordinate with Engagement Managers on logistics and stakeholders while retaining the stated technical-quality/team-growth responsibility. Show what was monitored and what triggered a change. IC collaboration alone does not become people-management experience.

Deep dives:

1. Both customers claim they are highest priority. Who decides? Present the technical risks and staffing trade-offs to the authorized prioritization owners. Separate customer urgency from required expertise and feasible commitments. Record the chosen sequence and escalation so the team is not left to arbitrate incompatible promises.
2. A developing engineer needs the experience but the engagement is high risk. What do you do? Create a bounded role, supervision and review plan that supports growth without transferring unsupported responsibility. State when the senior engineer intervenes and how readiness will be assessed. Growth is planned through work, not by concealing a skill gap.

Avoid a shallow answer: “I put our best engineer on it.” Explain alternatives, supervision, continuity and the effect on the wider team.

AN-DQ14: How do you make technical quality survive a strong individual?

Scope and evidence: New York FDE Manager only; player-coach, hiring/development and quality — A063, A064, A065; Manager, Forward Deployed Engineering.

Inferred practice question: A small FDE team succeeds through one exceptional engineer. How would you build review, coaching and reusable assets so that success is repeatable?

What it may test — editorial inference: Whether management changes the system of work and people capability, not only the manager’s own output.

Evidence and decisions to explain: Use a real example of a dependency on an individual. Identify what knowledge, review judgment or customer relationship was concentrated, then describe the review standard, paired work, coaching and reusable asset that distributed it. Explain when you intervened hands-on and when you let another engineer own the decision. Show observed capability changes and remaining gaps; distinguish a hiring plan from actual hiring results.

Deep dives:

1. Your own intervention always produces the fastest result. Should you keep taking over? Compare immediate delivery with team autonomy and risk. Define which decisions require your review and which can be safely delegated with feedback. Show a plan to reduce repeated dependence rather than measuring success only by your personal throughput.
2. A reusable template hides a weak engineer’s understanding. How do you assess growth? Ask the engineer to adapt it to a changed constraint and explain its assumptions and failures. Use code/architecture review and observed judgment, not template usage alone. Set specific coaching work and reassess with evidence.

Avoid a shallow answer: “I raised the bar and mentored the team.” Identify a concrete practice change and the capability it produced.

AN-DQ15: What must you clarify before preparing for this vacancy?

Scope and evidence: Candidate-to-recruiter preparation; Tokyo, London, Munich and US conditions kept separate — A002, A003, A012, A013, A026, A036, A047, A049, A051, A052, A062; All roles; technical roles where stated, All candidates, Applied AI Engineer, Applied AI Architect, Forward Deployed Engineer, Forward Deployed Engineer, Applied AI Engineer, Enterprise Tech.

Inferred practice question: What would you ask the recruiter to resolve the role’s scope, regional requirements and assessment rules before relying on an interview-preparation plan?

What it may test — editorial inference: Whether you notice documented uncertainty and ask bounded questions. This is a candidate’s preparation prompt, not a question officially asked in interviews.

Evidence and decisions to explain: Identify the exact title, job ID and location. Ask about implementation/advisory ownership, internal level, applicable interview formats and permitted tools for each assessment. For London, show the body’s 4+ years and form’s 8+ years; for Munich, distinguish native wording from C1. Clarify customer travel versus office attendance and avoid transplanting US three-day attendance to Tokyo. Under the AI policy, do not treat general lookup permission as live-AI permission.

Deep dives:

1. The recruiter says AI is allowed. Is that sufficient for every round? Confirm the particular assessment, permitted assistance and any disclosure requirement in its written instructions. A role-wide conversation should not silently override narrower instructions. Rehearse unaided for rounds that retain the default restriction.
2. The discrepancy remains unresolved before an application deadline. What can you state? Describe your actual experience truthfully and identify the conflicting field with the job ID. Ask for clarification through the proper channel; do not invent years, infer a level or claim you meet a condition whose meaning remains uncertain.

Avoid a shallow answer: “All FDE interviews are the same” or “the company uses Claude, so AI is allowed in the interview.” Both erase published scope and policy distinctions.

Offline worksheet: show the agreement that changed the work

For one real engagement, create a decision table with customer goal, technical constraint, commercial or operational constraint, owner, alternatives, chosen scope, baseline, observed result and unresolved risk. Attach only artifacts you may describe. Distinguish work you did, team work and a sponsor's decision; leave unmeasured savings unknown.

Give the table to a reviewer and ask them to challenge one dependency, one success metric and one role boundary. The review is an original offline exercise, not an actual interview round. If you have no relevant engagement, use a clearly marked hypothetical scenario and say what evidence you would collect. It cannot stand in for management, contracting or production experience. Connect the delivery story to technical practice only where the underlying project supports both.