Deutsch

Current Texts Comic Imprint Calendar Search PHP-Classes Container-Wizard main.s21

Categories

The FizzBuzz-Test

I just stumbled over the proposal for a FizzBuzz-Test to find good coding applicants when doing a job interview. In order to keep up my self-confidence, I tried it out and found the solution quickly enough - whew.

However, as good as the idea sounds, I find that approach a little bit too short sighted. The fact that someone does not immediately come up with a solution is not necessarily a proof that someone cannot write good code, as the author himself concedes. But he goes on saying that he who has difficulties with that will take longer to write it, which is bad.

I'd say that pretty much depends on the job. From my experience, I can tell that work that requires me to come up with a comparable solution is quite rare. Most of what I do is doing routine jobs: creating database tables, writing form definitions, defining links to some other part of an applications, create buttons, write validators, make things look nice ("can we have that font a little bit larger and that button more to the left"), search for bugs and, last but not least, anticipate and catch myriads of possible user wrongdoings, from entering "Twentyfour" as age to firing a cruise missile at the server to "see what happens".

From the perspective of the user, I consider it very bad design if, say, a form rejects my data but does not tell me what exactly I did wrong and how I can fix it. Users calling in and tell that the application failed with a white page and a long backtrace, because someone failed to validate the length of data submitted to input fields can cost more time than having to think two minutes longer on FizzBuzz. But more evil, applications should even fail silently, such as MySQL run in normal mode, which will just silently truncate whatever oversized data it gets - which will cost very much time if someone calls in and tells you that he cannot understand why some of his datasets have missing characters. Not mentioned the time to dispatch someone who then has to manually review all data.

Also, what good does it if someone can fork out a Dijkstra algorithm somewhat quickly, when his application is full of hardcoded paths, which will make it break as soon as I move it out of its cozy place in the filesystem, not to mention to port it to another platform? What is if even the most simple change requests turn into a nightmare digging through interwoven spaghetti code for hours because the whole architecture is broken? And about bugs: how quick will you take note of them, how long will it take to get the exact cause, how long will it take to fix them?

It is my theory that mankind as such still needs some time to gather experience on software development. Let's be honest: compared to, say, construction works, most of the concurrent software is utter rubbish (wouldn't even exclude my stuff). We're quite experienced on building houses and we have good and common measures for what is a good house, like "doesn't rain through the roof" or "was not blown away in the last storm". We have neither for software, not yet.

Comments

Please note: comments posted won't be visible immediately, as they will be checked for harmful content.