If an interviewer asks FizzBuzz, it means they want to do a quick sanity check that you can write code to solve a simple problem. Answer the question and the interview can move on to something more interesting.
If you try to give a "clever" answer at this point rather than collaborating with the interviewer, it's likely to give a bad impression. A good interview process isn't just looking for people who are strong programmers, it's looking for people who are good engineers - and good engineers are people who collaborate well rather than trying to prove a point at the first available opportunity.
It's not the point. At this point the interviewer isn't asking whether you can ship something, he's asking you whether you understand code or not. You need to fully comprehend what you're shipping, whether you imported it from a tested library or you built it yourself.
You should have seen the shambolic mess of a Python script I inherited from a colleague. The script was doing bash calls, to call itself with different arguments. Functions generating functions, not because of any high level of abstraction, but because she didn't know how to write a module. The code inside was more complex than fizzbuzz, but the way it was shipped was beyond terrible.
Coding something like fizbuzz is usually day one of a programming course. Using modules maybe day 2 or 3? I would see it as a sign of a more mature developer.
That's exactly the point of fizzbuzz: weed out those who clearly can't code. Only when the fizzbuzz test is passed can we start going into interesting parts, where an interviewer can assess whether you're a (truly) mature developer.
Yes, I read the entire article, maybe I didn't articulate correctly, my point is, given you are in an interview and somebody asks you "Show me factorial please", wouldn't be a smarter move to import a module that something already wrote and just use it?
Again, I read the entire article and saw he ended up with a generic solution.
I think HIS point was about premature abstraction and YAGNI. The article was just examples of terrible abstractions... they were intentionally terrible. The "generic solution" was an example of what NOT to do.
The article wasn't interview advice, it was advice about avoiding premature abstraction.
The goal is getting the job, or being a smart ass?
As an interviewer, I'll put this one to bed. Pick up the white-board marker and start writing.
The intern can look up libraries; I want to see if you can understand what we'd be looking for in those libraries. If you can't implement and discuss a simple version of it, odds are that you cannot.
If during this process you talk about how you'd be starting a build/buy research cycle at certain points and what that'd look like, as we spec out the problem and build a prototype, that wouldn't be misplaced.
If you try to give a "clever" answer at this point rather than collaborating with the interviewer, it's likely to give a bad impression. A good interview process isn't just looking for people who are strong programmers, it's looking for people who are good engineers - and good engineers are people who collaborate well rather than trying to prove a point at the first available opportunity.