Code RoomChangelog grouping by component
EasyPrep Room Coding #4918

Changelog grouping by component

CodingAlgorithms & data structuresEntry–Mid~15 min

A release note generator groups changelog entries by component before it prints. entries holds one change per string, written as the component, then a vertical bar, then the summary. The component is everything before the first bar, so a summary is free to contain bars of its own, and every entry carries at least one bar. Components compare exactly, which makes API and api two different components. Return the entries regrouped so that all the entries of one component sit together, with the components in the order their first entry appeared in the changelog, and the entries inside a component kept in the order they were written. Nothing is dropped and nothing is rewritten. An empty changelog returns an empty list.

Implement
group_by_first_seen(entries: list[str]) → list[str]
Examples
in[["api|add pagination","cli|new flag","api|fix 500","docs|typo"]]out["api|add pagination","api|fix 500","cli|new flag","docs|typo"]
in[["b|two","a|one","b|three","a|four"]]out["b|two","b|three","a|one","a|four"]
in[["ui|dark mode","ui|spacing"]]out["ui|dark mode","ui|spacing"]
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
[["api|add pagination","cli|new flag","api|fix 500","docs|typo"]]["api|add pagination","api|fix 500","cli|new flag","docs|typo"]not run yetsample
[["b|two","a|one","b|three","a|four"]]["b|two","b|three","a|one","a|four"]not run yetsample
[["ui|dark mode","ui|spacing"]]["ui|dark mode","ui|spacing"]not run yetsample