Figure·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

Jun 2026

Summary

System design round at Figure for a software engineering role. The whole thing was one big open-ended question about building a data ingestion pipeline for ML training, and it went pretty deep into areas I wasn't fully prepared for.

Questions Asked (1)

Design a backend system that collects, filters, and stores training data uploaded by many clients, including large media files like images and videos, action sequences, labels, and metadata. Walk through the full system end to end, covering APIs, ingestion flow, storage, async processing, scalability, reliability, observability, and how you'd detect and reduce bias in the collected data.

System DesignTechnical Trade-offsData Modeling

Author's notes

This question is basically five questions stitched together and they expect you to connect all of them.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements (data types, scale, latency, compliance) and then walk through the system end-to-end: client APIs, ingestion pipeline, storage tiers, async processing, and observability. Emphasize trade-offs, especially around large media handling, scalability, and bias detection, and tie decisions back to Figure's robotics use case.

Pro tip: Treat bias detection as a first-class pipeline stage, not an afterthought—propose automated checks on demographic and scenario coverage, and show how you'd surface gaps to data collectors. This demonstrates maturity beyond typical system design answers.

1. Clarify Requirements and Constraints

Ask about data volume, client types, latency needs, compliance (e.g., GDPR, CCPA), and Figure's specific robotics data (action sequences, sensor fusion). Define success metrics like ingestion throughput, processing latency, and bias thresholds.

2. Design APIs and Ingestion Flow

Propose REST/gRPC APIs for metadata and pre-signed URLs for direct-to-S3 uploads of large media. Include client-side chunking, resumable uploads, and validation (format, size, checksum) at the edge.

3. Storage and Data Modeling

Use object storage (S3) for media, a relational DB (PostgreSQL) for metadata and labels, and a time-series or columnar store for action sequences. Design schemas with versioning and indexing for efficient queries.

4. Async Processing and Scalability

Decouple ingestion from processing via a message queue (Kafka/SQS). Use serverless functions or containerized workers for transcoding, feature extraction, and bias checks. Auto-scale based on queue depth.

5. Reliability, Observability, and Bias Mitigation

Implement retries, dead-letter queues, and idempotency. Monitor with metrics, logs, and traces (Prometheus, Grafana, Jaeger). For bias, track data distribution across demographics/scenarios and alert on skew.

Key Points to Mention

Pre-signed URLs for direct client-to-storage uploads to avoid bottlenecking the API layer.
Use of message queues and worker pools for asynchronous, scalable processing of media and action sequences.
Data modeling: separating metadata (SQL) from media (object store) and action sequences (time-series/columnar).
Bias detection via automated statistical checks on data coverage (e.g., demographic, environmental, and action diversity) and feedback loops to clients.
Observability: end-to-end tracing, ingestion/processing metrics, and alerting on failures or bias drift.
Reliability patterns: idempotent writes, retries with exponential backoff, and dead-letter queues for poison messages.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.