Openai·Software Engineer·Technical Phone Screen·Senior

Senior

Jun 2026

Summary

Got a system design coding hybrid at OpenAI for a software engineer role. The problem was about managing a GPU credit pool across tenants, which sounds straightforward until you actually have to think through all the edge cases around concurrency and crash recovery.

Questions Asked (1)

You're managing a GPU pool with per-tenant credit balances. Given a stream of signed-integer events (positive = add credit, negative = deduct), implement three functions: init(events) to set up state from an ordered list of events, getBalance(tenantId) to return a tenant's current balance, and applyEvent(event) to process a new event and update state. You also need to define the event schema, decide whether to reject events that would push balances negative, handle idempotency for repeated event IDs, and discuss data structures, concurrency, and crash recovery. Target O(1) average per operation after O(n) init.

System DesignAlgorithms & Data StructuresTechnical Trade-offs

Author's notes

I went straight to a hashmap keyed by tenantId for O(1) reads and updates, which they seemed fine with.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and defining the event schema, then propose a hash map-based design with per-tenant balance and a global set of processed event IDs for idempotency. Walk through the three functions, discussing edge cases like negative balances and concurrency, and outline crash recovery using a write-ahead log. Emphasize O(1) average time and trade-offs.

Pro tip: Explicitly state your assumptions about event ordering and idempotency scope (global vs per-tenant) early, and mention that you'd use a lock per tenant or a concurrent map to balance performance and correctness.

1. Clarify requirements and define schema

Ask about event ordering, idempotency scope, and negative balance policy. Define event schema as {eventId: string, tenantId: string, amount: int}.

2. Design data structures

Use a hash map for tenant balances (tenantId -> balance) and a hash set for processed event IDs. For concurrency, consider per-tenant locks or a concurrent hash map.

3. Implement core functions

init(events): iterate events, apply each if not duplicate and balance stays non-negative. getBalance(tenantId): return balance or 0. applyEvent(event): check idempotency, validate balance, update state.

4. Address edge cases and concurrency

Decide on rejecting negative balances (e.g., throw error or ignore). For concurrency, use locks to ensure atomic check-and-update. Discuss idempotency with event IDs.

5. Discuss crash recovery and trade-offs

Propose a write-ahead log (WAL) or periodic snapshots for recovery. Mention trade-offs: memory vs durability, lock granularity, and idempotency storage growth.

Key Points to Mention

Event schema: include eventId, tenantId, amount, and possibly timestamp for ordering.
Idempotency: use a set of processed event IDs; consider TTL or per-tenant sets to manage memory.
Negative balance handling: reject event (throw exception) or ignore, and ensure atomicity.
Concurrency: use per-tenant locks or concurrent map with atomic operations to avoid race conditions.
Crash recovery: write-ahead log (WAL) or snapshots to rebuild state; ensure idempotency during replay.
Time complexity: O(1) average for getBalance and applyEvent, O(n) for init; discuss hash map collisions and resizing.

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