Katkat
Back

From Take-Home Script to Production: Python Trade-offs and Hardening a Data Job

RampSoftware Engineer · Online Assessment
MediumSoftware EngineerOnline AssessmentSoftware Engineering Fundamentals

Last updated

This question evaluates a candidate's engineering judgment about Python's language trade-offs and the steps needed to harden a working script for production use. It tests understanding of dynamic typing, concurrency limits, and correct handling of monetary data, commonly asked to assess practical software-engineering maturity beyond algorithmic correctness.

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?"

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?"

Hints

Hint 1

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.

Hint 2

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 3

The money trap: Floating-point dollars accumulate rounding error and break exact comparisons; prefer integer minor units (cents) or `decimal.Decimal` for monetary arithmetic.

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.