Business Context

You’re interviewing for an ML engineering role at VoltGrid, a logistics-and-energy operator that runs 18,000 industrial pumps and compressors across 420 facilities (ports, warehouses, and fuel depots). Unplanned failures can halt operations and trigger environmental compliance incidents. A single pump failure costs $30K–$120K in downtime and emergency repair, but unnecessary preventive maintenance also has a real cost: each truck roll is ~$900 plus lost utilization.

VoltGrid has instrumented assets with high-frequency sensors and maintains a CMMS (maintenance ticketing) system. The VP of Reliability wants a model that can predict whether an asset will fail in the next 7 days, so planners can schedule maintenance during low-demand windows.

The core challenge: failures are extremely rare and labels are noisy (some failures are never logged; some tickets are mislabeled as “failure”). You must propose a robust approach that works in production.

Dataset

You are given a feature table built from raw telemetry and maintenance logs. Each row is an asset-day snapshot.

Additional details:

• Size: ~6.5M asset-days spanning 24 months
• Target: fail_7d = 1 if a confirmed failure occurs within the next 7 days, else 0
• Class balance: ~0.06% positive (≈ 3,900 positives total)
• Missing data:
  • 8–12% missing in some sensors due to dropouts
  • Entire days missing for some assets (connectivity outages)
  • Maintenance fields missing for newly onboarded facilities

Success Criteria

Your model will be used to generate a daily risk list.

1. Catch failures: Achieve ≥ 70% recall on failures (7-day horizon).
2. Control false alarms: At the operating threshold, keep precision ≥ 10% (roughly ≤ 9 false alarms per true positive), because the maintenance team can only action ~120 work orders/day across the fleet.
3. Rank quality: The top 1% highest-risk asset-days should contain ≥ 25% of all failures (high lift for triage).
4. Reliability: Risk scores should be reasonably calibrated so planners can interpret “0.3” vs “0.05”.

Constraints

• Leakage risk: Maintenance tickets and some sensor flags may be recorded after a failure begins. You must prevent label leakage.
• Split strategy: Assets appear across time; random splits can overestimate performance.
• Latency: Daily batch scoring must finish in < 30 minutes on a modest Spark/CPU cluster; per-row inference should be < 5 ms in Python for integration tests.
• Interpretability: Reliability engineers require top drivers per alert (e.g., “vibration slope up 3× baseline”).
• Drift: Seasonality and facility operating regimes change; the model should be retrained at least monthly.

Deliverables (what you must produce in the interview)

1. A modeling approach for extreme class imbalance (including loss weighting / sampling and why).
2. A leakage-safe labeling and feature windowing plan (what data is allowed at prediction time).
3. A train/validation/test strategy that reflects production (time split, asset split, or both).
4. A thresholding and evaluation plan using PR-AUC, recall/precision at an operating point, lift, and calibration.
5. A production plan: monitoring, retraining cadence, and how you’d handle noisy/missing labels.