Because in the precious few hours they have to devote to "pure learning", when between jobs -- they're only motivated to hunker down and bone up the only thing that really matters: the latest tips 'n' tricks for passing all those fun programming quizzes (and the occasional "culture fit" question or two) that are the mainstay of the modern interview process.
Designing real, usable, maintainable ... software? That's much more difficult to "test" for.
Is it though? I give an interview question where I present a spec to be implemented. There's no algorithmic trick, but you do have to know to watch out for common problems (end of array conditions, etc). Sadly though we hired someone against my vociferous objection that failed my question in the worst way - he ditched the spec, attempted a complicated solution, and proudly asserted that "it works" at the end of the interview, because it passed the four test cases that I wrote as examples. I couldn't identify the bug by eye and in fact had to write a property testing framework to identify the bug. On the plus side, I now have a property testing framework for my interview question.
If you're doing your design in the language, you're doing it wrong. (Yes, you have to design something that you can implement in the language. But no, you should not be thinking in the language while you are doing design.)
Cannot be anything but a joke. The problem is simple, the solution requires 10 lines. There is no reason, absolutly none, to create an interface for a such simple problem.
I guess it's because I haven't worked on a really massive project with lots of other people, but I've never really needed to "design" software. Sure, sometimes I'll stop for a minute to think about the next thing I'm going to write and how it slots into the existing parts, but for the most part my programs grow organically. They start from a small kernel, parts of them grow and are branched off (B-tree style) into new files and subdirectories, and soon enough the whole thing is complete, or at least as complete as I need it to be for the moment.
The best experiences I've had programming are with languages and tooling that make this organic growth and splitting process as painless as possible (Rust in particular is really strong in this aspect). Doing such a thing from the top down (as with Java, where you have to be very thorough with your design patterns and UML diagrams and whatnot) seems unnecessarily difficult and restrictive.
Designing from top down may help you a bit when you already have a mental model that you'd wish to convey in written form rather quickly, otherwise risking to loose sight of it when you get into details. UML helped me write down ideas (mostly communication flows and other behavior related aspects, not class diagrams), but I can understand why one may feel restricted when that's not necessary. Growing organically has its benefits for sure (is more fun, at least), but I also had more than one case of reconciling diverging/incompatible parts of a system simply because I went ahead of myself there with improvements on the go. Wasting time on that under deadlines is less fun.
What's the point of wrapping an algorithm in strategy, when there is no reuse, nor any need to exchange algorithm?
And more. Why FizzBuzz(15), Buzz(5), Fizz(3); in enum and not in the constructor?
Why "mod" attribute, when the rest of the code doesn't use shortened words? It should be modulo.
Why FizzBuzzOperator when FizzBuzzStrategy's initialization is that easy? Also, again there's no requirement for reusability.
The code here is a classic example of why people make jokes about (usually in J2EE) overengineering solutions where even FizzBuzz will be designed for 1000MD-average-task-size scale.
Surely someone needs to mention FizzBuzzEnterpriseEdition [1],
which is clearly the best resource in this domain? Don't ignore the issues, true gold in there :)
24 comments
[ 3.1 ms ] story [ 64.2 ms ] threadBecause in the precious few hours they have to devote to "pure learning", when between jobs -- they're only motivated to hunker down and bone up the only thing that really matters: the latest tips 'n' tricks for passing all those fun programming quizzes (and the occasional "culture fit" question or two) that are the mainstay of the modern interview process.
Designing real, usable, maintainable ... software? That's much more difficult to "test" for.
The best experiences I've had programming are with languages and tooling that make this organic growth and splitting process as painless as possible (Rust in particular is really strong in this aspect). Doing such a thing from the top down (as with Java, where you have to be very thorough with your design patterns and UML diagrams and whatnot) seems unnecessarily difficult and restrictive.
What's the point of wrapping an algorithm in strategy, when there is no reuse, nor any need to exchange algorithm?
And more. Why FizzBuzz(15), Buzz(5), Fizz(3); in enum and not in the constructor?
Why "mod" attribute, when the rest of the code doesn't use shortened words? It should be modulo.
Why FizzBuzzOperator when FizzBuzzStrategy's initialization is that easy? Also, again there's no requirement for reusability.
The code here is a classic example of why people make jokes about (usually in J2EE) overengineering solutions where even FizzBuzz will be designed for 1000MD-average-task-size scale.
I have switched to Clojure for good. Our FizzBuzzes are oneliners http://www.learningclojure.com/2014/05/fizz-buzz-interview-q...
[1] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...