You are discussing two quantitative systems: a tax-loss harvesting optimizer and a multi-period asset-location backtest. Explain the mathematical model, the backtest methodology, and the execution architecture deeply enough that an interviewer can distinguish research choices from engineering choices. ### Constraints & Assumptions - Treat tax rates, holding-period rules, wash-sale windows, eligible accounts, and trading limits as explicit inputs rather than universal constants. - Distinguish measurements from estimates. State the actual data volume, solver runtime, historical coverage, and hardware only if they are known. - The backtest may require roughly 30,000 optimizer runs, but the runtime distribution and shared-input size must be measured before choosing a parallelization strategy. - Preserve point-in-time information in the research design so that later knowledge cannot enter an earlier simulated decision. ### Clarifying Questions to Ask - Is the optimizer minimizing current taxes only, or balancing taxes against risk, tracking error, transaction cost, and expected return? - Which tax jurisdictions, account types, lot-selection rules, and wash-sale interactions are in scope? - Is the backtest a historical replay, a Monte Carlo study, or both, and what decision is it intended to support? - Are optimizer paths independent after initialization, or do they share mutable portfolio state between periods? - What accuracy, reproducibility, runtime, and infrastructure-cost requirements determine whether a distributed design is justified? ### Part 1 — Formulate the Tax-Loss Harvesting Optimizer Describe how tax regions, tax lots, short- versus long-term gains, wash-sale restrictions, and trade decisions enter the model. Explain where binary variables and Big-M constraints arise, why the formulation may be a mixed-integer quadratic program, and how branch-and-bound and its continuous relaxation are used. Assess whether a relaxed solution can safely reduce the binary search space. Compare a single-period formulation with one that can wait for a holding period to become long-term. ```hint Separate economics from solver mechanics First define the decisions, accounting identities, and objective terms. Then identify which rules create discrete choices and how the solver treats them. ``` #### What This Part Should Cover - Decision variables, objective terms, and the source of nonlinearity or integrality - Tax-lot timing and wash-sale constraints across relevant accounts and periods - Big-M calibration, relaxation quality, and optimality versus heuristic trade-offs - The additional state and uncertainty introduced by a multi-period horizon ### Part 2 — Design the Backtest Explain when to use historical paths, Monte Carlo paths, or both. Choose a rebalancing cadence and evaluation metrics, justify the historical window and data sources, and explain how you prevent stale, missing, revised, or future data from biasing the result. ```hint Match evidence to the decision The right path generator, cadence, and metric depend on whether the study evaluates after-tax wealth, risk, implementation cost, robustness, or another decision criterion. ``` #### What This Part Should Cover - Path construction and the assumptions each path type preserves or breaks - Rebalancing logic, transaction effects, and after-tax performance metrics - Point-in-time data, corporate actions, missing observations, and reproducibility - Sensitivity analysis across market regimes and modeling assumptions ### Part 3 — Execute About 30,000 Optimizer Runs Design the execution plan for tens of thousands of path-level optimizations. Decide whether to use one machine or several, whether a machine per path would help, how to share common inputs, and how serialization, scheduling, solver startup, and result aggregation affect throughput. Explain how you would measure per-path runtime, profile the bottleneck, and choose the next enhancement. ```hint Optimize the measured critical path Break total wall time into input preparation, transfer, queueing, solver work, and result reduction before selecting a concurrency model. ``` #### What This Part Should Cover - Task granularity, bounded concurrency, load balancing, and failure isolation - Shared immutable inputs, transfer volume, process startup, and memory pressure - Runtime distributions, profiling evidence, deterministic seeds, and resumability - A reasoned comparison of vertical optimization and horizontal distribution ### Part 4 — Explain Your Role Fit State whether your strongest contribution is closer to software engineering, quantitative research, or the boundary between them. Support the answer with evidence about the work you personally own and explain which part of the optimization-to-production lifecycle you most want to handle. ```hint Use an evidence-backed position Choose a point on the spectrum, then connect it to concrete decisions you can explain in depth rather than presenting equal interest in everything. ``` #### What This Part Should Cover - A clear position rather than an unqualified claim of being equally strong everywhere - Evidence of ownership in engineering, optimization research, or both - Awareness of the different standards for research validity and production reliability - A credible account of where the candidate can contribute immediately and grow next ### What a Strong Answer Covers Across all parts, connect the financial objective, mathematical formulation, data assumptions, execution plan, and personal ownership. Mark which claims are measured, which are modeled, and which remain hypotheses to test. ### Follow-up Questions - How would you detect that a tighter Big-M formulation materially improved solver performance without changing the feasible set? - What evidence would persuade you that Monte Carlo paths add value beyond historical replay for this decision? - If a few paths dominate wall time, how would you separate difficult optimization instances from infrastructure skew? - Which approximation would you consider first if the exact multi-period optimizer could not meet the runtime target?