← revolut Interview Insights

revolut·Software Engineer·Technical Phone Screen·Intermediate

Intermediate
Jul 2026

Summary

Did a technical phone screen for a Software Engineer role at Revolut. One coding problem, design-flavored, not a pure leetcode grind. Left feeling okay about it but not sure I nailed all the edge cases they were probably looking for.

Questions Asked (1)

Q1

Design and implement a minimal in-memory load balancer that routes requests to backend nodes chosen uniformly at random, supporting add, remove, and route operations with a fixed capacity cap.

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

My first instinct was to use a HashSet for O(1) add/remove, but then I realized route() needs random access by index and a HashSet doesn't give you that cleanly.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then design a data structure that supports O(1) add, remove, and random routing. Implement using an array with a hash map for index tracking, and discuss trade-offs like uniform randomness, capacity handling, and concurrency.

Pro tip: Emphasize the importance of uniform random selection and how the swap-with-last removal technique maintains O(1) operations while preserving uniformity. Also mention how you would handle edge cases like empty pool or full capacity.

1. Clarify Requirements

Ask about expected load, concurrency needs, capacity cap behavior (e.g., reject or evict), and whether nodes have weights. Confirm that routing must be uniformly random.

2. Design Data Structures

Propose using a dynamic array to store node references for O(1) random access, and a hash map from node ID to array index for O(1) add/remove. Discuss how to maintain uniformity when removing.

3. Implement Core Operations

Detail add: append to array and update map, checking capacity. Remove: swap with last element, pop, update map for swapped node, and remove from map. Route: generate random index and return node.

4. Handle Edge Cases and Concurrency

Address empty pool (return null or throw), full capacity (reject add), and thread-safety (e.g., use locks or concurrent structures). Discuss trade-offs of locking vs lock-free.

5. Analyze Complexity and Trade-offs

State that all operations are O(1) average time. Discuss memory overhead of hash map, and alternatives like reservoir sampling if nodes are added/removed frequently.

Key Points to Mention

  • Uniform random selection using random index generation
  • O(1) add/remove via swap-with-last and hash map index tracking
  • Capacity cap enforcement and behavior when full
  • Thread-safety considerations and potential locking strategies
  • Edge cases: empty pool, duplicate nodes, node failures
  • Trade-offs: memory vs speed, simplicity vs concurrency

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