I've been attending quite a few interviews recently and have been asked by companies to answer "design a [insert model]" questions more than a few times.

Is this normal in the industry nowadays? I've been in the software world for more than two decades and have attended my share of interviews, but I am seeing this pattern in interviews emerge only recently.

I feel the question is very open ended. For example: I was asked to draw a class diagram to "Design a parking lot". I am not sure what level of detail the interviewer is expecting. This was in an online test where I was expected to attach a visio diagram, so I couldn't ask them what their expectations were.

Do you use these kind of questions in your interview process? Are they related to only class diagrams or do you also ask sequence, flowcharts and ERDs (ofcourse based on the nature of the position) Have they been effective in your hiring process?

* Edit for Kevin's response *

For example: A complete question could be "Design a parking lot management system that can be used to find vacant slots"

I can be done with 2 classes, ParkingLot and Slot or I could go on to add IVehicle and Vehicle and Car and Motorcycle classes. Where do I draw the line?

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

8 Answers
8

To some degree, yes. Anyone can recite syntax or copy/paste their way through a solution. We want to hire people who can solve problems.

They expect you to document the design sufficiently that they can understand it (and no more than that).

I ask people how they would solve XYZ problem, yes. Usually they just describe it verbally. I want to see if they ask questions to clarify requirements. I want to see how they communicate with other programmers. I want to see if they can think on their feet.

It has been helpful for me. I don't want code monkeys, I want software engineers.

I wasn't able to ask questions to clarify requirements as I was asked this as a part of an online test. I understand judging their communication skills may partly be the motive behind such a question. But does it really help understanding their analytical and design skills?
–
NickJan 13 '13 at 19:32

1

@nick - dunno. Online tests are of questionable benefit in the first place. In person, it provides some insight to design skills.
–
TelastynJan 13 '13 at 20:09

I find these questions rather silly. The true answer is "what are the use cases?" Without a use case, there is no need for any design. For example, here is a perfectly reasonable answer to the parking lot question:

Are you suggesting that these questions only have value when there are use cases associated with them? If there were use cases, how do you still determine the depth of what the interviewer is expecting. Please see edit**
–
NickJan 14 '13 at 16:05

2

I'm suggesting that before designing anything I would agree on use cases with the interviewer.
–
kevin clineJan 15 '13 at 6:52

That doesn't make it a silly question. On the contrary, it helps to discover whether a candidate is capable of clarifying vague requirements. That's an essential skill.
–
Cameron SkinnerFeb 21 '13 at 20:54

1

It's not silly if the interviewer knows that there is not enough information to start designing anything.
–
kevin clineFeb 23 '13 at 5:45

I agree with your answer & your comment above. There's always the possibility with this kind of question that the interviewer simply picked it up because he "liked it" without really realizing what it's for (asses the candidate's ability to demand the right/mandatory details to an incomplete/vague/generic problem). This in turn may lead to the interviewer treating any kind of follow-up question/clarification as a "bad approach" to the problem.
–
Shivan DragonFeb 4 '14 at 13:54

I have seen this type of interviews at least 12 years ago. It is the approach I have used for the last 6 years. Experience shows that it selects better candidates for the job than the ask 20 questions and give them a score out of 20 approach.

Again, I would make it very open ended too. The goal is to provide space for the candidate to demonstrate ability. Having a candidate that asked relevent questions at this stage would be a plus. As is a candidate making good assumptions, but flagging up that they were assumptions, and would need to be reviewed before implementation.

I do requre all potential employees to demonstrate the skills they need for the job at interview. For programmers, they will need to implement some code, and talk about their design for it. It is very effective for preventing bad hires, but be prepared for a 90% failure rate at interview.

Making the question open ended is fine as long as I can ask the interviewer intelligently for specific information. When I was asked to do this online, all I could do is guess the solution. Do you typically ask design questions when you are doing an interview face to face?
–
NickJan 13 '13 at 19:30

I tend to do both. A technical programming challenge, that they submit via email before they are invited to an interview, as well as different exercises face to face.
–
PtolemyJan 13 '13 at 19:46

These open challenges do not have a single correct answer, and anything else is wrong. Their goal is to identify people that have good thought processes, make sensible decisions and to assess how much support they will need to perform the job duties.
–
PtolemyJan 13 '13 at 19:50

Designing a small system is actually a very relevant exercise to ask in an interview. It shows your skills at coming up with a good software solution to a domain problem.

However, I find it strange to just ask to post a class diagram online with no human interaction :

They'll miss the essential - the reasoning behind the diagram and what led you to design things that way.

There's no "parapet" to stop the applicant from going too far. If you reflect a final implementation in the diagram, you'll probably have dozens of classes and an unreadable schema.

Being able to draw a UML class diagram is not really an essential skill, it's just one OO notation among others. The ability to create solid designs is.

In a live interview, the ideal steps I'd expect a candidate to take would be :

Talk about the problem with the recruiter and start expressing a basic solution verbally, asking questions and adjusting as the recruiter gives more precise needs.

Stand up and sketch an overall view of the system and how components could interact together. Might be the purest style of UML, might be just boxes and circles.

Write a test, either high level acceptance test or unit test for one of the components/classes.

Start writing the corresponding implementation.

Hopefully at some point the recruiter will have gathered enough information about the candidate's skills and call it a day. The goal is not to implement a full working solution (unless it's one of these unpaid service in disguise interviews).

I used to ask these - back when we created class diagrams for code generation. I still do on occasion, but not routinely. I like the question because it lets me see the person think.

It is intended to be open ended. That's ok. There isn't one right answer. I don't have an answer in my mind; I want to see where it leads. I think it's a better question to ask in person, not "email in answer." It's about communication, assumptions and interaction; not just an answer!

"I like the question because it lets me see the person think" -> What exactly do you look for when you are evaluating the person's thinking skills? Is it the speed at which they solve the problem? Is it the final solution? Is it how deep they go in creating classes, interfaces? Is it how they demonstrate how much they know the OOP concepts (inheritence, polymorphism etc)?
–
NickJan 13 '13 at 19:36

Are they methodical? Do they think of what might go wrong? Do they think of alternatives? Do they declare defeat at the odd question quickly? (I usually ask for something like a telephone, not an object most people have designed before?). I don't look for speed (unless someone takes 15 minutes before even starting to say anything!)
–
Jeanne BoyarskyJan 14 '13 at 0:08

The OOP questions are open-ended. There is no right or wrong answer, but there are some principles the interviewers expect to see (like using a constructor to initialize variables, keeping your methods small, using encapsulation/composition/polymorphism/inheritance when applicable, etc).

Always expect data structure, OOP, and database related questions in interviews, they are very common. Books like "cracking the coding interview" and "programming interviews exposed" can help you to prepare.

You also mention creating Car and Motorcycle classes, which doesn't make a lot of sense without further consideration. Your design isn't going to benefit any from having subclassed Vehicle. If you introduce Motorcycle without any behavioral differences to Vehicle, I'd consider it a fail.

If you didn't spot the single Vehicle problem, then we'd pretty much be done in a live interview. If you corrected that (possibly by making that a List<IVehicle>), I would use this as a starting point to look at evolution of your design. There's a reason the requirements are basic, and there's no well defined use cases - that's pretty much the way the world works.

I might throw the new requirement at you that "two motorcycles can park in one slot" to see how you'd evolve your design to handle it. Then maybe we have a conversation around concurrency (What if we have two entrances, and two cars pull up simultaneously - will your design fail? How? What can we do to fix it?). Other possible avenues to explore would be how to implement assigned parking, charging for parking, rates per row (maybe closer rows have to pay more), time limited parking and how to find offenders, etc., etc.

I would also consider your thought process around parking lots to be indicative of your general ability to intelligently analyze a problem. If you have to ask me for basic use cases and/or come up with oddball ones (like 2 for 1 specials on parking), I start to get mightily concerned that you've never actually used a parking lot before and that we're going to have a hard time communicating on anything slightly complicated.

I had been asked for coming out a design for a parking lot not too long ago. I wasn't given any use cases in the first place, but mentioned a couple later. I believe my design didn't fit what the interviewer's had in mind. I agree that any software design is only valid for a given use case. Back to this interview question, I believe that my interviewer didn't have any real world design experience. Those people believe that they know what they ask for. It is another story whether that is indeed true or not.