Why are we interviewing Developers by asking Architect questions?
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.
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.
Just this Monday I was in an interview that finished with me being given a practical programming test - given 45 minutes, a laptop with visual studio and a fake but relevant scenario, work through it as far as you can then walk somebody else through your code.
ReplyDeleteI enjoyed it, and the rationale for the mini code slam? Never hire a programmer you have not seen code.
I fall firmly into the maintenance programmer category; having worked for 5 years on help desk and another 5 years on SQL Server databases, I had a lot of time to pitch in on .NET code in large projects, refactoring and fixing bugs, and testing; not to mention writing a lot of my own tools.
ReplyDeleteI can’t often build something substantial from the ground up like a real programmer but I’m not without my uses, and that makes it hard to find jobs.
So imagine my surprise when I found myself out of work a few months ago and started applying, and found a few places that direly needed someone to take over maintenance and refactoring mode as a dual programmer + DBA. Except even though I flew through the interview process and received a lot of head nodding and agreement, I didn't end up getting them because I wasn't enough of “a real programmer”.
I think it comes down to a throwaway culture. In the past you wouldn’t have expected a fridge or washer repair person to know how to build one from the ground up; but currently you wouldn’t likely even hire one, you’d just throw your broken equipment away and buy a new one. Ditto for programming; every business thinks its codebase needs the most skilled hands possible… even if it's not skilled work and their stars are going to leave out of boredom a year later.
I did end up finding work elsewhere as a pure DBA,but I can’t help but feel those short-sighted companies missed out on something special.
You hit the nail on the head. Props to you for being a real world programmer and doing what it takes to keep the world running in spite of the stupidity and disrespect from the hiring community.
DeleteSad to hear that in this DevOps world...
DeleteI think you sorely misunderstand what "architecting code" is. No "hello world" program can be compared to architecture, any more than a lean-to shelter can be meaningfully compared to something as simple a house. Architecture is not about languages or "techniques." (What are those anyway? Data structures? Design patterns? Size/speed/power optimizations? Integrity, atomicity, or durability guarantees?)
ReplyDeleteArchitecture involves understanding the properties of materials, their strengths, weaknesses, and relationship to other materials. It also involves taking a set of desired outcomes and expectations an integrating them into a coherent whole. Architecture, in other words, involves more than merely constructing individual programs or components, and certainly much more than knowledge of the internal details of a particular tool (e.g. ASP.NET, which you mentioned).
When it comes to techniques, SOLID principles, etc., those are just things that experienced, professional developers should know. If you're an object-oriented programmer that can't meaningfully discuss SOLID (you don't have to have it memorized) and what it implies, you're not as experienced as you think you are. If you're a functional programmer and you can't meaningfully discuss the tradeoffs of immutability, again, you're not as experienced as you think you are.
Being a professional means that you are conversant in the terminology of your industry. It also means that you are aware of best practices and aware of developing trends in your field. In programming, a great many problems have already been solved, so being a professional programmer often means knowing how to find and use the solutions that are already available. Being able to do so without the assistance of an architect is a sign of maturity, something good interviewers are looking for.
Partially agree, but if there is an architect, a programmer gets an UML diagram and turns it to code.
DeleteOTOH SOLID and YAGNI mutually exclusive so the interviewee have to read mind on the interview, too, not only on the edge of the current trends.
I did not mean to downplay the work of architects--I spend almost all of my time doing it these days myself. I was instead trying to demonstrate how easily you can confuse the two job roles, especially if you're not in the field. There's certainly a lot more to say on the subject. I only posted this to remind myself of the differences so that I might think about things differently in the future. I am glad that it seems to have started a discussion--one which I think is sorely needed.
DeleteWith regard to that discussion, you're wrong. I will not further extend the house metaphor because this is about interview questions, a highly discussed topic in our industry at the moment.
These questions are so hard to come up with that we've seen everything from "Code this on a whiteboard" to "How many Jelly Beans are in a (theoretical) jar?" The current way of thinking simply isn't working. I believe that this is due to confusion about job roles.
In a hot dog factory you don't quiz your HR applicants about the proper way to slaughter a pig. A developer's job is similarly removed from that of an architect. Any benefit he gains from being able to know technique number 457 off the top of his head is negligible compared to the speed at which he can pick up something new--because let's face it, you're hiring developers because your technology stack is unique. If you were like everyone else everyone out there is trying to sell you a preconfigured tool.
The post emphasizes repeatedly that many questions are flat out arbitrary. Programming is not like academia or even like other scientific fields. There's such a high demand that companies are more interested in productivity, even over quality. Hiring a bug fixer is more akin to hiring a mechanic. He benefits from problem solving skills. The equivalent would be like asking him to define some technical terms related to wind resistance. While technically related to his field when working in a shop he gains little to no benefit from that knowledge. Those are, quite simply, the wrong questions to ask.
If you're going to discuss architecture, it would be helpful to actually understand where the term came from. This is why I brought up the house metaphor (in a perhaps misguided attempt to keep things simpler than they actually are), and precisely why it is relevant. Nothing that you have mentioned concretely to this point is relevant to architecture. Indeed, to even say "architected code" is a complete misnomer and implies that you don't understand the term as it is actually used in the industry. Code can be "designed," but it is not architected.
DeleteMaybe your choice of examples have just been too limited, but they don't remotely resemble the sorts of things I would ask when interviewing an architect. It might help if you provided say 5 or 6 complete examples (I know that's a fair amount of detail) so I can better understand what you're getting at.
To reiterate: when interviewing object-oriented programmers, their ability to intelligently discuss design patterns and principles (such as SOLID) is one measure of how competent they are. Their ability to explain the tradeoffs of composition vs inheritance is one measure of how competent they are. The list goes on: eager/lazy initialization and binding, dependency injection, loose coupling, futures, strong vs soft references, (in)appropriate use of generic types, etc. Architects care about these things too, but all of these things are clues about the skill of the programmer.
Programming is very much a scientific field: there are decades of scientific research that provide answers to most of the pressing concerns of everyday programming. I don't care how clever you are, if you don't know that that search algorithm you invented yourself (or copied out of convenience) is n-squared, I don't want you working for me. If you don't know what a state machine is, I'm going to assume you are pretty inexperienced, even if you're a good problem solver. If you're not regularly connecting your experience to the experience of other professional programmers and adapting to the shared terminology and nomenclature that is a part of the profession, you may be good at what you do, but you're not a professional, and I'm not likely to hire you.
This comment has been removed by the author.
DeleteThis post gives a more complete response than I could give in a comment
DeleteHR wants to hire as few IT employees as possible so they expect that a low priced programmer can do any task in the application development process up to and including project management. I can't count the number of department managers and project managers that offloaded their responsibilities onto me, because I was so "competent", so they could go home at 5:00 while I worked 12 hour days. "Work smarter, not harder" really means "Do more with less".
ReplyDeleteLately I find myself reminding people that competence is rare. I go so far as to say that 2% of the world is competent, and that this is across the spectrum of skills from brain surgeons to burger flippers. Mentioning that to your boss might remind them that they're demonstrating a lack of competence by offloading their work to you. Of course it might also come across as the veiled insult it is (in this case) and get you in trouble, so use with caution.
DeleteAs a PROGRAMMER YOU MUST KNOW SOLID http://www.developerhandbook.com/2014/09/19/8-things-every-net-developer-must-understand/
ReplyDeletesee my reply here: http://deltreey.blogspot.com/2015/02/programmers-dont-need-to-know-solid.html
Delete