27

I'm preparing questions for job interviews for a senior development position. The job would include object oriented design, and the existing software uses design patterns, so I'd like to ask the candidates to explain a few design patterns they know, they've used, how they've used them, why they've used them and so on. However, in previous interviews when I asked senior developers with at least 5-10 years experience about design patterns, almost none ever heard of them. I think two out of twenty developers could name a single design pattern (Singleton and MVC, respectively).

So my question is: does it make sense to ask these questions? Or is this such an obscure subject that you cannot expect new hires to know them already?

Should a senior developer have prior experience with design patterns, or would you say that design patterns are such a simple topic that every decent developer can pick them up during training? If so, what questions would you ask instead to gauge their design abilities?

Add After reading the answers so far, I should give a few clarifications:

  • The job is for a .NET developer with experience in OOP/OOD
  • The existing code uses class names like IParameterGraphVisitor and IStorageFactory in many places
  • How do you ask people about their past experiences with OO designs they created, if they don't have the vocabulary to explain their designs? That's what I want to do, and all I can come up with is "please you draw the design/object hierarchy of your last project on the whiteboard".
Improve this question
14
  • 31
    Patterns are a transient artifact; that is, they appear through a good design. They are not "used". There's a reason the name is "pattern" and not "constraint" or "requirement". So, do you want someone with OO design experience, or someone with design pattern experience? The former is more likely to know more than buzzwords. Commented Mar 28, 2011 at 19:46
  • 6
    @Michael: Agree. There is a difference between knowing the names and being able to use the pattern. I've been raised on OO, but if you asked me to name some patterns and describe them I would not do well. I don't particularly care what industry has decided to call it, but I bet I've actually implemented most of the patterns you were expecting to be listed. Commented Mar 28, 2011 at 19:55
  • 18
    @Michael: I've always seen design patterns as a communication aid. It's much more efficient to say "this is a tree visitor" instead of "this is an abstract interface that will be passed to a function that will walk a tree and call a method through that interface so I can separate tree walking from the code that does the actual work". But if you know better ways to gauge design skills in an interview, please answer the question! That's what I'm looking for. Commented Mar 28, 2011 at 19:58
  • 3
    Perhaps a better approach would be to ask them how to solve a specific problem. I for one don't remember the names of all the design patterns but I know how to apply them and use them. as @Michael says, having experience and knowing buzzwords are two different things. Commented Mar 28, 2011 at 20:01
  • 4
    Knowing the design patterns well could in fact be a negative. Some architecture astronauts will only talk about design patterns, and will apply them vigorously, whether or not they make any sense. Commented Mar 28, 2011 at 20:32

18 Answers 18

Reset to default
76

Chances are they do know them. They just may not know them as 'design patterns'; ie, they may not be familiar with the academic terminology for such things. What you view as a 'state machine' might simply be a common sense approach to a problem to an older, more experienced programmer. I never paid much attention to 'design patterns', for example, but when I learned what a State Machine was, I had to laugh because I'd been doing that for years. Who knew I was such an academic? I always just considered it basic coding skill, and not a 'design pattern'.

The point is not assuming your experienced developers know the text-book terms for things; instead, ask them how they would structure classes, or how they would approach a task.

Improve this answer
15
  • 2
    +1 I'd been using those structures for sometime before Gang of Four came out so I always have trouble remembering the names they were given. Commented Mar 28, 2011 at 19:56
  • 13
    The pattern literature is, I think, pretty explicit about this sort of thing - patterns are not intended to substitute for design, they are intended to help communicate about design. (I'd say that helping communicate about design also helps the design itself, but I guess that's a different point.) Commented Mar 28, 2011 at 19:57
  • 5
    +1. That happens to me all the time. Awhile back I read the wiki article on "Dependency Injection" to find out why it seems so popular, only to find out it's a technique I've been using for years, but just never gave it a name. Same with "state machine". Commented Mar 28, 2011 at 20:02
  • 4
    Isn't it a reasonable expectation then for a senior developer to follow what's going on on the field, and adopt the widely used terminology? Patterns have been around for more than 15 years by now, so you can hardly even call them "new" anymore... Commented Mar 28, 2011 at 23:17
  • 3
    The point of design patterns was to provide a common language for software developers to talk to eachother about solutions to reoccurring problems. That's the point in learning design patterns. IMO, it shows a definate lack of dedication to the profession for them to not even bother to learn something that has been at the forefront of OO Software development for the last 17 years. I would certainly have reservations about anyone who can't name and understand some basic patterns. Didn't they care that they were not able to understand people's conversations because they don't know the names? Commented Mar 29, 2011 at 17:06
26

Your expectation is quite reasonable for a senior OO developer. Anyone calling him/herself that without knowing Design Patterns just demonstrates that experience isn't brought automatically by the years passing by :-( Sure there are lots of developers out there having spent years or even decades on the field, without ever hearing about design patterns - that just shows they weren't interested in learning new ideas, improving themselves and adopting best practices.

Should a senior developer have prior experience with design patterns, or would you say that design patterns are such a simple topic that every decent developer can pick them up during training?

IMO experience counts a lot. In theory, a decent developer can read upon Design Patterns in a book, or even on Wikipedia, and understand the basic concept in 15 minutes. However, applying the concepts properly takes hard-earned experience. It is easy to get infatuated with patterns, trying to cram them into every possible piece of code, l'art pour l'art. It is also easy to dismiss them saying "patterns are no silver bullet, just use the simplest thing which could possibly work". Finding the middle ground between the two extremes by learning when and how to use patterns to solve real problems, and when not to use them, takes years of experience.

what questions would you ask instead to gauge their design abilities?

In concert with the above, I would only add these questions to your list:

  • What are the drawbacks of design patterns (in general, and of the ones they explicitly mention)?
  • When not to use them, and why?

Update

@GrandmasterB has a good point in that some developers may be using specific design patterns without knowing their name. In a way he is right in that this is a terminology/communication question. However, the other side of the coin is that it is indeed a terminology/communication question :-) That is, one of the main benefits of Design Patterns is to give a common vocabulary to developers, enormously improving communication. (Try to explain the basic idea of Adapter without using the word itself, or its synonyms "wrapper" et al!) So however talented and knowledgeable a candidate may be, without knowing the widely accepted terminology (s)he will introduce a communication problem in your team.

Improve this answer
5
  • 2
    I don't know how generally true this is, but I'd also say that using design patterns can introduce communications problems. For example, when something you're doing is similar to a well-known pattern, but not exactly like it, then the knowledge of the existing pattern may obscure your local differences. Or when the developers on your team don't completely understand the pattern, then they may use the pattern name in an idiosyncratic way. Commented Mar 28, 2011 at 22:21
  • 1
    @Aidan, good point there, albeit to me this is misusing patterns. That's one more way in which experience and practice is indispensable, i.e. in differentiating between variants of the same pattern vs two different patterns. Commented Mar 28, 2011 at 23:08
  • 1
    +1, anyone calling themselves a senior .NET dev should be able to name off at least a couple explicit pattern names, and their use. It's a matter of communication and toolbox, if nothing else. Commented Mar 29, 2011 at 1:27
  • I've read it 3 times and still can't tell if the first paragraph is sarcasm or not Commented Mar 28, 2012 at 16:11
  • @briddums, what makes you think it's sarcasm? Commented Mar 28, 2012 at 16:41
12

In an interview you should ask what is critical for the candidate to know in order to do the job.

If they have to know the names of the patterns as they are from Gang of Four then that is a valid requirement.

If, on the other hand you want them to display appropriate working knowledge of program architecture I think your better off given them a problem and asking them how the would structure the code. If they give you the appropriate pattern solution then you have proof they know it, regardless of the name used.

Whenever I interview for Senior positions they tend to be more "practical" than Q&A. I want a clear demonstration of skill and comfort in programming. I also want a firm foundation in CS concepts which means more general skills of how to apply concepts like encapsulation, algorithms, coupling/cohesion, etc. Experience and familiarity in multiple languages and paradigms.

Improve this answer
10

A senior developer? Definitely. A junior should. I'm 15, have no formal education on the subject and even I understand them. It is not only reasonable to expect that they know them, it would be unacceptable if they didn't. Assuming they know something about object oriented programming that is, which they most likely do.

Improve this answer
3
  • 14
    To be fair. OO only became one of the dominant methodologies during your life time. There are a number of people that got their degrees before Java was the language used in college. There are lots of people that don't live in the OO world. Commented Mar 28, 2011 at 20:03
  • 2
    @unholysampler: of course, but I think it is an OOP position which is being talked about Commented Mar 28, 2011 at 20:09
  • 2
    @unholysampler: I wish I lived in that time.. I can't stand seeing nothing but Java at uni <_< Commented Mar 29, 2011 at 12:44
4

Depends on the area of their expertise. I wouldn't expect an embedded C developer to know much about design patterns. If we are talking about a Java or .NET developer, they should be familiar with design patterns, and especially how to not get too carried away with them.

Improve this answer
2
  • 2
    +1 for not getting too carried away with design patters :) Commented Mar 28, 2011 at 19:52
  • Good point. Added a clarification to the question. It's for .NET developer, with project experience in at least on OO programming language. Commented Mar 28, 2011 at 20:28
4

Assuming you're seeking seniority in OOP the answer is defintely yes. Design patterns are lexicon of the OOP language.

Furthermore it is nowadays unreasonable that a decent OOP programmer with 10 year of experience cannot name a design pattern, being design patterns widely adopted in standard APIs, libraries and development frameworks.

It has been years now I've been asking this question during interviews and it is a showstopper when the candidate does not provide satisfying answers on the topic.

Improve this answer
3

Yes, but you should probably elicit their understanding by asking design questions rather than asking people to enumerate the design patterns they've heard of. I'm pretty comfortable with patterns described in PoEAA, GoF and even some functional programming patterns and I still don't think you'd learn much more about my approach to solving problems by asking me to name some patterns.

Given a question like "design me a text editor" with follow-ups like, "How are you going to support embedded objects like images? Bold and italic? Undo?" You'd probably eventually hear enough to recognize the command pattern, the composite pattern, the memento pattern, and a few others with even a short conversation.

Design patterns were discovered and then described so that we'd have a common language with which to communicate design decisions.

I've unfortunately worked for someone for whom every use of a design pattern had to be explained and justified, not because of due diligence, but because he simply didn't know them. That's not fun. But most serious developers have, by accident or design, learned the names of the most commonly used OO patterns, if nothing else, and most enterprise application developers worth their salt at least know something about the most common PoEAA patterns.

Improve this answer
0
3

Reasonable. Definitly. Necessary. No

I ask potential candidates if they know design patterns. Its just one of several criteria to be weighed as a whole. Do not overlook the total picture.

Yes, many developers unknowingly use some design patterns, no doubt.

That is not why I ask the question.

It is important to know that I can communicate quickly and effectively with another developer. I do not want to spend 20 minutes on a whiteboard explaining a state machine only to find that they "used it before, but never knew what to call it". This is not productive.

They also help in the refactoring process. Glancing through code one might haphazardly implement some form of a factory pattern, but the GoF factory pattern has withstood the test of time. That's why its the factory pattern, not YET ANOTHER fp (reinventing the wheel is not preferable, Joel on software has plenty on the disadvantages of doing so).

A team that uses and recognizes the importance of design patterns increases communication and productivity. If your team, as a unit, does not use dp's then they lose their relevance.

Improve this answer
2

Speaking from my own experience, I ignored design patters for quite a while. I knew that they existed, I just never read about them. Once I finally bit the bullet, I realized that I had been using design pattern all along and I just didn't realize it or I didn't know that my design solutions actually had a common name.

I would be more inclined to come up with a set of problems where a particular design pattern fits the solution well and see the developer comes up with something similar to the pattern. If they do, great. I might be even more inclined to hire a developer that used design patterns unknowing as I see a lot of developers that have design pattern knowledge trying to fit a solution to a pattern when it is not appropriate rather than realizing a particular pattern happens to solve the problem well.

Improve this answer
2

I think a better question would be: Given a name of a pattern, and a description of the pattern, for example a Factory Pattern from the Gang of Four book, the candidate should be able to come up with a scenario where the pattern would be a reasonable approach.

Improve this answer
1

There are developers with 5-10 yearsw of experience and there are senior developers. They are not the same thing at all. Yes if you are hiring at the senior level and you expect people to know and use design patterns then I would not hire a senior person who was not familiar with them. That would be like hiring a database specialist who didn't understand left joins. That's pretty basic stuff for a true senior developer. I probably would hire a junior person though.

Improve this answer
1

Yes indeed they should be familiar with the term, and should even be able to name a few of the patterns - but don't make the mistake of confusing theoretical knowledge with experience.

There are many people who before an interview will brush up on design patterns, and can rattle them off with a brief description - but that is just the theory. It is a real senior developer who can spot when to use one, or without knowledge of a formal pattern would solve the problem in a classic design pattern way.

The best way to check is let them design something in front of you and ask probing questions.. a senior developer is someone who can think naturally at the abstraction level. These are the people who "create" the design patterns.

Like the class Peopleware which talks about hiring a juggler without asking them to juggle - just because they say they can does not mean much.. try them out.

Improve this answer
2
  • Could you give an example problem? All the design examples I can come up with are either so simple that no interesting design is needed, or so construed that it's hard to see why one solution would be better than another, or so complex they can't be solved in an interview. Commented Mar 28, 2011 at 20:05
  • It does not really matter what it is, it could be something as simple as "Design me a coin toss game". Wait to see what they do with it. Then add a requirement to explore what you are interested in eg: How can you change this to make it : testable | portable | used as a service | usable for different UI's | run on the web... etc Commented Mar 29, 2011 at 10:29
0

As already stated, I also believe that it is OK if they don't remember buzzwords by heart. But since this is a senior position they should know when to apply a pattern for solving a problem optimally instead of using worst solutions. Thus, give them a problem that should be solved using a pattern (for example, how to create an object without hard-coding its class, how to access the elements of an object without having details about its implementation, etc.) and see how they will attack it.

Improve this answer
0

Definitely they ought to know the patterns, but not necessarily the buzzwords.

For example MVC has many very similar alternatives like PAC, 3-tier. Few years ago another popular buzzword for MVC was "Model 2". I actually know very good developers who know that pattern perfectly, but didn't know that current buzzword for it is MVC.

Improve this answer
0

Very simply: if you are using them then you need to ask your candidates. If they do know patterns, then it should add a few plus points; but not knowing shouldnt necessarily debar them, especially if they show good OOD skills. Developers who have been in maintainance projects are unlikely to know much about design patterns as compared to those who have been into designing them. it also depends on whether they have been taught desing patterns in college. In my experience it is unlikely that they will. Most universities and private courses teach you OOP but not OOD. Chances that they will have studied DP are even less.

Personally, I hadnt studied DP until my project required me too. Even then I found that I had used a few of the patterns, at least in a similar manner if not in the exact fashion described in the book. I was surprised to know that they were codified. So look for good design skills if they dont know DP. If they know DP it is probable that they are good in design but still test them. They may have just head some buzz word about DP or found out from some insider and just studied a few patterns without having applied them.

Improve this answer
0

It's reasonable for you to expect people who apply for a job with you to know (or to learn) the things that are needed in your job slot, regardless of whether they are industry standard or not. Otherwise you condemn yourself to mediocrity. But beware of making some knowledge (or skill) a job requirement, if it isn't really needed.

Let's say you have two candidates with roughly similar backgrounds, and one is able to tell you about design patterns, and the other is not. What will that tell you about how they are going to perform on the job?

You say the existing software uses design patterns. Is that an advantage? If so, how? Is it your goal that new software written conform to existing patterns, or that new patterns be introduced? Why?

Improve this answer
0

I can think of a senior developer who does not know about design patterns in the following situation:

  1. There are only one book about design patterns. It's the book that made them popular in the first place. If the person has not read this one book, it's possible they do not know about design patterns, or might have heard about them, but do not properly know what they are for
  2. Instead, they would have to know something like uml....
  3. Finding good information about design patterns from the internet is not easy. You're very lucky if you hit the correct web page that has good design patterns knowledge. Simply coming to software after 1995 might make a person not know about design patterns book, because the book is old.
Improve this answer
-2

Why should any developer in a non-OO environment know about OO design patterns? I've worked in shops doing only Cobol, only PL/SQL, only Progress 4GL, etc.. OO design principles are irrelevant there, I'd expect the seniors in those environments to have relevant knowledge to those environments, not to OO design patterns.

Being able to mindlessly quote from a pattern catalogue also doesn't make you a good developer (in fact, in my experience, it produces some of the worst pieces of code I've ever seen). Yet that's what you expect to be the mark of a "senior developer". I've been working the industry for 15 years, yet don't ask me to draw a pattern diagram. I've never given it much time, I don't need to. I've gained enough experience to find what works without putting a specific name to it, and if I need the formal definition I know where to look it up (and yes, I do have the reference books in my personal library). That's the mark of the experienced developer, not rote knowledge gained from cramming some school books.

Improve this answer
4
  • 2
    I don't see the relevance for the question. I'm not interviewing for a Cobol developer position and I'm definitely not going to ask people to "mindlessly quote rote knowledge". Your only point seems to be that you don't know design patterns. Commented Mar 29, 2011 at 9:18
  • unix/linux is written in 'C', it is full of OO Patterns, and many more that in the gof book. Commented Mar 29, 2011 at 9:53
  • 2
    "I've gained enough experience to find what works without putting a specific name to it." Part of the value of design patterns IS the name. So you can say "let's use a Factory pattern" and your colleague immediately knows what you mean. If you both know how to do that sort of thing, but neither of you has a name for it, you have to spend a lot more time explaining before the other person says, "oh, THAT." And again, if the code contains a WidgetFactory, someone who knows the Factory pattern understands what that's for. Commented Mar 29, 2011 at 15:23
  • I agree with Nathan. The point of design patterns is to put a name to a common solution. There are very few design patterns that people would not have thought of on their own. The benefit is assigning a commonly accepted name so you can communicate with other developers without going into gory details. So your opinion that you don't need to put a name to a pattern because you are already using them is akin to your saying that communication is not important. Try going on an interview and make the "communication is not important" statement and see how many job offers you get. Commented Mar 29, 2011 at 17:15

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.