← Axon Interview Insights

Axon·Software Engineer·Onsite - System Design / Architecture·Intermediate

Intermediate
Apr 2026

Summary

System design round at Axon for a software engineer role. The problem was scoped around a body camera checkout system, which sounds simple but the O(1) constraint on all three operations is where things get interesting.

Questions Asked (1)

Q1

Design a body camera pool management system for police officers. It needs check_out(officer_id) to randomly assign an available camera, check_in(body_cam_id) to return one, and a way to query current assignments. All operations must run in O(1) time. Walk through your data structures and how you'd handle edge cases like double check-ins or an empty pool.

System DesignAlgorithms & Data StructuresTechnical Trade-offs
Author's notes

The random selection in O(1) is the crux of it.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then propose a design using two hash maps (one for officer-to-camera and one for camera-to-officer) plus a list of available cameras for O(1) random assignment. Walk through each operation, explicitly handling edge cases like double check-ins, empty pool, and invalid IDs.

Pro tip: Mention that you'd use a thread-safe implementation (e.g., locks or concurrent data structures) since multiple officers may check out cameras simultaneously, and discuss how to handle failures gracefully (e.g., returning an error if no cameras are available).

1. Clarify requirements and constraints

Confirm that all operations must be O(1), that cameras are indistinguishable, and that we need to handle edge cases like double check-ins and empty pool. Ask about concurrency and persistence if relevant.

2. Design core data structures

Use a hash map for officer-to-camera assignments, another for camera-to-officer (to detect double check-ins), and a dynamic array (or hash set) for available cameras to enable O(1) random selection via swap-with-last removal.

3. Implement operations

For check_out: if available list is empty, return error; else pick a random index, swap with last, pop, and update both maps. For check_in: validate camera is checked out, remove from both maps, and add back to available list. For query: return the officer-to-camera map or list all assignments.

4. Handle edge cases

Double check-in: check if camera is in camera-to-officer map; if not, return error. Empty pool: return error or null. Invalid IDs: validate existence. Also consider concurrency with locks or atomic operations.

5. Discuss trade-offs and extensions

Mention that this design assumes cameras are identical; if not, we could use a priority queue or separate pools. Discuss persistence, scalability, and thread safety as potential extensions.

Key Points to Mention

  • Use of two hash maps for O(1) lookups and bidirectional mapping
  • Available cameras stored in a dynamic array with swap-and-pop for O(1) random removal
  • Edge case handling: double check-in detection via camera-to-officer map, empty pool returns error
  • Concurrency considerations: locks or concurrent data structures for thread safety
  • Time complexity analysis: all operations O(1) average case
  • Potential extensions: persistence, camera types, audit logging

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