Lightning talks with team caps
A hack week committee fills k lightning talk slots from the proposals it received. proposal_ids, teams and scores are parallel lists holding each proposal's identifier, the team that submitted it, and the review score it earned. To keep one team from owning the schedule, no team may hold more than cap slots. Work down the proposals from the highest score, giving a slot to each proposal whose team still has room and passing over the rest, until the slots run out or the proposals do. A proposal that is passed over does not use up a slot. Two proposals on the same score are considered in identifier order, comparing as plain text. Return the identifiers of the chosen proposals in the order they were chosen. Return an empty list when k or cap is zero or below. Identifiers are distinct and scores can be negative.
fill_lightning_slots(proposal_ids: list[str], teams: list[str], scores: list[int], k: int, cap: int) → list[str][["p1","p2","p3","p4"],["a","a","b","c"],[90,85,80,70],3,1]out["p1","p3","p4"][["z9","a1"],["x","y"],[50,50],2,2]out["a1","z9"][["p1","p2","p3"],["a","b","a"],[40,60,50],2,5]out["p2","p3"]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.
[["p1","p2","p3","p4"],["a","a","b","c"],[90,85,80,70],3,1]["p1","p3","p4"]not run yetsample[["z9","a1"],["x","y"],[50,50],2,2]["a1","z9"]not run yetsample[["p1","p2","p3"],["a","b","a"],[40,60,50],2,5]["p2","p3"]not run yetsample