OO Design related questions in technical interviews

Question

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.

1. 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.
2. 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.
3. 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?

public class ParkingLot
{
   IVehicle Vehicle {set; get;}

   List<Slot> GetEmptySlots() { };
}

public class Vehicle : IVehicle
{
  Slot SlotNum {set; get;}
}

public class Slot
{
  int Row {set; get;}
  int Column {set; get; }
}

Answer 1

1. 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.

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

3. 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.

Answer 2

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!

Answer 3

1. 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.

2. 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.

3. 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.

Answer 4

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.

Answer 5

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:

class ParkingLot {
 boolean isFull();
 void carEntered();
 void carExited();
}

It satisfies one obvious use case.