Compact Conversations by Unique Listings
Reported by candidates from Sierra's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Sierra reported this one in October 2026, and the whole thing hinges on a hash map of occurrence counts. If your OA invite lists it, you'll see a queue of conversations, a pile of repeated string IDs, and a cap on distinct listings. It looks like a design problem. It's a counting problem with a pointer. You evict the oldest conversation until the distinct total fits, then print survivors in first-appearance order. StealthCoder is the safety net if you blank on the live assessment, but the logic below is short enough to hold in your head.
The problem
You are given an ordered array conversations. Each conversation contains listing identifiers, and an identifier may appear in several conversations or more than once in one conversation. While the retained history contains more than maxUniqueListings distinct identifiers, remove the oldest entire conversation. Use identifier occurrence counts so an identifier stops contributing to the distinct total only after its final retained occurrence is removed. After eviction finishes, return the distinct identifiers from the retained conversations in first-appearance order. Include each identifier exactly once. Function compactUniqueListings(conversations: String[][], maxUniqueListings: int) → String[] Examples Example 1 conversations = [["a","b","c"],["b","c","d"],["e"]] maxUniqueListings = 4 return = ["b","c","d","e"] All conversations contain five distinct identifiers. Removing the oldest conversation deletes the final occurrence of "a", leaving the first-appearance order ["b","c","d","e"]. Example 2 conversations = [["x","x"],["x"]] maxUniqueListings = 1 return = ["x"] The history already contains one distinct identifier, so no conversation is removed. Repeated occurrences produce one output entry. Example 3 conversations = [["a"],["b"],["a"]] maxUniqueListings = 1 return = ["a"] Removing the first conversation does not remove "a" from the distinct set because it appears later. Removing the second conversation deletes "b", leaving only "a". Constraints 0 <= conversations.length <= 10^5 The total number of listing occurrences across all conversations is at most 10^5. Every listing identifier is a non-empty ASCII string. 0 <= maxUniqueListings <= 10^5
Reported by candidates. Source: FastPrep
Pattern and pitfall
Build a count map of every identifier across all conversations, and track distinct as the number of keys with count above zero. Then keep a start index. While distinct exceeds maxUniqueListings, walk the conversation at start, decrement each identifier's count, and when a count hits zero drop distinct by one. Advance start. The pitfall is removing an ID from the set on its first eviction. Example 3 shows why: "a" survives because a later copy exists. Duplicates inside one conversation matter too, so count every occurrence, not every unique ID per conversation. After eviction, scan the remaining conversations in order and use a seen set to emit each ID once. Watch maxUniqueListings of 0, which empties everything. Total work is linear in the occurrences, so 10^5 is easy. If you freeze mid-assessment, StealthCoder can hand you this structure in real time.
Memorize the pattern. If you can't, run StealthCoder. The proctor sees the IDE. They don't see what's behind it.
You can drill Compact Conversations by Unique Listings cold, or you can hedge it. StealthCoder runs invisibly during screen share and surfaces a working solution in under 2 seconds. The proctor sees the IDE. They don't see what's behind it. Made by an engineer who treats the OA as theater. If yours is tonight, you don't have time to grind. You have time to hedge.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Sierra's OA.
Sierra reuses patterns across OAs. Made by an engineer who treats the OA as theater. If yours is tonight, you don't have time to grind. You have time to hedge. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Compact Conversations by Unique Listings FAQ
How hard is the Sierra compact conversations problem really?+
Easy to medium. There's no fancy algorithm. You need a count map, a moving start pointer, and a seen set for output. Most people lose points on edge cases like duplicates inside one conversation or a cap of zero, not on the core idea.
What's the trick to this problem?+
Track occurrence counts, not just a set of IDs. An ID only leaves the distinct total when its count reaches zero. Evict whole conversations from the oldest end, decrementing each ID, until distinct is at or under the cap.
What's the time complexity I should aim for?+
Linear in total occurrences, O(N) with N up to 10^5. Each occurrence is counted once, decremented at most once during eviction, and scanned once for output. Anything that rescans retained history after each eviction risks going quadratic.
What edge cases should I test before submitting?+
Test maxUniqueListings of 0, which should return an empty array. Test empty conversations, an ID repeated within one conversation, and an ID that appears in an evicted conversation and a later one. Also confirm output follows first appearance in retained history only.
How do I prepare for this in 48 hours?+
Write this solution once from scratch with a hash map of counts and a pointer. Then do a couple of sliding-window-style eviction problems on queues. Focus on getting count decrement logic right. You don't need broader theory for this one.