aichallengesafrica
Take a challenge
HomeChallengesRepsProblemsLeaderboardTake a challenge

Index, Do Not Scan

An orders table shows the customer name on every row, and it takes four seconds to render. The data is fine. The lookup is not.

Beginner15 min on the clock5 graded checks · 100 pointsData Structures at Work
Graded by running your code against real cases.

What you build

  • indexById(items) — a Map from id to the item
  • attachCustomer(orders, customers) — each order with its customer attached
  • uniqueCategories(orders) — every category once, sorted
  • hasDuplicateIds(items) — true when two items share an id
  • One case runs 20,000 orders against 20,000 customers on a time budget

Done means

Every function is correct, and the 20,000-row case finishes inside its budget.

How it is graded

Published in full, before you start — every point is one of these and there is nothing else. Each one runs your code; it is not a search for keywords.

  1. indexById builds a Map keyed by id+20Indexes and lookups
  2. attachCustomer joins the two lists+25Indexes and lookups
  3. It still finishes with 20,000 orders+25The cost of a loop inside a loop
  4. uniqueCategories returns each one once, sorted+15Indexes and lookups
  5. hasDuplicateIds spots a repeated id+15Indexes and lookups

What it teaches

Indexes and lookupsbeginner

An index is a Map built once so you can find a thing by its id instantly, instead of searching the whole list every time you need it — which is the difference between a table that renders instantly and one that takes four seconds.

The cost of a loop inside a loopintermediate

A search inside a loop does the work once per row per row: at 20,000 rows that is 400 million comparisons, and it is the single most common reason a working feature is unusably slow.

The rest of Data Structures at Work

Group and TotalBeginner · 15 minThreaded CommentsIntermediate · 20 minAn LRU CacheIntermediate · 20 minThe Job SchedulerAdvanced · 25 min