Are questions about the Singleton pattern a good way to evaluate a job applicant?

Question

I have been recently assigned the task of taking interviews in my company. I have been taking interviews of developers and engineers with atleast 5-6 years of experience.

One of my favorite question is to ask whether they have used any kind of patterns...and the default answer has always been "Singleton Pattern"

Since it is the most simple pattern, I always end up asking them to write a code for it, and only 1-2 out of 5 end up getting it right, but get confused when I start asking about thread safety, double-checked locking issues and etc..

My questions are:

1. Is it fair on my part to expect a person with 5-6+ years of experience to know how to write a Singleton pattern?
2. Is it fair on my part to judge a person upon their ability to code a Singleton class?

EDIT: Some clarifications. - When I ask if they know anything about design patterns, I would like to know what kind of GoF patterns they have used, why they have used and how they have used them. And with 5-6 years of development experience, I would expect a person to know about GoF patterns...correct?
- The first answer which everyone say when I ask about patterns is "I have used and written Singleton Classes". Singletons are at the cusp of being declared an anti-pattern...with asking them to write about it, I try to gauge 1. If they can code, 2. If they can code what they claim they could code, 3. Tell me the problems with Singleton...

Do I sound more reasonable now? :)

Answer 1

Yes, it is fair to expect them to know how to write a singleton, in particular if they claim they have used it.

Do they need to code singletons where you work? If the answer is "never", then no, it is not fair.

You should ask them things that you expect them to do in the line of work. Asking theoretical questions that have no bearing on the real work expected from them is in my opinion a bad way to interview someone for their technical fit.

I would ask why they used a singleton and whether it was really needed...

Answer 2

Well, you've gotten a bunch of answers from folks who don't think design patterns are all that useful. I, on the other hand, find that patterns are in fact very useful as short hand for solutions. If you can simply indicate that you want a visitor here or a strategy there, you've expedited your communication in a big way.

That said, the singleton question is a poor one--simply because it's become the standard design pattern interview question and is all over the web as such. Someone who can answer the question hasn't proved much (although if they can't, they're unprepared to say the least). I'd rather ask about a USEFUL pattern.

Answer 3

While there is a religious war over whether using a singleton is appropriate or not, if you were to assume that using a singleton is acceptable then I still disagree with the premise of writing a "thread-safe" singleton instance method as being necessary. Which by your post seems to be your gauge for if a person knows how to implement one correctly or not.

I am having a very hard time thinking of a situation where a singleton is used that it isn't created at application startup and it doesn't remain the same instance throughout the life of the application. In that case there is no need for thread safety in retrieving the instance. So all you are doing by creating a thread-safe singleton is needlessly using up processing cycles. I'm sure there are some special cases where it is appropriate, but for the other 99.99% of the time people use singletons, there is no need for thread safety in retrieving the instance. Now making method calls on the singleton instance is another topic entirely. Thus, I don't see the relevance in your asking your thread-safe singleton questions unless those people read the articles that you have read or you are trying to assess the person's understanding of multithreading/processing issues in general.

Answer 4

I would say no. I don't really know anything about implementing the Singleton pattern, because it's a pattern that I would never, ever implement. Would you also ask me to implement goto error handling? Or how about manually implementing multiple inheritance, or exceptions? You're talking about the implementation of something that should never be implemented (in the average programming job, of course- you'd have to implement exceptions if you're writing a compiler). Therefore, you're only talking about experience doing bad things. I'm not ashamed to admit it- I wouldn't want to work for an employer who wants me to have experience doing bad things. You should ask about implementing patterns that add value to the code base, not remove value from the code base.

On top of that, a candidate's ability to implement various patterns isn't really that helpful. You can Google double-checked locking. Even if you can't, when you find out there's a problem, you can just go back and re-implement it. You can never design it back out because the design is fundamentally wrong. The important skills are whether or not your candidate knows that Singletons are bad, and when to use a Factory, or any other pattern.

Answer 5

Yes, Absolutely...

...if your company manufactures singletons!

Otherwise... focusing on a single-point concept in an interview is unlikely to reveal much about the capabilities of the applicant.

If you're interviewing for an intermediate position, are design patterns even relevant to the scope of work? Is your code base riddled with design patterns? Are you trying to find out if the applicant has... read a book? Or applied the techniques?

Why not focus on iterators instead? Or lambda expressions? Or the HAVING clause in SQL?

Frankly if I was in an interview where the interviewer seemed to be obsessed with singletons, I would be afraid, very afraid to work there.

[Don't be lazy, conduct a proper technical interview!]

Answer 6

If they bring up the concept, then I say that it is definitely fair game. You want someone who is honest about what they can actually get done. At the same time, being able to write code that follows the singleton pattern specifically should not be a requirement for every position. Singleton is not even used that often in an appropriate context.

One of my favorite question is to ask whether they have used any kind of patterns...

I am assuming you mean GoF patterns specifically. Personally, I care a lot less about whether or not someone knows the details of a specific pattern, and more about if they can solve a problem on the fly that does not readily fit into any sort of cookie-cutter pattern. It does not matter if they can solve a problem that already has a clear solution that they happen to remember, which is the basic nature of these sorts of questions.

Bottom line: Should someone with that much experience be able to explain and implement a singleton? Yes. Does it actually prove that the person is a good fit? No. I have seen too people who can talk your ear off about the abstract factory pattern, but cannot seem to churn out some basic CRUD code to put any value on this metric.

Answer 7

In my opinion, the ability to write a good implementation of a singleton is not something you can reasonably expect from a 5-6 year programmer. The ability to write a singleton that is reasonably good is what I expect.

Also, if I asked somebody to demonstrate a singleton pattern and they said something like "I don't implement singletons, instead I use a dependancy injection framework so I don't worry about stuff like that" or "I have not written a singleton in years (if ever). I'd do a google search before attempting it." I would score them as passing on the question.

I suspect that you would be better off asking your candidates to write a fizzbuzz solution. If they failed that, end the interview and move on to the next candidate.

Answer 8

Would the candidate get extra points for pointing out that the use of singletons is controversial? Here is one of many articles on the subject.