Sign in to run and submit your work
Reading is open to everyone. Running code and saving drafts need an account so your work is yours and comes back on your next visit.
or
CODE WORKSPACE
The on-call team is drowning in pages and wants the weekly review to open with the handful of error codes that fire most. The alerting log records one code per page, but three services emit it, and they disagree on case and padding — and now and then a broken emitter writes a null or a blank.
Write top_error_codes(codes, k). It takes codes, a list of error-code entries in the order they fired (normally strings like "E503"), and k, an integer, and returns the k most frequent normalised codes as a list of [code, count] pairs, busiest first.
Function to write
top_error_codes(codes: list, k: int) -> list[list]Up to k [code, count] pairs of normalised codes, ordered by count descending then code ascending.
How to approach it
Counting is one pass; picking k from the counts does not need a full sort — and a tie on count needs a rule that does not depend on log order.
Sample cases
+ 4 held back until you submit
one code written three ways
E503, 'e503 ' and ' E503' are one code with 3 alerts; counted raw, E429 would wrongly top the list.
Input
Argument 1
[
'E503',
'e503 ',
'E429',
' E503',
'E500',
'E429'
]Argument 2
2Returns
[
[
'E503',
3
],
[
'E429',
2
]
]ties go to the code, not to who fired first
E504 and E502 tie on 2, and E401 and E400 tie on 1 at the k cut; the smaller code by string comparison wins each tie.
Input
Argument 1
[
'E504',
'E502',
'E504',
'E502',
'E401',
'E400'
]Argument 2
3Returns
[
[
'E502',
2
],
[
'E504',
2
],
[
'E400',
1
]
]k larger than the distinct codes
Only two distinct codes exist, so asking for 5 returns both of them rather than padding or raising.
Input
Argument 1
[
'E429',
'E429',
'E500'
]Argument 2
5Returns
[
[
'E429',
2
],
[
'E500',
1
]
]k of zero
Asking for zero codes returns an empty list even though the log is not empty.
Input
Argument 1
[
'E500',
'E500'
]Argument 2
0Returns
[] (empty list)
Constraints
"e503 ", " E503" and "E503" are one code.[code, count] lists (lists, not tuples), ordered by count descending. When two codes have the same count, the smaller code by plain string comparison comes first (so E10 sorts before E9) — never the one that fired first.k is 0 or negative, or there are no usable codes, return []. If k is larger than the number of distinct codes, return all of them.Worked example
Take ["E503", "e503 ", "E429", " E503", "E500", "E429"] with k = 2. Normalise first: E503, E503, E429, E503, E500, E429. Count into a dict: E503 → 3, E429 → 2, E500 → 1. Rank by the key (−count, code): (−3, E503), (−2, E429), (−1, E500). The two smallest keys are the answer: [["E503", 3], ["E429", 2]]. Counting the raw strings instead makes E429 top the list with 2, and E503 — the real busiest code — shows up with a count of 1, because its other two alerts were counted under "e503 " and " E503".
The trap is in the tie case: E504 and E502 both fire twice, and E504 fired first. Sorting by count alone keeps log order and puts E504 first; the contract says E502. The same rule picks E400 over E401 for the third slot.
What this tests
Counting with a hash map, then selecting the top k with a heap: LeetCode 'Top K Frequent Elements' in data clothing. The dict count is the hashing half — one O(n) pass. Selecting with heapq.nsmallest keeps only k candidates, so choosing from m distinct codes is O(m log k) against O(m log m) for sorting them all, which matters when k is 10 and there are a million distinct keys. A data engineer meets it for real in top-N dashboards, heavy-hitter detection and alert triage. It is reported in data engineering loops: 'Top K Frequent Elements' is tagged for data engineers at Adobe, Apple, Amazon and Microsoft on Exponent, and Paytm data engineering candidates report 'frequency of each word in a string', its counting half.
top_error_codes(codes: list, k: int) -> list[list]Submit for review to find out what your query gets right, what it gets wrong, and how it compares with the best working query for this exercise.
This scenario runs a full workspace — editor, canvas and results side by side. It needs a laptop or desktop to be usable. Open this page on a bigger screen to start building.