Typical of many developer interviews is the technical portion - a section which presumably is designed to gauge the technical ability of the applicant to accomplish the tasks associated with the position being interviewed for. On the surface, a reasonable..nay...a completely necessary portion if one cares about any level of organizational success...in practice? The technical circus.
The problem is that the manner in which far too many organizations attempt to evaluate technical skill has little to no correlation to what actually makes a good/bad developer. You will all too often find this section of the interview littered with absurd questions such as the all too common fibonacci.
I once shot back to an interviewer after completing one of these circus tests - what makes a bad developer and how does this test help you identify said traits? It was a dear in headlights a very obvious realization (on their part - confirmation on mine) that there had been very little if any thought put into the limited time they had to judge whether an individual would be competent at completing the tasks at hand.
I'll answer my own question. I'll tell what in my experience makes a bad developer 100% of the time that I've encountered someone I would label as such. The list is short, sloppy, lack of discipline, inability to think beyond today or to realize that someone else other than themselves might have to change/update the code, realizing that THEY might have to one day update/change the code.
Tests such as the fibonacci sequence and the rest of these silly 'brain teaser' tests, are simply testing what I like to call the 'aha' or 'Eureka' moments of software development..how quickly you figure out 'how' to solve a specific problem. The thing is, software engineering isn't about the Eureka moment, it's everything that happens AFTER the eureka moment. Do you think clearly through the requirements and ensure that your solution properly solves all of them? Do you think through any/all potential edge cases and discuss with steak holders what the expected behavior is. Do you in your design display the coveted attribute of software that thinks about the future without designing for it. Is your solution not just code but functionally modular to an appropriate degree, allowing minimal interdependency and maximum maintainability?
This is what I want to know about a new developer and silly in person quizzes simply don't enable me to asses that - in fact the irony is that these 'tests' require a developer to do something that I generally discourage - start typing out a solution immediately without taking substantial time to let the requirements marinate and come up with a true production grade solution rather than some silly hack.
Any 'one hour' coding challenge is nothing more than technical hazing. You simply cannot meaningfully in a span of an hour start to finish possibly meaningfully gauge the technical chops of an individual.
I don't claim to have all the answers, but I do know there's a much more productive way to conduct technical interviews, one which a number of organizations are progressively adopting, one which enables organizations to get a much better glimpse into the developer's actual coding style and habits, one which much more closely resembles the actual software engineering work that we do. A simple mini-project such as this one that a previous director came up with, that allows you to see the developers approach to creating actual production grade software around specific constraints/requirements.
Upon completion of said project, you can (if it's completed to your satisfaction), then have them talk about their solution - what they were thinking, what assumptions (if any) were made, what the known limitations are etc. You can introduce changes to the requirements and see how they would handle a requirement change that conflicts with a fundamental assumption they made to some degree. This is just a much better approach to evaluating ability. Simpler, more comprehensive....but hey what do I know?