Build a Create/Execute Workflow Service With an AI Assistant: Plan, Implement, Verify

In a 45-minute coding session you are expected to use an AI coding assistant. With it, build a small service that creates and executes workflows. The service exposes two APIs: - **Create workflow**: accept a workflow definition, validate it, store it, and return an identifier. - **Execute workflow**: run a stored workflow on a given input and return the result of the run. The interviewer cares more about how you work with the assistant than about how much code you produce. They want to see you plan first, then implement, then verify correctness, rather than asking the assistant to generate the whole service in one shot. The prompt does not define what a workflow is. If the interviewer leaves it to you, a reasonable assumption is: a workflow is a named set of steps; each step has an ID, calls one action from a fixed server-side registry with its own parameters, and may depend on other steps, whose outputs it receives; executing a workflow runs every step after the steps it depends on and returns each step's status and output. ### Clarifying Questions - Is a workflow a linear sequence of steps or a graph with dependencies, and may independent steps run in parallel? - What can a step do: call registered functions only, call external HTTP endpoints, or run code supplied by the user? - Should execute block and return the result, or start a run and return a run ID that the client polls? - When a step fails, should the run stop, retry the step, or continue with the steps that do not depend on it? - Must workflows and runs survive a restart, or is in-memory storage enough for this session? - Can a stored workflow be changed, and if so, which version does a run use? ### Part 1 — Plan with the assistant Before writing code, use the assistant to turn the prompt into a short written plan: the requirements and the assumptions you chose, the workflow data model, the request and response shapes and error cases of both APIs, the module layout, and the list of tests you will write. ```hint Make the plan checkable Write the plan so that each requirement maps to a test you can name. Ask the assistant to attack the plan, for example by listing invalid workflow definitions, before you accept it. ``` #### What This Part Should Cover - Assumptions stated and confirmed with the interviewer, with scope cut to fit 45 minutes - A concrete workflow schema and API contract, including validation errors - A test list written before any code - Deliberate prompting of the assistant and critical review of what it proposes ### Part 2 — Implement the two APIs Implement create workflow and execute workflow. Creating a workflow must reject any definition that can never run correctly. Executing a workflow must run each step only after the steps it depends on, and must report what happened to every step. ```hint Validate once, run many times Some properties of a definition can be checked when it is created, so that execution never has to discover them. Decide which ones, and what the executor can then rely on. ``` ```hint Keep the assistant on a short leash Generate and review one small piece at a time (model, validation, executor, HTTP layer), and read every change before accepting it. ``` #### What This Part Should Cover - Validation at creation time: unknown actions, duplicate step IDs, references to missing steps, and dependency cycles - An executor that respects dependencies and passes outputs to the steps that need them - Defined behavior when a step raises an error, without crashing the service - A thin HTTP layer with correct status codes, kept separate from the core logic ### Part 3 — Verify correctness Show that the service works: run tests that cover the normal paths and the failure paths from your plan, and explain how you checked the code the assistant wrote. ```hint Tests from the spec, not from the code If the assistant writes tests by reading its own implementation, the tests confirm what the code does, not what it should do. Derive the expected results from the plan. ``` #### What This Part Should Cover - Tests for a dependency graph, steps defined out of order, invalid definitions, and failing steps - Tests actually run, with failures diagnosed rather than patched over - A review of generated code for invented library calls, swallowed errors and untested branches ### What a Strong Answer Covers - A visible plan, implement, verify loop instead of one-shot generation - Judgment over the assistant's output: catching its mistakes and explaining which suggestions were accepted or rejected - Correct core logic: validation at creation, dependency-ordered execution, explicit failure semantics - Time management that leaves a working, tested slice at the end of 45 minutes - Clear statements of what is out of scope and how it would be added ### Follow-up Questions - How would you make execute asynchronous, so that a long workflow returns a run ID immediately and the client polls for its status? - How would you run independent steps in parallel, and what changes in the failure semantics? - A client retries execute after a timeout. How do you avoid running steps with side effects twice? - How would you persist workflows and runs so that a run resumes after the service restarts in the middle of it?