Code RoomModal focus trap
EasyPrep Room Coding #4845

Modal focus trap

CodingAlgorithms & data structuresEntry–Mid~15 min

A modal dialog traps keyboard focus, and a test harness reproduces that from data so the team can assert it without a browser. Each element inside the dialog arrives as one string: its id, a vertical bar, then its state, which is ready, disabled or hidden. The list is in document order and ids are unique. Only a ready element can hold focus. Focus starts on start_id when that element is ready, and otherwise on the dialog itself, written as an empty string. keys holds the presses in order, each either Tab or Shift+Tab. Tab moves to the next ready element, wrapping from the last round to the first. Shift+Tab moves to the previous, wrapping from the first round to the last. From the dialog itself, Tab lands on the first ready element and Shift+Tab on the last. Return the id focused after each press, in order. When nothing is ready, every press reports the empty string.

Implement
focus_trap_sequence(elements: list[str], start_id: str, keys: list[str]) → list[str]
Examples
in[["close|ready","name|ready","save|ready"],"name",["Tab","Tab","Tab"]]out["save","close","name"]
in[["close|ready","name|disabled","save|ready"],"close",["Tab","Shift+Tab","Shift+Tab"]]out["save","close","save"]
in[["close|ready","name|ready"],"",["Shift+Tab","Tab"]]out["name","close"]
What a strong answer looks like

State your approach and its time/space complexity out loud before you optimize. Handle the edge cases (empty input, duplicates, overflow), and say why you chose this over the brute force. Green tests are the floor, not the grade.

0:00 of about 15 min
InputExpectedGot
[["close|ready","name|ready","save|ready"],"name",["Tab","Tab","Tab"]]["save","close","name"]not run yetsample
[["close|ready","name|disabled","save|ready"],"close",["Tab","Shift+Tab","Shift+Tab"]]["save","close","save"]not run yetsample
[["close|ready","name|ready"],"",["Shift+Tab","Tab"]]["name","close"]not run yetsample