Recently where I work we have been interviewing candidates for developer roles in our team. I have been involved in conducting some of these interviews and this has been causing me to reflect on other interviews I have been involved in, both as candidate and interviewer.
Most of the candidates that I have seen, both recently and over the years, have been fairly strong when it came to their knowledge of C#, SQL, and the .NET Framework. Where typically they fall down is in their understanding of the ways in which these tools can be used to create quality software.
An analogy that has been rolling around in my mind is that of the developer as a builder (I'm sure it's not original to me). Now I'm not a builder (as my g/f would happily attest I'm not even much good at DIY) but it strike me that a good builder has certain key areas of expertise.
A good builder will know the materials that are key to their trade. She will understand the differences between materials, such as between different types of wood, or cement, girders etc...
But there are another set of skills that are important for a builder to possess before you would want them to work for you. Beyond this knowledge of materials a good builder will also know the techniques required to build things from these materials that are fit for purpose.
To build a wall it's not enough to know about bricks and cement, its' important to also know at least some of the types of bond, that's to say the commonly accepted strategies for building the wall.
Of course, what I'm saying and the parallel is not new. The GoF design patterns were inspired by the work of Alexander in the field of architecture (not software). But it is, at least to my mind, a useful analogy. You wouldn't want a joiner (carpenter) that didn't know about types of joints, so why would you employ and trust a developer that didn't know (and couldn't discuss to some degree) some of the common design patterns, or fundamentals of object oriented development.
Posts
