Coupang Software Engineer Interview Experience — A Group Anagrams Twist and a Write-vs-Read Tradeoff Question

Team: Marketplace Growth, the US team (people in the group said the whole org is about 100 people — 50–60 in Korea, 30–40 in China, and only this one team in the US, around 10 people; the org head is based in the US).

Process: one phone screen (57 min) → onsite, same team. Phone screen structure: ~35 min coding → ~13 min project Q&A → ~10 min reverse questions.

Coding (HackerRank)

Question: a variant of Group Anagrams that needs to support three operations:

add(word)
remove(word)
largestGroup() // returns the current largest anagram group

Follow-ups:

• What's the time/space complexity of each of the three operations? (With a sorted-set approach, all three operations are O(log n), and space is linear.)
• "Between your first solution and this one, when would you use which? What metric would you look at to decide?" — this was the key question of the round. It was testing the write-optimized vs. read-optimized tradeoff: if writes are frequent and reads are rare, don't maintain a sorted structure — just scan when largestGroup is called; if it's the other way around, maintain the structure up front. Once I answered this clearly, he wrapped up the coding part.

A tip: HackerRank's environment doesn't have sortedcontainers. If you're coding in Python, don't count on third-party libraries — plan a fallback ahead of time (a hand-rolled heap or bucket approach).

Project Q&A

• What's the project you're most proud of, and why
• What made this project special, what did you learn from it
• Is there anything you'd do differently

What I learned from asking questions at the end:

• The team mainly owns: the catalog database used by Marketplace, auto-pricing (automatic price cuts), and seller score (seller quality assessment — it's offline rules, not a model)
• They used to work on promotions and recently moved to listing; the goal is to make the listing system more general-purpose and able to handle more traffic
• They don't do model development — "most of the stuff we do is more infrastructure work"
• On-call is fairly light (about once a month getting paged at night), and the alerts are mostly infrastructure-related: Kafka consumer lag, a table not getting produced on time for another team, the scoring system not updating in time
• The listing team is mostly in China, so you have to get used to evening meetings (the Korea/China teams come online around 5–6pm PT)