I discovered something spectacular and I must write about it.
Calling a developer an Architect is something of a badge of glory. It essentially means "this guy knows so many languages and techniques that he should be the final say in planning projects". Developers who work with an architect tend to refer to his judgement whenever something new-to-them comes up.
This title is associated with an action: Architecting Code--but architecting code is simple. Any programmer who's written even the simplest "Hello World" app from scratch has architected code. The idea behind an Architect is that he architects code well. He plans the code in such a way that it works, is easy to maintain and is easy to extend--at least in theory.
But what about the non-architects? Every other developer in the office is just that--a developer. They aren't stepping into a clean room where they are free to wave their paintbrush across the canvas. They've walked into what is generally described as a mess of spaghetti code. Someone architected their project for them and their just trying not to mess it up too bad. The truth is, the role of a maintenance developer is nothing like that of an architect.
And this is where my enlightenment laid. A developer interview is a series of Architect questions. The more arbitrarily picked questions you get right about relatively relevant languages and techniques, the better developer they think you are. In reality, the best developers (not architects) I've worked with probably couldn't name the technique they were using or recite the SOLID principles off the top of their heads. But they were brilliant problem solvers, and they were great at matching their code to the code style already there. These sorts of coders are an architect's dream. That's the sort of skill we should be interviewing for--not asking them to list the steps in an ASP.NET page lifecycle.