My favorite coding question to give candidates
A popular blog post about a “favorite” coding interview question – finding “loyal customers” from two days of web logs – has triggered debate over what interviews should really measure. Commenters argue over the value of ambiguity in the problem statement, the insistence on avoiding O(n²) solutions, and whether optimizing in-memory algorithms is realistic compared to simply using SQL or shell tools. Many see the exercise as a proxy for data-structure and communication skills, while others criticize it as contrived, favoring people who are good at whiteboard puzzles rather than those who build maintainable, business-focused systems.
Ambiguity and “trickiness” of the prompt
- Many see the “loyal customers” spec (esp. “at least two unique pages”) as underspecified or logically ambiguous.
- Some argue this mirrors real-world product specs and tests ability to spot ambiguity and ask clarifying questions.
- Others see it as unfair “mind reading,” especially in stressful interviews where candidates may fear that asking questions is penalized.
- There’s concern that interviewers overestimate how clearly they’ve signaled “please ask questions.”
What the question is actually testing
- Supporters say it tests:
- Recognizing bad asymptotic complexity (rejecting naive O(n²)).
- Use of basic data structures (maps/sets) and time–space tradeoffs.
- Ability to reason about large data and constraints.
- Critics say it mostly rewards LeetCode-style pattern matching and Big-O talk, not real-world skills like understanding requirements, system design, or working with stakeholders.
- Some highlight that the optimal in-memory solutions are brittle and tightly coupled to “exactly two days,” hurting extensibility.
Alternative solution styles (SQL, shell, tools)
- Several would solve it with shell pipelines (sort/uniq/grep/awk) or a small SQLite/DB query, especially for one-off business reports.
- Debate:
- Pro-DB/shell: fastest to implement, easier to tweak requirements, handles big data via external sort/indexes.
- Pro-“20 lines of code”: keeps dependencies minimal; focuses on algorithmic understanding.
- Some note the problem is essentially a relational join; DB execution plans (hash join, merge join) mirror the proposed CS solutions.
Performance vs practicality
- Strong disagreement over “no great engineer should ever settle for O(n²).”
- One side: quadratic algorithms are dangerous landmines; better approaches are usually just as simple and should be instinctive.
- Other side: for one-off or small datasets, developer time and simplicity matter more than asymptotics; premature optimization is common.
- Several point out that clever micro-optimizations (storing only 2 pages, early exits, etc.) add complexity and reduce flexibility for evolving metrics.
Interview design, bias, and candidate experience
- Some praise the question as simple, revealing, and suitable even for seniors; others describe algorithmic live-coding as boring, soulless, or “dehumanizing.”
- Concern that this style selects for:
- People comfortable under high-pressure, adversarial-feeling tests.
- Those who have specifically trained on similar problems.
- Others advocate collaborative, pair-programming-style exercises or small realistic tasks (e.g., CLI apps) as better signals of day-to-day effectiveness and teamwork.