Tuesday, 2 September 2014

Why should we not ask about Design patterns in an interview?

There is a famous book "Design Patterns: Elements of Reusable Object-Oriented Software" they have covered a number of classic object-oriented design patterns and also have covered some basic design concepts as well. It's a good book…
But what people in the software industry have done with it is beyond preposterous. It’s not a stop shop to write code this way. It's not a recipe book to be followed slavishly like some kind of paint by number template.
Interviewers always ask if you know design patterns. Job descriptions list "Familiarity with design patterns" as if it is some kind of secret rare knowledge only real programmers know.
Anyone who has been into proper programming over any length of time will accumulate "patterns": things you did in the past that worked, ideas you got from colleagues or from the internet, basically anything that was worth remembering that seemed to be useful. Everyone's experience is different but it makes up the toolbox you use in your daily work. Your approach to solving problems, how you test or debug, how you think about structure and design, your personal process; all sorts of things make up your "pattern". These are the things that you offer to an employer, in whatever shape or form it may be.
Yet people insist on you naming a design pattern in interviews, like it's a secret handshake, or asking a carpenter if they know any kinds of wood. What does it prove? Bloody hell…Nothing.
Programming is not coding by numbers or simply cobbling known patterns together. Today I will write a flyweight pattern and then add some strategy and maybe a proxy which goes well with a nice Chianti and some Fava beans.
Mozart composed music in the style of the period he lived in, he knew what people expected, he understood how to craft excellent music that people would want to listen to, and he definitely knew all the things only bad composers did. He did not write music by filling in blanks in some preconceived template even if the music of the time was highly formulaic: he created music people still listen to today because his patterns were all internalized and he knew how to compose within, and also violate, those formulas without resorting to stringing together simplistic bits of music. He knew all the mundane basics but that didn't drive his compositions.
Programming likewise isn't a bag into which you pour some things you read in a blog. It is an aggregation of your experiences, successes and failures, experiments and deliveries. Like any craft you discover things that work, ideas that have merit, and yes patterns that are worth reusing.
Looking at a set of canned design patterns as something independent and meaningful in all situations isn't craft, it is paint by numbers. It is a tool like anything else. Programming isn't some task that you keep on doing that you’ve mugged up from a book, it’s a continuous learning procedure where every day you make decisions on what to write and how to design or structure the code in a continuous basis. The set of patterns from the book are a useful collection but knowing what they. So stop trying to memorize those patterns!
Given that languages today are often functional or hybrid types, design patterns may be entirely irrelevant for many people. Today having a broader knowledge of how to use these types of languages and being willing to learn how to use them effectively is way more useful than remembering a static set of patterns or as a matter of fact a static set of anything. Programming these days is constantly changing, and we are coming to an age where anything written ten days ago may be partially or even completely pointless today.
So stop asking candidates if they have worked on any design pattern. The answer is always "Singleton"!!!

No comments:

Post a Comment