## Analyze Mission Outcomes and Allocate Response Units You receive historical mission-level data for a set of response units. Assume one row represents one completed mission and includes: - `mission_id`: a unique mission identifier - `unit_id`: the response unit assigned to the mission - `location`: the mission location - `rest_time_bucket`: the unit's rest-time group before the mission - `mission_length`: the mission duration - `won`: 1 for a successful mission and 0 otherwise - `damaged`: 1 if the unit was damaged and 0 otherwise - `event_time`: the mission completion timestamp Explain the calculations and decision rules you would use for each part. You may use SQL, Python/pandas, formulas, or precise pseudocode, but no executable console solution is required. ### Constraints & Assumptions - Treat each mission as one observation unless you explicitly justify another unit of analysis. - Exclude or separately report records with missing outcomes rather than silently treating them as losses. - A historical rate is an estimate, not a guarantee of future performance. - Where the prompt leaves a tie or business preference unspecified, state a deterministic rule and show how you would test alternatives. ### Clarifying Questions to Ask - Are all missions equally important, or should any be weighted by difficulty, length, or location? - Can one unit cover more than one future location, or is this a one-to-one assignment? - Is damage a hard constraint or a trade-off against expected wins? - How should ties be resolved, and is there a minimum history required for a unit to be eligible? - Does the deployment decision concern one mission per location or a longer stream of missions? ### Part 1: Calculate Overall Win Rate Define and calculate the overall historical win rate. Explain how you would validate the numerator and denominator. #### What This Part Should Cover - Uses successful completed missions divided by eligible completed missions. - Handles missing, duplicate, or invalid outcome rows explicitly. - Reports the numerator and denominator with the rate. ### Part 2: Compare Performance by Rest-Time Group Calculate average win rate by `rest_time_bucket`. Explain the difference between a pooled mission-level rate and the unweighted average of unit-level rates, and state which you would use for an operational decision. #### What This Part Should Cover - Groups at the requested grain and defines both possible estimands. - Recognizes that unequal mission counts make pooled and unweighted averages different. - Reports sample size and uncertainty rather than ranking tiny groups at face value. ### Part 3: Select Three Units When Future Location Is Unknown Choose three units when the future mission location is not known. Describe a ranking rule based on historical performance and how you would prevent units with very little history from dominating the result. #### What This Part Should Cover - Defines an overall expected-performance score aligned with the unknown-location objective. - Accounts for sample size, uncertainty, and location mix. - States a deterministic selection and tie-breaking rule. ### Part 4: Assign Units to Three Known Locations Future missions will occur at locations A, B, and C. Use location-specific historical win rates to choose at most three units and assign one unit to each location so that total expected wins are maximized. Explain how you would handle missing unit-location history. #### What This Part Should Cover - Builds a unit-by-location performance table using consistent denominators. - Optimizes the assignment jointly rather than choosing each location independently when a unit can be used only once. - Treats sparse or missing cells explicitly and validates the stability of the rates. ### Part 5: Find a Mode and Return a Representative Row For a categorical column, find its mode and return the earliest row whose value equals that mode. Describe how you would handle tied modes. #### What This Part Should Cover - Separates finding the modal value from retrieving a row that contains it. - Uses `event_time` and then a stable identifier for deterministic row selection. - Defines a tie policy instead of relying on incidental row order. ### Part 6: Balance Coverage and Damage Risk Three already-selected units cover the middle of the observed mission-length range. Choose one additional unit to improve coverage of short and long missions while accounting for damage rate. Explain how you would compare a candidate with broader coverage against one with lower historical damage risk. #### What This Part Should Cover - Defines a coverage measure for the underserved tails of the mission-length distribution. - Calculates damage risk with a clear denominator and adequate sample-size checks. - Makes the trade-off explicit through constraints, a score, or a Pareto comparison. ### Part 7: Estimate a New Team's Win Rate A new team completed 572 eligible missions and won 422. Calculate its observed win rate and describe the uncertainty you would report. #### What This Part Should Cover - Computes `422 / 572` and presents the result at a sensible precision. - Reports uncertainty for a binomial proportion. - Avoids claiming that the observed rate alone proves future superiority. ### What a Strong Answer Covers - Maintains a consistent row grain and denominator throughout the analysis. - Distinguishes descriptive calculations from decisions that require generalization to future missions. - Handles missingness, ties, repeated observations, sparse groups, and small samples explicitly. - Connects every ranking or assignment rule to the stated operational objective. - Uses uncertainty, shrinkage, sensitivity checks, and transparent assumptions where raw rates may be unstable. - Communicates the selected units and the evidence behind them in language a decision-maker can audit. ### Follow-up Questions 1. How would your selections change if mission difficulty differs substantially by location? 2. What would you do if outcomes for the same unit are strongly correlated over time? 3. How would you validate that historical win rate remains predictive after deployment conditions change? 4. How would you set a minimum history threshold without excluding promising new units?