Now would you consider a smarter move to do the following in an interview:
- gem install your-fizzbuzz-package
- require 'your-fizzbuzz-package'
- puts FizzBuzz.range(1..100)
?
My point being why reinvent the wheel.
- gem install your-fizzbuzz-package
- require 'your-fizzbuzz-package'
- puts FizzBuzz.range(1..100)
?
My point being why reinvent the wheel.
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.
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.
Again, I read the entire article and saw he ended up with a generic solution.
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.