Practice

A colleague argues an FDE is 'just a consultant who codes'. Using the four adjacent roles (product engineer, solutions architect, consultant, support engineer), write where the FDE differs from each and the single accountability that distinguishes it.

Deliverable: A 200-word memo with a short table and one concrete accountability test.

• All four adjacent roles addressed with a real difference, not phrasing differences
• The accountability test is a specific question with a specific answer
• Under 250 words, no filler

Pick any project you have worked on. Map it to the six lifecycle stages and mark each stage: artifact existed, artifact existed but late, or artifact missing.

Deliverable: A six-row table plus a 100-word analysis of which missing artifact cost the most.

• All six stages with artifact status
• The cost analysis names a concrete consequence
• At least one improvement action stated

Interview a colleague (or role-play with a friend) about a recurring task in their work using the past-incident question pattern. Record answers, then write the problem statement with a number.

Deliverable: Interview notes (four questions with answers) plus a one-sentence problem statement with a metric.

• Questions target past events, not hypotheticals
• Problem statement contains a count, duration, or frequency
• At least one correction or surprise is noted

You are told: 'Automate our supplier onboarding.' Write eight unknowns as questions, rank the top three by cost of being wrong, and design a test under two hours for the highest one.

Deliverable: A ranked unknown list plus one test design with method and time box.

• Eight concrete questions, not vague concerns
• Ranking justified per item in one line
• The top test is executable within the time box

Map a real or realistic invoice-processing flow: trigger, steps, three systems, two handoffs, two failure points. Build the system inventory with owners and access paths.

Deliverable: A structured map (text or diagram) plus an inventory table.

• Handoffs marked with the information gap at each
• Inventory includes owner, access path, and data sensitivity
• At least one data-quality risk flagged

Write the one-page brief for a fictional engagement: automating expense-report approval at a 400-person company. Discovery found: 90 reports per week, 40 minutes average manual review, two policy violation cases per month reaching payment.

Deliverable: The brief with all six sections, each under 60 words.

• Problem sentence carries the numbers from discovery
• Out-of-scope names at least three items
• Success measures have baseline and target numbers
• Risks have named owners

Rewrite these wishes as testable acceptance criteria: 'fast search', 'secure enough', 'easy onboarding', 'reliable sync', 'good error messages'.

Deliverable: Five given-when-then criteria with measurable thresholds.

• Every criterion has a numeric threshold
• Given-when-then structure used throughout
• No vague adjectives survive

Mid-engagement, the sponsor asks: 'Since you are building invoice extraction, add full AP workflow automation too.' Write the trade-off paragraph and the change log entry that protects the agreed core.

Deliverable: A one-paragraph reply and a change log entry with impact estimate.

• The reply states the cost in days and the date impact
• A nearest-fit alternative is offered
• The change log entry has date, requester, reason, impact

Design a small API for a document-status service: four endpoints, field validation rules, three error codes with meanings, pagination on the list endpoint, and one example error response.

Deliverable: An endpoint table plus validation rules and one JSON error body.

• Endpoints are resource-oriented and minimal
• Validation covers type, length, and range for key fields
• Error codes are machine-readable and documented
• Pagination scheme includes limits and cursors or offsets

Design the canonical invoice model for a two-source integration (email PDFs and an ERP export). List fields with types, external identifier fields per source, and your timestamp strategy.

Deliverable: A field table plus a short timestamp strategy statement.

• External IDs and updated-at stored per source
• UTC storage with a stated conversion point
• At least one field handles source-format difference

Classify these five failures for a sync job as retryable or permanent, with reasons: connection reset mid-upload; 422 validation rejection; timeout waiting for response after the write may have landed; missing record in source; 503 from the target API.

Deliverable: A classification table with reasons, plus the idempotency key design that makes the ambiguous case safe.

• The 'may have landed' case handled via idempotency key, not guesswork
• Each classification has a one-line reason
• Retry policy includes backoff and cap

Design an ETL job loading supplier invoices from two sources (email attachments, ERP export). Specify staging, five validation rules, sync strategy with reconciliation, and quarantine record fields.

Deliverable: A design document with four sections.

• Raw payloads staged untouched
• Validation precedes transformation
• Reconciliation mechanism named with frequency
• Quarantine fields allow later reprocessing

Write the weekly data quality report for a fictional customer-master sync from this data: 12,400 rows in, 61 quarantined (38 missing email, 14 duplicate tax ID, 9 unparseable phone), freshness 2.1 hours, duplicates 0.4 percent.

Deliverable: The one-page report plus one recommended upstream fix.

• Numbers match the input data exactly
• Top failure reason identified with a next action
• At least one threshold with an owner stated

Design a webhook receiver for a payment provider: signature verification, fast ack, queue and worker split, dedup on event ID, and a replay procedure for a bad 6-hour window.

Deliverable: A design document covering the delivery lifecycle of one event.

• Verification happens before ack
• Processing is asynchronous from a durable queue
• Dedup uses storage, not memory
• Replay is safe because processing is idempotent

For three problems, choose rules, classic ML, or LLM, and write a sponsor-ready justification each: (a) approve invoice totals under 10k against policy, (b) route support emails into 12 queues, (c) extract line items from scanned PDFs.

Deliverable: A decision table with justifications.

• Each choice defensible on cost, accuracy, and auditability
• At least one hybrid answer with the split stated
• Justifications avoid hype and name failure paths

Define the baseline for a fictional email-triage feature: the dumb approach, the metric that matters to the business, an estimated baseline score, and the threshold an LLM approach must beat to replace it.

Deliverable: A half-page definition with the fallback rule.

• The metric ties to a business cost
• Threshold numeric with a decision rule
• Fallback behavior explicit

An LLM feature drafts customer-reply emails for support agents. Write the guardrail plan: three expected failure modes with a structural defense each, and the two-sentence limits paragraph for the customer brief.

Deliverable: A guardrail table plus the brief paragraph.

• Defenses are structural (schema, threshold, human gate), not instruction-pleading
• The brief paragraph states limits and error handling honestly
• At least one guardrail is measurable

Define the chunking scheme for an HR-policy knowledge base: boundary rule, size and overlap, six metadata fields per chunk, and the citation format shown to users.

Deliverable: A one-page scheme document.

• Boundaries follow document structure
• Metadata includes access or owner field
• Citations identify document and section

For a fictional support KB assistant, users report: (1) answers miss facts that exist in the wiki, (2) answers cite the outdated 2024 policy, (3) one team sees another team's runbook titles. Diagnose each as a recall, ranking, or access-filter failure with the fix.

Deliverable: A three-row diagnosis table with fixes.

• Each diagnosis correctly separated
• Fixes address the layer that failed
• The access issue treated as severity one

Write tool contracts for a refunds agent: lookup order, check policy, issue refund. Typed inputs and outputs, two structured error codes each, usage guidance, and a confirmation argument on the destructive tool.

Deliverable: Three contract definitions.

• Schemas complete enough to implement
• Errors machine-readable with retry hints
• Destructive tool separated with confirmation

Specify loop guardrails for a research-and-draft agent: step, time, and cost budgets with numbers and reasons; the cycle-detection rule; and the give-up message template.

Deliverable: A half-page specification.

• Budgets numeric and justified
• Cycle detection on normalized call signatures
• Give-up template includes attempts, reason, next step

Write the deploy plan for a pricing service at a customer with a weekly change board: strategy choice with reason, five go/no-go criteria, rollback steps with duration, and the migration-compatibility note.

Deliverable: A one-page plan.

• Strategy fits customer risk profile
• Criteria numeric and checkable
• Rollback is a procedure someone can run under stress
• Schema changes addressed with expand-migrate-contract or equivalent

Write the runbook for a nightly reconciliation service: top three symptoms with checks and actions, escalation contacts, and two symptom-based alerts (not CPU alerts).

Deliverable: The runbook plus the alert definitions.

• Symptoms first, causes second
• Every action runnable by someone who did not build the system
• Alerts fire on user-visible symptoms

Threat-model a fictional multi-tenant document assistant: four trust boundaries, the top threat at each, the mitigation, and the test that proves the mitigation works.

Deliverable: A four-row threat table plus the test list.

• Boundaries include tenant and model boundaries
• Mitigations structural, not procedural
• Every mitigation has a test