Search⌘ K
AI Features
Home
Courses
Forward Deployed Engineer for AI Systems

Practice Rounds and Self-Review Rubric

Apply the complete FDE design method across three new client scenarios, developing an initial design and revising it in response to follow-up requirements. Compare your design decisions with the reference reasoning, identify unsupported claims, and document corrections without modifying your original submission. Use a self-review rubric to identify recurring weaknesses in your design decisions and prioritise areas for further practice.

We'll cover the following...

This lesson starts with three blank design notes and the reference architectures kept closed. The task is to build a three-round portfolio: an initial design and a separately preserved follow-up revision for each client. The useful result is evidence of changing a commitment when capacity, freshness, or authority changes.

Defending three designs before opening the references

Allow 12 minutes for each initial design and three minutes for its follow-up. These are suggested practice timings, not standard interview limits. Save each initial design before addressing the new constraint. Complete and preserve all six responses before reviewing any worked solutions.

Structure your design decisions using CLIENT: Context, Landscape, Integration points, End-to-end design, Non-happy paths, and Trade-offs. Distinguish confirmed facts, working assumptions, and unresolved questions.

For each initial design, document six areas:

  1. Outcome and scope: Define the initial workflow, measurable target, exclusions, and completion criteria.

  2. Interface inventory: Identify supported or proposed connections, authentication methods, network paths, authoritative data fields, system identities, and responsible owners.

  3. Operation trace: Trace one operation through request acceptance, durable processing, business completion, and user-visible confirmation, identifying the evidence required at each stage.

  4. Numerical feasibility: Show the calculation, input assumptions, limiting constraint, and what the estimate does not establish.

  5. Controls and recovery: Address failure scenarios, uncertain operation outcomes, authorisation checks, deployment safeguards, and ownership of unresolved exceptions.

  6. Recommendation: Propose the smallest viable implementation, identify its operational owner, explain the rejected alternative, and specify the next validation step.

For each follow-up, update the affected design commitment, operation trace, and trade-off analysis. Keep the original designs, follow-up revisions, and subsequent corrections as separate records.

Round 1: How Northstar could connect approval to scheduling

Northstar Components’ planners manually copy approved releases into Scheduling, taking a median of 20 minutes. The pilot aims for five minutes during normal operation without scheduling unapproved work.

  • Authority: Approval owns release_id, revision, approval state, and quantity. Scheduling owns job_id and execution state. An approved item crosswalk connects their different item identifiers.

  • Source contract: Approval provides a read-only, API-key REST feed with stable continuation positions, deletes, seven-day retention, and approved read capacity above the workload.

  • Destination contract: Scheduling supports workload OAuth access, conditional job creation using an expected release revision, and atomic create deduplication plus lookup under a caller-supplied operation identity for seven days. Its normal create-and-status sequence costs two calls per release.

  • Budget: Total destination quota is 60 calls per minute, with 12 reserved elsewhere. Arrivals are 18 releases per minute; an outage leaves 120 queued releases.

  • Environment and ownership: An approved client-VPC host reaches both APIs and token endpoints. Operations resolves approval or item exceptions; integration engineering operates the connector; ...