# From Take-Home Script to Production: Python Trade-offs and Hardening a Data Job You are in a software-engineering interview at a quantitative trading firm. You have just finished walking the interviewer through a small Python script you wrote for a take-home exercise: it reads a list of stock trade records — each a `(date, symbol, price)` tuple — and computes the maximum profit obtainable from a single buy-then-sell transaction on one stock. With the algorithm settled, the interviewer shifts to engineering judgment and asks two questions: one about Python as a language, and one about what it would take to run this code in production. ### Constraints & Assumptions - The script today is a single function in one file, with no tests, that reads its input from an in-memory list. - The firm processes financial and monetary data, so the correctness of money arithmetic matters. - "Production" here means the code runs as a step in an automated pipeline that ingests possibly malformed third-party trade data on a recurring schedule, at non-trivial volume. - The audience is engineering judgment and communication, not a specific framework; there is no single "right" library you must name. ### Clarifying Questions to Ask - What is the expected data volume and latency target — a nightly batch, or near-real-time? - Where does the input come from, and how trustworthy is it — already validated upstream, or a raw third-party feed? - Who consumes the output — a human-read report, an automated trading decision, or an audit log? (This sets the correctness and precision bar.) - Are monetary values already normalized to integer minor units (cents), or are they floating-point dollars? - Are there runtime constraints — Python version, single process vs. cluster, CPU-bound vs. I/O-bound — that affect the design? ### Part 1 — Python's strengths and weaknesses The interviewer asks: "What are the main advantages and disadvantages of Python as a language, especially for this kind of data-processing and backend work?" ```hint Frame it as trade-offs, not a list Pair each strength with its concrete cost: rapid development and a rich ecosystem versus raw runtime speed; dynamic typing versus safety in a large codebase; the GIL versus CPU-bound parallelism. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 2 — Making the script production-ready The interviewer asks: "Suppose we want to put this script into a production environment. What would you change or add?" ```hint Walk the lifecycle, not just the code Trace input to output to operations: validation and error handling, decomposition plus tests, behavior at scale and in memory, observability (logging and metrics), and a correct representation for money. ``` ```hint The money trap Floating-point dollars accumulate rounding error and break exact comparisons; prefer integer minor units (cents) or `decimal.Decimal` for monetary arithmetic. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - (Part 2) The input becomes a 50 GB CSV feed that will not fit in memory. How does your design change? - (Part 2) The upstream feed occasionally sends a price of `0` or a date like `2024-02-30`. What is your policy for each, and why? - (Part 1) When would you *not* choose Python for this service, and what would you reach for instead? - Show concretely how you would represent and compare monetary values to avoid rounding bugs.