Coinbase OA Interview Question: Build a Simple Endpoint That Can Filter by Time Range, User, and Currency

Build a simple endpoint that can filter by a time range, user, and currency.

Some example use cases here would be to display some sort of transaction history. For simplicity, let’s just build this using a typed interface in your language of choice, but we can pretend there is a service boundary.

Let’s also use this sample dataset so we can build an endpoint we can use, but you can imagine in a real situation we would have a database. We do not want to build a database here, so it is okay to loop through the items, but do consider what you are doing that might be different in an actual database-backed implementation.

[{"time": 1, "id": 11, "user_id": 1, "currency": 1, "amount": 10},
  {"time": 2, "id": 12, "user_id": 1, "currency": 3, "amount": 11},
  {"time": 3, "id": 13, "user_id": 2, "currency": 1, "amount": -10},
  {"time": 4, "id": 14, "user_id": 1, "currency": 2, "amount": 12},
  {"time": 5, "id": 5, "user_id": 1, "currency": 2, "amount": -10},
  {"time": 6, "id": 6, "user_id": 1, "currency": 1, "amount": 13},
  {"time": 7, "id": 7, "user_id": 1, "currency": 2, "amount": -5},
  {"time": 8, "id": 8, "user_id": 1, "currency": 2, "amount": 10},
  {"time": 9, "id": 9, "user_id": 1, "currency": 1, "amount": 10},
  {"time": 10, "id": 10, "user_id": 1, "currency": 1, "amount": 10},
  {"time": 10, "id": 21, "user_id": 1, "currency": 1, "amount": 16},
  {"time": 11, "id": 22, "user_id": 1, "currency": 2, "amount": -3},
  {"time": 11, "id": 23, "user_id": 1, "currency": 1, "amount": 5},
  {"time": 12, "id": 24, "user_id": 1, "currency": 2, "amount": 6},
  {"time": 13, "id": 25, "user_id": 1, "currency": 1, "amount": 10}
]

This problem asks you to build a lightweight endpoint that filters transaction records by time range, user, and currency. The main task is to define a typed request/response model and apply the requested filters over the provided in-memory dataset. Since no database is required, a simple loop is acceptable, but the solution should still reflect how the logic would differ in a database-backed implementation, especially around filter composition and boundary handling.