Solving Fizz Buzz with Cosines
Key topics
Regulars are buzzing about an unorthodox solution to the classic Fizz Buzz problem, which uses cosine functions to determine whether numbers are divisible by 3 or 5. Commenters riff on the creative approach, with some praising its mathematical ingenuity and others poking fun at its unnecessary complexity. As the discussion unfolds, a consensus emerges that while the cosine-based solution is an entertaining brain teaser, it's hardly the most practical or efficient way to tackle Fizz Buzz. The thread feels relevant right now because it highlights the playful side of coding culture, where problem-solving meets mathematical curiosity.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
1h
Peak period
26
0-12h
Avg / period
6.5
Based on 39 loaded comments
Key moments
- 01Story posted
Nov 21, 2025 at 12:28 PM EST
about 2 months ago
Step 01 - 02First comment
Nov 21, 2025 at 1:37 PM EST
1h after posting
Step 02 - 03Peak activity
26 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 29, 2025 at 7:07 PM EST
about 1 month ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
> interviewer: Great, we find that candidates who can't get this right don't do well here.
> me: ...
Shit attitude from that candidate, considering the interviewer is completely correct. I wouldn't hire them since they are obviously a problem employee.
For those that don't know, Fizz Buzz is less an aptitude test and more of an attitude test. That's why this candidate failed and didn't get the job.
The amount of (highly credentialed) interviewees that can't 0-shot a correct and fully functional fizzbuzz is also way higher than a lot of people would think. That's where the attitude part also comes in.
The articles which popularised FizzBuzz as an interview question stated as a categorical fact that most computer science graduates or programmer candidates (one article even said 199/200!![2]) cannot do FizzBuzz[1,2,3] and were absolutely recommending it as an aptitude test.
I personally think this whole thing was simply untrue back in 2007 (or at the very least incredibly overstated) and we are paying the price for it with ridiculous 15-stage interviews as a paranoid response to some urban legend from ~20 years ago.
[1]: https://imranontech.com/2007/01/24/using-fizzbuzz-to-find-de... [2]: http://weblog.raganwald.com/2007/01/dont-overthink-fizzbuzz.... [3]: https://blog.codinghorror.com/why-cant-programmers-program/
Yes, very much yes.
FWIW I have never been asked this question or similar, but since it's so famous I do have my own answer at the ready, which is just slightly more complex than the naive solution, but still well within the realm of production-worthy (maintainable, testable, readable) code. We don't really ever see any discussion of such because of course it isn't "interesting".
Does this ring a bell for anyone?
---
Found it!
https://aphyr.com/posts/340-reversing-the-technical-intervie...
https://aphyr.com/posts/341-hexing-the-technical-interview
https://aphyr.com/posts/342-typing-the-technical-interview
https://aphyr.com/posts/353-rewriting-the-technical-intervie... (the FizzBuzz one)
https://aphyr.com/posts/354-unifying-the-technical-interview
wow.
https://github.com/taolson/Admiran/blob/main/examples/fizzBu...
Of course, we could calculate the DFT using a tool, and from there work out the coefficients for the cosine terms. For example, we could get the coefficients for the exponential form like this:
https://www.wolframalpha.com/input?i=Fourier%5B%7B3%2C+0%2C+...
And then convert them to the coefficients for the cosine form like this:
https://www.wolframalpha.com/input?i=%7B11%2F15%2C+2*0%2C+2*...
That's certainly one way to avoid the tedious work but I decided to use the shortcuts as the basis for my post because I found this approach more interesting. The straightforward DFT method is perfectly valid as well and it would make an interesting post by itself.
Also probably easy enough to encode as quantum superpositions.
[0]: https://www.desmos.com/calculator/wgr3zvhazp
EDIT: the llm gods do recreational mathematics as well. claude actually thinks it was able to come up with and verify a solution...
https://claude.ai/share/5664fb69-78cf-4723-94c9-7a381f947633
This is orthogonal to the style, still, if it realizes that it can use Python's arbitrary precision integers instead of floats then the problem becomes absolutely trivial. Fast, and numerically stable.
Anyway an interesting read.
(The divisions will get optimized away.)
arr = [];
y = 0;
setInterval(()=>{arr[y]=x},10)
setInterval(()=>{x=y++},1000)
setInterval(()=>{x="fizz"},3000)
setInterval(()=>{x="buzz"},5000)
setInterval(()=>{x="fizzbuzz"},15000)
* Generate a tuple from 1 to 1000 and name it 'Sequence'
tuple_gen_sequence (1, 1000, 1, Sequence)
* Replace elements in 'Sequence' divisible by 3 with 'Fizz', storing the result in 'SequenceModThree'
tuple_mod (Sequence, 3, Mod)
tuple_find (Mod, 0, Indices)
tuple_replace (Sequence, Indices, 'Fizz', SequenceModThree)
* Replace elements in 'Sequence' divisible by 5 with 'Buzz', storing the result in 'SequenceModFive'
tuple_mod (Sequence, 5, Mod)
tuple_find (Mod, 0, Indices)
tuple_replace (SequenceModThree, Indices, 'Buzz', SequenceModFive)
* Replace elements in 'Sequence' divisible by 15 with 'FizzBuzz', storing the final result in 'SequenceFinal'
tuple_mod (Sequence, 15, Mod)
tuple_find (Mod, 0, Indices)
tuple_replace (SequenceModFive, Indices, 'FizzBuzz', SequenceFinal)
Alternatively, this process can be written more compactly using inline operators:
tuple_gen_sequence (1, 1000, 1, Sequence)
tempThree:= replace(Sequence, find(Sequence % 3, 0), Fizz')
tempFive:= replace(tempThree, find(Sequence % 5, 0), 'Buzz')
FinalSequence := replace(tempFive, find(Sequence % 15, 0), 'FizzBuzz')
In this program, I applied a vectorization approach, which is an efficient technique for processing large datasets. Instead of iterating through each element individually in a loop (a comparatively slower process), I applied operations directly to the entire data sequence in one step. This method takes advantage of Halcon's optimized, low-level implementations to significantly improve performance and streamline computations.
TFA implies that branches (if statements and piecewise statements) are not allowed, but I don't see why not. Seems like a basic operation to me.
Nevermind that `s[i]` is essentially a piecewise statement.
((cos((x0 + x0) * 1.0471969) * 0.66784626) + ((cos(sin(x0 * 0.628323) * -4.0887628) + 0.06374673) * 1.1508249)) + 1.1086457
with compleixty 22 loss: 0.000015800686 The first term is close to 2/3 * cos(2pi*n/3) which is featured in the actual formula in the article. the constant doesn't compare to 11/15 though
[0] https://github.com/MilesCranmer/PySR
I see a case for 3 * 5 in here:
Why?If we add 'Bazz' for mod 7, are we going to hardcode:
Or should we have done something like: I've been told sure, but that's a premature optimization, 3 factors wasn't in the spec. OK, but if we changed our minds on even one of the two factors, we're having to find and change 2 lines of code ... still seems off.Sort of fun to muse whether almost all FizzBuzz implementations are a bit wrong.
25 more comments available on Hacker News