The fizzbuzz that did not get me the job

• Candidate solves FizzBuzz interview using TypeScript types instead of runtime code, handling every constraint including "no numeric operations allowed"
• When told hardcoded lookup tables are "cheating," switches entire solution to base-15 representation so divisibility by 3 and 5 can be checked via last digit (since both are factors of 15)
• Interviewer keeps adding rules and eventually makes up "no hardcoded matrices" rule mid-interview, seemingly to force the candidate to fail
• Despite handling 16+ increasingly complex rules and demonstrating deep understanding of number theory and type systems, candidate doesn't get the job
• Raises questions about whether technical interviews punish unconventional thinking and whether interviewers move goalposts when candidates don't follow expected solution paths

A developer shares their experience with a FizzBuzz interview that spiraled into an exercise in creative problem-solving under increasingly arbitrary constraints. When told they couldn't use numeric types or mathematical operations, they initially used string manipulation and digit-sum checking. But when the interviewer declared their lookup table "cheating," they made a brilliant pivot: switching to base-15 number representation.

The key insight was recognizing that divisibility by the last digit only works for factors of the base (2 and 5 are factors of 10, which is why multiples of 5 end in 0 or 5). By encoding numbers in base-15, both 3 and 5 become factors of the base, making divisibility checkable via the last digit alone. This eliminated the need for any hardcoded tables while staying under the 30-line limit.

Despite successfully handling 16+ rules—including edge cases for zero, decimals, invalid inputs, and changing "FizzBuzz" to "Bazz" for numbers divisible by both 3 and 5—the candidate felt the interview was unfair. The "no hardcoded matrices" rule appeared to be invented on the spot when their initial solution was too robust. The interviewer later admitted they wanted to see candidates struggle and debug, but the type-system approach was too resilient.

The story highlights a tension in technical interviews: the candidate demonstrated deep knowledge of type systems, number theory, and creative problem-solving, but may have been penalized for not following the expected path of writing buggy imperative code that needs debugging. It raises questions about whether interviews measure actual engineering skill or just conformity to expected solution patterns.