Fizz buzz is a toy problem. I think it’s a mistake to read too much into anything but basic programming skills while using it as an interview question. If you want to test code quality and maintainability you are much better off with a more realistic problem.
On the contrary, it shows that the OP has a very good understanding of the type system. Plus, it’s an understandable approach given the code golf nature in which the original problem was presented. (Line length and character limits screams “code golf” to me)
I give lots of interviews and I try very hard to resolve ambiguity in the expectations and requirements. Up front I explain what the purpose of the interview is and what I intend to evaluate. It’s silly to assume everyone is equally able to read between the lines and coding interviews are already a very poor approximation of what a day to day software engineering job looks like, so I try my best to set expectations up front.
But it shows OP is "one trick pony" and interviewer told him it will not be proper approach but then he still went with it.
We also had some freelancers like that and one employee who lasted 3 months - and always it was company owners who wanted to "bring help to speed things up".
Those guys ignored everything and did code the way they knew how to do it. Results were always bad and 3 months guy instead of speeding anything up trashed all team productivity for those 3 months and I guess even 2 more when we had to do the cleanup of his worst inventions.
Two tricks. OP switched from programming to meta programming halfway through.
Also the reason given (not the right tool for the problem) was demonstrably false if we take the OP at face value. They solved it and their solution was robust to changing requirements.
We only know the OPs side of the story, but if we take it at face value it reads a lot like the interviewer wanted to jump them through hoops and they made the best of it. I would have politely declined the interview pretty early on if I was in their shoes.
