Inverted-index posting-list evaluation
Design the low-level posting-list storage and query-evaluation engine of an inverted index that must answer boolean + phrase queries over a 5B-document corpus with very long posting lists for common terms (the term 'the' appears in billions of docs). A naive 'intersect two sorted doc-id lists' is too slow when one list is billions long and the other is short. How do you store posting lists compactly and evaluate AND/OR/phrase queries so the cost scales with the *smaller* list and with the result, not with the giant list?
What a strong answer looks like
Clarify scale and constraints first. Propose a clean component breakdown, then go deep on the hard parts (data model, bottlenecks, consistency, failure modes) and name the trade-offs you are making.
Clarify5:00 left
Estimate5:00 planned
Design15:00 planned
Deep dive12:00 planned
Failure8:00 planned
Which questions mattered is sealed until you submit. Telling you now would just be handing over the edge cases.
Run or narrate your approach, then ask the coach.