Katkat
Back

Diagnose the Leading Cause of Slow or Failed Charging

FigureaiData Engineer · Technical Screen
MediumData EngineerTechnical ScreenAnalytics & Experimentation

Last updated

This problem tests your ability to define metrics from imperfect telemetry, perform root cause analysis on hardware failure, and design a strategy to identify performance bottlenecks in an autonomous charging system.

Scenario

You are a Data Engineer at a robotics firm. Our robots are reporting an increasing frequency of 'Charging Failure' or 'Slow Charging' alerts. We receive telemetry logs containing session_id, robot_id, start_time, end_time, charge_added_wh (watt-hours), avg_voltage_v, and a status flag (SUCCESS, FAILED, TIMEOUT). Due to sensor noise, some end_time values are missing for failed sessions, and charge_added_wh is occasionally null.

The Task

  1. Define Reliability Metrics: Define a robust 'Charging Reliability' metric. How do you account for the missing telemetry while ensuring the metric is not biased against robots that fail early?
  2. Root Cause Analysis: Given a dataset of sessions, describe your SQL-based or programmatic approach to determine if failures are driven by robot-side hardware (e.g., degraded battery), station-side hardware (e.g., misalignment or charging pad faults), or environmental factors.
  3. Investigation Strategy: You observe that a cluster of robots shows 'Slow Charging' (defined as charge_added_wh / duration < threshold). Design a step-by-step analytical plan to isolate whether this is due to thermal throttling, software power management, or physical connectivity issues.

Constraints

  • Assume 10,000+ sessions per day.
  • Telemetry is streamed; you must suggest how to handle late-arriving data.
  • Your solution should prioritize safety-critical failures over efficiency issues.

Hints

Hint 1

Consider defining 'Exposure' as the total attempted charge duration to normalize your failure rates.

Hint 2

Use a Join or Window function approach to compare identical robots against different charging stations to isolate location-based variables.

Hint 3

For missing `end_time` data, consider using a heartbeat-based heuristic or the last logged sensor timestamp to estimate session duration.

Follow-up questions

  • How would you build an automated alerting system that distinguishes between a single faulty charging station and a fleet-wide firmware regression?
  • If we introduce a new charging protocol, how would you design an A/B test to verify it improves reliability without disrupting ongoing operations?
  • How do you handle 'outlier' robots that have significantly higher failure rates than the rest of the fleet?