Normalize and Aggregate Error Logs
Reported by candidates from Temporal's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
With up to 200000 logs and 500 characters each, nested comparisons between logs are dead on arrival. This Temporal OA, reported in February 2026, is a string parsing and hash map grouping problem dressed up as log analysis. Split each line on the pipe, swap digits for #, count by a composite key, then sort the output. It's easy to read and easy to botch on the details. If you freeze on the sort order or the output format, StealthCoder runs invisibly during the live OA and gives you a working solution as a safety net.
The problem
Each log is encoded as timestamp|errorCode|link|api. Normalize its link by replacing every decimal digit with #, then group logs with the same error code, API, and normalized link. Return one row per group as errorCode|api|normalizedLink|count, sorted lexicographically by the complete first three fields. Function aggregateErrors(logs: String[]) → String[] Examples Example 1 logs = ["10|E1|/users/123|GET","11|E1|/users/456|GET","12|E2|/users/123|GET"] return = ["E1|GET|/users/###|2","E2|GET|/users/###|1"] The two E1 links normalize to the same tuple. Example 2 logs = ["1|ERR|/v2/a9|POST","2|ERR|/v20/a8|POST"] return = ["ERR|POST|/v##/a#|1","ERR|POST|/v#/a#|1"] Digit replacement preserves how many digits each link contained and the rows are sorted lexicographically. Example 3 logs = ["1|A|/x|GET"] return = ["A|GET|/x|1"] A link without digits is unchanged. Constraints 1 <= logs.length <= 200000. Every log has exactly four non-empty fields separated by |. Fields contain printable ASCII characters other than |; each log is at most 500 characters.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The trick is a single pass with a hash map. For each log, split into timestamp, errorCode, link, api. Replace every digit in the link with #. Build a key from errorCode, api and normalizedLink, using a tuple or a delimiter that can't appear in the fields (the fields never contain |, so that's safe). Increment the count. That's O(n * L) for n logs of length L, which fits the constraints easily. The pitfalls: the input order is timestamp|errorCode|link|api, but the output order is errorCode|api|normalizedLink|count, so don't mix them up. Sort lexicographically by the first three fields, not by count. Example 2 shows why: ERR|POST|/v##/a# sorts before ERR|POST|/v#/a# because '#' (35) is less than '/' (47). Sort on the tuple, not on the joined string with count appended, or numeric suffixes can break ties. If you freeze, StealthCoder is your hedge on the live OA.
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 Normalize and Aggregate Error Logs 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 Temporal's OA.
Temporal 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.
Normalize and Aggregate Error Logs FAQ
What's the trick in Normalize and Aggregate Error Logs?+
Hash map grouping on a composite key of errorCode, api and normalizedLink. Normalize by replacing every digit with #, count occurrences, then sort the keys. No log needs to be compared to another, so it runs in linear time plus the sort.
How hard is this Temporal OA question really?+
Easy to medium. There's no clever algorithm. The difficulty is in details: the input field order differs from the output order, digits map one-to-one to # so length is preserved, and the sort is lexicographic on three fields, not on the count.
Will brute force pass with 200000 logs?+
No. Comparing every pair of logs is about 2 x 10^10 comparisons, each costing string work. A single pass with a hash map and one final sort handles it comfortably. Always group by key instead of comparing logs against each other.
How should I sort the output rows?+
Sort by the tuple (errorCode, api, normalizedLink) with plain string comparison, then format each row with its count. Example 2 confirms that '#' sorts before '/', so /v##/a# comes before /v#/a#. Don't sort by count or by insertion order.
How do I prepare for this in 48 hours?+
Write a split-normalize-count-sort routine in your language of choice until it's automatic. Practice string splitting on a delimiter, a digit check, dictionary counting and custom sort keys. Test against the three examples, especially the no-digit link and the digit-length case.