← Whatnot Interview Insights

Whatnot·Software Engineer·Technical Phone Screen·Intermediate

Intermediate
Jul 2026

Summary

Whatnot software engineer interview with a two-part coding problem around building a content safety filter for a chat platform. The problem started straightforward but the follow-up pushed into trie territory pretty fast.

Questions Asked (2)

Q1

Given a list of chat messages and a list of banned words, return only the messages whose text contains none of the banned words. Tokenization is whitespace-only, punctuation stays attached to tokens, and matching is case-insensitive.

Algorithms & Data StructuresTechnical Trade-offs
Author's notes

The punctuation rule is what trips people up.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the problem constraints and edge cases, then propose an efficient solution using a hash set for banned words and tokenization. Discuss trade-offs like time/space complexity and potential optimizations for large inputs.

Pro tip: Mention that you would preprocess the banned words into a set for O(1) lookups, and consider streaming the messages to handle large datasets without loading everything into memory.

1. Clarify requirements and edge cases

Ask about input sizes, case sensitivity, punctuation handling, and whether messages can be empty or contain multiple spaces. Confirm that tokenization is whitespace-only and matching is case-insensitive.

2. Design the algorithm

Propose using a set for banned words (lowercased) and for each message, split by whitespace, lowercase each token, and check against the set. If no token matches, include the message.

3. Analyze complexity and trade-offs

Discuss time complexity O(total tokens) and space O(banned words + output). Mention alternatives like regex or trie for partial matching, but note they are unnecessary here.

4. Handle edge cases and optimizations

Address empty messages, messages with only banned words, and large inputs. Suggest streaming or early termination for efficiency.

5. Test with examples

Walk through a sample input to verify correctness, including case variations and punctuation attached to tokens.

Key Points to Mention

  • Use a hash set for banned words to achieve O(1) lookup per token.
  • Tokenization by whitespace only, preserving punctuation as part of tokens.
  • Case-insensitive matching by lowercasing both banned words and tokens.
  • Time complexity: O(total number of tokens across all messages).
  • Space complexity: O(number of banned words + size of output).
  • Consider streaming for large inputs to avoid loading all messages into memory.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

Extend the filter to support banned phrases (multi-word sequences). A phrase matches only if its words appear as consecutive tokens in the message, in order, case-insensitively. The follow-up asks you to do this efficiently using a single left-to-right pass over each message's tokens rather than checking every phrase independently at each position.

Algorithms & Data StructuresSystem DesignTechnical Trade-offs
Author's notes

This is where it got interesting.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First, clarify the requirements: phrases are multi-word sequences that must match consecutive tokens in order, case-insensitively, and we need a single left-to-right pass. Then, propose building a trie (prefix tree) from the banned phrases, where each node represents a token and terminal nodes mark the end of a phrase. During the pass, maintain a set of active trie nodes (or a single pointer if using Aho-Corasick) and advance them token by token, reporting matches when a terminal node is reached.

Pro tip: Mention that a naive trie per position is O(n * max_phrase_length) but can be optimized to O(n) by using Aho-Corasick or by maintaining active states; also note that tokenization and case normalization should happen once upfront to avoid repeated work.

1. Clarify requirements and constraints

Confirm that phrases are sequences of tokens, matching is case-insensitive, and we need a single left-to-right pass. Discuss tokenization (e.g., splitting on whitespace/punctuation) and whether overlapping matches should be reported.

2. Choose data structure: Trie or Aho-Corasick

Build a trie from all banned phrases, where each node represents a token and terminal nodes mark phrase ends. For efficiency, consider Aho-Corasick to handle failure links and avoid restarting from scratch at each position.

3. Design the single-pass algorithm

Iterate over tokens, maintaining a set of active trie nodes (or a single Aho-Corasick state). For each token, transition active nodes to children; if a terminal node is reached, record a match. Add the root's child for the current token to active nodes for starting new matches.

4. Analyze complexity and trade-offs

Explain that with a trie and active set, worst-case time is O(n * L) where L is max phrase length, but Aho-Corasick achieves O(n + total matches). Discuss memory trade-offs and whether to precompute or build on the fly.

5. Handle edge cases and test

Consider overlapping phrases, phrases that are prefixes of others, empty tokens, and case normalization. Walk through a small example to verify correctness and efficiency.

Key Points to Mention

  • Tokenization and case normalization should be done once upfront.
  • Trie (prefix tree) is ideal for multi-word phrase matching.
  • Aho-Corasick automaton enables O(n) matching by avoiding redundant checks.
  • Maintain active states to handle overlapping and nested phrases.
  • Time complexity: naive per-position trie is O(n * L), Aho-Corasick is O(n + matches).
  • Space complexity: O(total characters in phrases) for the trie.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.