Theoretical architects

time to read 3 min | 547 words

This is another response to The Daily WTF post. This time, I wanted to talk about the last part of the post, the architect reply interviews. Here is how it starts:

Note: Based on my understanding, the purpose of these low-level programming questions is to draw out the participant’s knowledge and usage of reference materials and web knowledge-base searches to derive the answers, demonstrating his approach and thought process.  My role as IT Architect for the past 8.5+ years has been to focus on the bigger picture and higher-level architect and design issues that solve specific business problems, so I don’t know the answers to these specific programming questions off-hand...

At this point, I have alarms bells going all over my head. You can't be a successful architect if you don't know what is happening at the lowest levels. That is like a construction architect saying that they are not interested in validating the strength of a bridge because it impacts their "artistic sense".

I suggest that you will read the whole thing (doc format), it is interesting, in a bizarre way. I agree with the overall methodology that he uses (I had to stop to thing about how to solve the second question), but the actual result is alarming. My impression from that is Do Not Hire, Leech. Leech is a term I use for those people who can't code without hand holding and a group hug. I am willing to bet that this guy would not be able to pass the FizzBuzz test.

Here is another thing that spiked my ire, this comment to the post:

My view of the role of architect, because that is my job title, is that you do the important stuff as well as the high level stuff. The database schema is extremely important so you want to be involved with that, but the code to interface with it? Well I'd write some code so that the minions can use it as a basis for their code if they haven't done it before. Network code as well, unless you have an experienced minion you can trust. But do I want to code piles of business logic? Nope.

Sorry, that is the kind of attitude that will simply irks me to no end. The whole attitude is domineering and repulsive, but "do I want to code piles of business logic? Nope." And then expect the developers to do it? Why the hell are you writing piles of code in the first place?

I interview architects, and it really gets me that some of those guys actually think that coding is somehow beneath them. My expectation from an architect (and I should mention that I do mostly the technical verification side of it) is that they can discuss everything along the line from the high level architecture to the implementation details that can affect it. My favorite question in this regard is designing a grid, and the best interviewees were able to discuss making it fault tolerant and scalable at the high level and face issue in the Assembly.Load context.

Sorry, but if you don't code, you can't be an architect. There is not such thing as theoretical architects.

I feel better now that I let it out.