Loadingone moment…
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 ingestion team wants a daily count of events by type so they can see at a glance when a producer stops sending something. The feed is written by three different client SDKs, and none of them agree on how to spell a type: one uppercases it, one pads it with spaces, one sends it clean.
Write count_by_type(events). It takes the raw list of events and returns the count of each type, busiest first.
Function to write
count_by_type(events: list[dict]) -> dictA dict of normalised type to count, ordered by count descending then type ascending.
How to approach it
Normalise the type first, then count. The ordering is a sort at the end, not during the loop.
Sample cases
+ 2 held back until you submit
one type written four ways
click, CLICK and Click are the same type, and view arrives once padded with spaces.
Input
Argument 1
| id | type |
|---|---|
| e1 | click |
| e2 | CLICK |
| e3 | view |
| e4 | purchase |
| e5 | Click |
| e6 | view |
Returns
{
'click': 3,
'view': 2,
'purchase': 1
}an empty feed
No events in, no counts out — and no crash on the empty dictionary.
Input
Argument 1
[] (empty list)
Returns
{}a tie in the counts
Two types with two events each, so the alphabetical tie-break decides the order.
Input
Argument 1
| id | type |
|---|---|
| t1 | view |
| t2 | click |
| t3 | view |
| t4 | click |
Returns
{
'click': 2,
'view': 2
}Constraints
CLICK, click and click are one type with three events.type field, or has a type that is not a string or is blank once stripped. Skip it silently — a bad row is not an exception, it is a row the producer should never have sent.None.Worked example
The feed carries click, CLICK and Click as three separate rows, plus view with spaces around it and a clean view. Counting the raw strings gives five types with one or two events each, which is exactly the report nobody can read. Normalising first gives click with 3, view with 2 and purchase with 1.
The ordering rule matters more than it looks. In the tie case, view and click both have two events; without the alphabetical tie-break the order depends on which type happened to appear first in the feed, so the same data produces a different report on a different day.
What this tests
Accumulating into a dict, and the habit of normalising a value before using it as a key. The ordering rule is what separates a report that can be diffed between runs from one that only looks stable.
count_by_type(events: list[dict]) -> dictSubmit 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.