Question presented to candidate: "What is a Bloom filter? Explain how it works, what kind of mistakes it can make, how you would size one, and give me a couple of places in a real system where you would use it."
What a strong answer should cover:
- The structure: a bit array of m bits and k hash functions; add sets k bits, a lookup checks the same k bits
- The guarantee: no false negatives ("not present" is always right), tunable false positives ("maybe present" can be wrong)
- The maths: false-positive rate about (1 - e^(-kn/m))^k; optimal k = (m/n) ln 2; about 9.6 bits per item for 1%, independent of item size
- What it cannot do: no deletes (unless counting or cuckoo filters), no listing members, and the error rate climbs fast when you insert more than it was sized for
- Real uses: LSM-tree databases skipping files that cannot hold a key (Cassandra keeps one per SSTable), guarding a cache or database from lookups of keys that do not exist, crawlers checking seen URLs; Redis 8 ships Bloom filters built in
- The trade-off in one line: memory and speed for a small, known chance of an unnecessary expensive lookup
Code / implementation expected: Optional β a short implementation (bit array plus double hashing) or the sizing formula; the example builds one and measures its error rate.