Logger with Remove, Truncate, Uppercase and Store Handlers and Stored-Message Search

Build a logger that passes every logged message to a set of handlers. The logger must support four handler types: - **Remove**: removes every occurrence of a configured string from the message, then prints the result. - **Truncate**: truncates the message to its first `N` characters, then prints the result. - **Uppercase**: converts the whole message to uppercase, then prints the result. - **Store**: keeps the message in an internal list without printing anything. The round then adds search over the stored messages and ends with a discussion of punctuation. In the reported round, the boundaries of every handler were agreed with the interviewer before any code was written, and the implementation and unit tests came after that (an AI assistant was allowed to write them), so expect the edge-case discussion to carry much of the weight. ### Clarifying Questions - Does every handler receive the original message, or does each handler receive the output of the one before it? - Remove: is matching case-sensitive? What does removing `aa` from `aaa` give, and if a removal creates a new occurrence (removing `ab` from `aabb`), is that removed too? What if the configured string is empty? - Truncate: what happens when `N` is zero, negative, or larger than the message length? Are characters counted as code points or as user-visible characters? - Uppercase: what happens to characters without case, and to characters whose uppercase form is longer, such as `ß`? - Can a logger hold several handlers of the same type, and can handlers be added or removed later? - Where does "print" write, and if one handler fails, do the others still run? ### Part 1 — The logger and the four handlers Implement the logger and the four handler types with the boundaries you agreed, and write unit tests for each handler and for the logger. ```hint Separate the transform from the output Three of the handlers compute a new string and then print it. Decide what they share, what differs, and how a test can see what a handler printed without reading the console. ``` #### What This Part Should Cover - A handler abstraction that the logger treats uniformly, so a new handler type needs no change to the logger - Exact behavior on every agreed boundary case for Remove, Truncate and Uppercase - Output that tests can capture, and a store that callers cannot modify from outside - Unit tests that pin each agreed boundary and the logger's fan-out to all handlers ### Part 2 — Search the stored messages Add search over the messages kept by the Store handler: given a query, return the stored messages that match it. ```hint Define a match first Decide whether a query matches anywhere inside a message or only whole words, whether case matters, and in what order results come back, before choosing a data structure. ``` #### Clarifying Questions for this Part - Is a match a substring, a whole word, or every word of a multi-word query? Is it case-sensitive? - Should results be the messages, their positions in the store, or both, and in what order? - How many messages are stored, and how often is search called compared with logging? #### What This Part Should Cover - A precise definition of a match and of the result order - A plain scan and its cost, and an index for when searches are frequent or the store is large - Keeping any index consistent as new messages are stored ### Part 3 — Messages that contain punctuation Discussion: how would you handle messages that contain punctuation? ```hint Follow one message everywhere Take a message such as `Error: disk full, retrying...` and trace it through each handler and through search. Note every place where a punctuation mark changes the result. ``` #### What This Part Should Cover - Where punctuation changes behavior: word matching in search, queries that themselves contain punctuation, and whether Remove works on substrings or on whole words - A tokenization rule and its edge cases, such as apostrophes, hyphens, decimals and dotted names - Which choices should be configurable rather than hard-coded, and what must stay untouched in the stored text ### What a Strong Answer Covers - Agrees each handler's boundary cases before implementing and turns them into tests - An extensible handler design with injected output and isolated failures - Correct string semantics for removal, truncation and uppercasing, including non-ASCII text - A precisely defined search with a sensible cost model - Concrete reasoning about punctuation rather than "strip it all" ### Follow-up Questions - Handlers must now run as a chain, each receiving the previous handler's output. What changes in your design? - Several threads log at the same time. What can go wrong in the Store handler and in search, and how do you prevent it? - The store must keep only the most recent messages. How does that interact with your search index? - How would you support a phrase query such as `disk full` that must match the two words next to each other?