Implement Refactoring Assessment Features
Company: Luma
Role: Software Engineer
Category: Coding & Algorithms
Difficulty: hard
Interview Round: Technical Screen
Quick Answer: This question evaluates proficiency in implementing spec-driven algorithms and data structures in Java, covering route reconstruction (directed graph/path assembly and handling uniqueness and continuity constraints) and a versioned multi-level key-value store (time-versioned entries, deletions, and lexicographic scans).
Part 1: Reconstruct a Simple Route
Constraints
- 0 <= len(tickets) <= 200000
- start, from, and to values are non-blank strings for valid inputs
- Each ticket is a pair [from, to]
- A valid route must use every ticket exactly once
- No two valid tickets may have the same from value
Examples
Input: ([['SFO', 'LAX'], ['LAX', 'JFK'], ['JFK', 'BOS']], 'SFO')
Expected Output: ['SFO', 'LAX', 'JFK', 'BOS']
Explanation: The tickets already form a direct chain from SFO to BOS.
Input: ([], 'HOME')
Expected Output: ['HOME']
Explanation: With no tickets, the route contains only the starting location.
Input: ([['B', 'C'], ['A', 'B'], ['C', 'D']], 'A')
Expected Output: ['A', 'B', 'C', 'D']
Explanation: Tickets may be provided out of order; the route is reconstructed using the from-to links.
Input: ([['A', 'B'], ['B', 'A']], 'A')
Expected Output: ['A', 'B', 'A']
Explanation: A cycle is valid if all tickets are used exactly once.
Hints
- Because duplicate from values are invalid, you can map each from location to exactly one to location.
- While walking the route, track which from locations have already been used so you do not reuse a ticket in a cycle before all tickets are consumed.
Part 2: Versioned Multi-Level Key-Value Store
Constraints
- 0 <= len(operations) <= 200000
- recordKey, fieldKey, prefix, and value are strings
- Timestamps in operation input are positive integer strings
- Timestamps of set and delete operations are strictly increasing in call order
- Query timestamps may refer to the past, present, or future relative to previously processed updates
Examples
Input: ([['set', 'user1', 'name', 'Ana', '1'], ['set', 'user1', 'city', 'NYC', '2'], ['get', 'user1', 'name', '2'], ['scan', 'user1', '2'], ['delete', 'user1', 'name', '3'], ['get', 'user1', 'name', '4'], ['set', 'user1', 'name', 'Ann', '5'], ['get', 'user1', 'name', '5'], ['scan', 'user1', '5']],)
Expected Output: [['Ana'], ['city(NYC)', 'name(Ana)'], ['true'], [], ['Ann'], ['city(NYC)', 'name(Ann)']]
Explanation: The name field is visible, then deleted, then set again with a new value.
Input: ([] ,)
Expected Output: []
Explanation: No operations produce no results.
Input: ([['delete', 'r', 'a', '1'], ['get', 'r', 'a', '1'], ['set', 'r', 'apple', 'red', '2'], ['set', 'r', 'ape', 'gray', '3'], ['set', 'r', 'banana', 'yellow', '4'], ['scanByPrefix', 'r', 'ap', '4'], ['delete', 'r', 'apple', '5'], ['scanByPrefix', 'r', 'ap', '6']],)
Expected Output: [['false'], [], ['ape(gray)', 'apple(red)'], ['true'], ['ape(gray)']]
Explanation: Deleting a missing field returns false. Prefix scans include only existing matching fields in lexicographic order.
Input: ([['set', 'r', 'f', 'v1', '5'], ['get', 'r', 'f', '4'], ['get', 'r', 'f', '5'], ['set', 'r', 'f', 'v2', '10'], ['delete', 'r', 'f', '15'], ['get', 'r', 'f', '14'], ['get', 'r', 'f', '15'], ['set', 'r', 'f', 'v3', '20'], ['scan', 'r', '12'], ['scan', 'r', '16'], ['get', 'r', 'f', '20']],)
Expected Output: [[], ['v1'], ['true'], ['v2'], [], ['f(v2)'], [], ['v3']]
Explanation: Historical queries use the latest version at or before the requested timestamp, even after later updates have been processed.
Hints
- Store a sorted version history for each recordKey and fieldKey. Because update timestamps increase, you can append new versions.
- Use binary search to find the latest version whose timestamp is at most the query timestamp.