Interview prompt
As the FDE (Forward Deployed Engineer), your job is to shape a Configurable Platform for Customer-Specific Workflows. Ten customers share one platform, yet each wants its own fields, approval steps, branding and integrations. The thing to avoid is ending up with ten separate forks.
Clarify the customer problem
- Which of the differences keep coming back, and which really happen only once?
- Who writes the configuration: our engineers, the customer's admins, or both?
- Does each configuration have to keep working, unchanged, across core releases?
- Where is custom code allowed: in the core, in a sandbox, or only inside adapters?
- How long should it take to configure a new customer?
Users and workflows
| User | Workflow | Current pain | AI assist opportunity | Human approval needed? |
|---|---|---|---|---|
| Customer administrator | ||||
| FDE / delivery team | ||||
| Core platform engineer | ||||
| Support and release team |
Requirements
Functional
Non-functional
- Latency target
- Availability target
- Cost budget
- Security/privacy constraints
- Audit/compliance requirement
Data and integration map
| Data source | Format | Owner | Freshness | Permission model | Risk |
|---|---|---|---|---|---|
Proposed architecture
Start from a rendered diagram and shape it to fit this case. Cover each part below:
- Workflow runtime
- Configuration registry
- Schema validation
- Adapter SDK
- Sandbox and flags
- Migration and rollback
Evaluation plan
| Metric | Good threshold | Bad threshold | Test dataset | Owner |
|---|---|---|---|---|
| Fork count | 0 | One fork that cannot be removed | Analysis of the repo | Engineering lead |
| Handled by configuration | High and climbing | Dropping | Tags on change requests | Platform eng |
| Time to launch customer | Getting shorter | Getting longer | Records of each release | Delivery lead |
| Tenant incident rate | Stays inside one tenant | Reaches other tenants | The incident system | Support and SRE |
Failure modes
- An approval graph contains a cycle and never ends
- An adapter's contract shifts on the downstream side
- An upgrade breaks a field mapping that older configs rely on
- Nobody tested a particular mix of feature flags
- Custom code gets out of its sandbox
- One validation rule eats all the available resources
Rollout plan
- Spot the pattern that keeps repeating.
- Build it into shared primitives.
- Have the first customer's admin set it up.
- Run a pilot that goes through the real support desk.
- Record a baseline for launch speed and defect count.
- Widen only while the fork count stays at zero.
Weak vs strong answer
Weak: "I'd make a flexible system with forms, approvals and hooks you can configure."
Strong: "I'd run every customer on a single engine that ships on a single release train. Each customer's variation would live in a declarative config that is versioned, immutable and validated before it can be published. I'd deny arbitrary code unless it is explicitly allowed, and scope adapters and secrets to a single tenant. I'd count success as variations shipped with no fork."
Candidate scorecard
Final 2-minute spoken answer
Rehearse this out loud before you look at it. Summarising the whole design in two minutes is its own skill, and it is usually the last thing you are asked for.