Practice
Node1(val=1) -> Node2(val=2) -> Node3(val=3), where Node1.random = Node3, Node2.random = Node1, Node3.random = null.
After Step 2 (assigning random pointers), what is the value of
copy_curr.random.val when copy_curr points to the copied node of Node2?Solution
Step 1: Trace Step 1 (interleaving nodes)
Original list: 1 -> 2 -> 3 becomes 1 -> 1' -> 2 -> 2' -> 3 -> 3'.Step 2: Trace Step 2 (assign random pointers)
Node2.random = Node1, so copied Node2 (2') random = Node1.next = 1'. Thus, copy_curr.random.val = 1.Final Answer:
Option C -> Option CQuick Check:
copy_curr.random points to copied Node1 with val=1 [OK]
- Confusing original and copied nodes when assigning random pointers
- Off-by-one errors in stepping through interleaved list
- Assuming random pointer points to original node's val
travel_time when checkOut(1, "Leyton", 20) is called after checkIn(1, "Paradise", 3) and checkIn(2, "Leyton", 10)?
class Node:
def __init__(self, id, station, time):
self.id = id
self.station = station
self.time = time
self.next = None
class UndergroundSystem:
def __init__(self):
self.head = None
self.route_data = {}
def checkIn(self, id: int, stationName: str, t: int) -> None:
new_node = Node(id, stationName, t)
new_node.next = self.head
self.head = new_node
def checkOut(self, id: int, stationName: str, t: int) -> None:
prev = None
curr = self.head
while curr:
if curr.id == id:
travel_time = t - curr.time
route = (curr.station, stationName)
if route not in self.route_data:
self.route_data[route] = [0, 0]
self.route_data[route][0] += travel_time
self.route_data[route][1] += 1
if prev:
prev.next = curr.next
else:
self.head = curr.next
return
prev = curr
curr = curr.next
Solution
Step 1: Trace checkIn calls
First, checkIn(1, "Paradise", 3) adds Node(id=1, station="Paradise", time=3) at head. Then checkIn(2, "Leyton", 10) adds Node(id=2, station="Leyton", time=10) at head.Step 2: Trace checkOut(1, "Leyton", 20)
Traverse linked list from head: Node with id=2 (not match), then Node with id=1 (match). travel_time = 20 - 3 = 17.Final Answer:
Option B -> Option BQuick Check:
Check-in time for id=1 is 3, checkout time is 20, difference is 17 [OK]
- Using wrong node's time due to linked list order
Solution
Step 1: Understand the problem constraints
The problem requires flattening a multilevel doubly linked list in-place without extra space.Step 2: Identify the approach that guarantees in-place flattening without extra space
Using a recursive depth-first traversal that returns the tail of each flattened child list allows splicing child lists correctly and efficiently without extra data structures.Step 3: Evaluate other options
Iterative splicing (Iteratively traverse the list, and whenever a node has a child, splice the child list in place by connecting the child's tail to the node's next, updating pointers accordingly.) can cause repeated tail searches leading to O(n^2) time and is less straightforward. Greedy appending (Apply a greedy approach that always appends child lists at the end of the main list after full traversal.) fails to maintain order. Dynamic programming (Use dynamic programming to store intermediate flattened sublists and merge them bottom-up.) is not applicable.Final Answer:
Option B -> Option BQuick Check:
Recursive DFS approach is standard and efficient for in-place flattening [OK]
- Assuming iterative splicing is always best despite complexity
- Appending child lists only at the end
- Using DP which is not applicable here
get operation in the optimal SnapshotArray implementation that uses a hash map per index with binary search, assuming m snapshots and k set operations?Solution
Step 1: Identify data structure for get
Each index stores a sorted list of (snap_id, value) pairs, with length up to number of set operations k but bounded by m snapshots.Step 2: Analyze get operation
Get uses binary search on this list to find the value for the requested snap_id, which takes O(log m) time since at most one entry per snapshot per index.Final Answer:
Option D -> Option DQuick Check:
Binary search on sorted snapshot list yields O(log m) [OK]
- Assuming get is O(1) due to direct indexing
- Confusing linear search with binary search
Solution
Step 1: Understand the problem extension
Passengers can have multiple active trips simultaneously, so a single check-in per id is insufficient.Step 2: Choose data structure to track multiple check-ins
A stack per passenger id allows tracking multiple check-ins in order, enabling correct matching on checkOut.Step 3: Why other options fail
Overwriting check-ins loses data (A). Traversing full list each time (C) is inefficient. Disallowing multiple check-ins (D) is not a solution.Final Answer:
Option A -> Option AQuick Check:
Stack per id supports multiple active trips correctly [OK]
- Overwriting check-in info loses data
