Build a Running Late-Order Refund Workflow as Separate Python Services

In this round you build a small working system in Python with the help of an AI coding assistant, and then discuss how you would extend it. The workflow to implement is given as a directed acyclic graph: ```text Start --> Check: is the order late? |-- Yes --> Issue refund --> End `-- No -------------------> End ``` The requirements that come with the graph: - Build a working end-to-end system. At minimum, a late order must trigger a refund. - Keep it simple: a working demo matters more than polish. - The components must interact as separate systems through real API calls, not as function calls inside one script. - The system must keep running continuously rather than execute once, so that it can be observed live. - Use Python. The evaluation focuses on a working end-to-end system, reasonable scope decisions under time pressure, and effective use of AI to speed up implementation. Perfect abstractions, elaborate class hierarchies and low-level polish matter less. ### Clarifying Questions - How is "late" defined: delivered after the promised time, still undelivered after it, or late by more than a grace period? - How much is refunded: the full order amount, a fixed credit, or an amount that depends on how late the order was? - Where do orders come from in the demo: should the system simulate a stream of orders, or receive them through an API? - Can the same order be evaluated more than once, and what must prevent it from being refunded twice? - How will the interviewer observe the running system: logs, HTTP endpoints, or a simple dashboard? ### Part 1 — Build the working system Implement the components and wire them together so that, while the system runs, late orders are refunded and on-time orders are not. Explain the component boundaries and the APIs between them. ```hint Scope to the one path List the smallest set of separate components that makes the late-order-to-refund path real, and fake everything else behind those components' APIs. ``` ```hint What keeps it running Decide what drives the workflow again and again: a worker that polls for orders to evaluate, or an endpoint that receives order events. ``` #### What This Part Should Cover - Component boundaries and the HTTP APIs between them - How the workflow graph is represented and executed - Continuous operation, and a way to watch it happen live - Refunds that cannot be issued twice for one order, even after a restart or a retry ### Part 2 — Extend the design The discussion then goes beyond the demo: which features would you add next, how would you design the APIs so they can be extended later without breaking callers, and how would you add payment functionality to the system? ```hint Graph as data Consider what adding a new step, such as a payment step, would touch if the graph's nodes and edges were configuration rather than code. ``` #### What This Part Should Cover - The features that would make the workflow usable in production - How the APIs evolve without breaking existing clients - A payment component: how money moves, how a refund relates to the original payment, and how failures are handled ### Part 3 — Test the system Explain how you would test what you built, including the code the AI assistant wrote. ```hint Test the seams Separate what can be tested without starting any server from what needs the components running together. ``` #### What This Part Should Cover - Unit tests for the lateness decision and the workflow engine - Tests at the API boundaries, including repeated refund requests - An end-to-end test of the running system that shows a late order being refunded and an on-time order not being refunded ### What a Strong Answer Covers - A demo that really runs continuously, with separate components talking over HTTP - Explicit, defensible scope cuts made under time pressure - Effective use of the AI assistant, with the candidate owning the interfaces and verifying the generated code by running it - Exact money handling, and refunds that are safe to retry ### Follow-up Questions - The refund service is down for several minutes. What happens to late orders during the outage, and how does the system catch up afterwards? - Two workflow workers run at the same time for availability. How do you stop them from processing the same order twice? - Refunds above a certain amount must be approved by a person first. How do the graph and the engine change? - How would you replace polling with events, and what new failure modes does that introduce?