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.

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.

You actually demonstrate one use of this question in your edit, where you fail to design a workable model.

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; }
}

var parkingLot = new ParkingLot();
var v1 = new Vehicle();
v1.Slot = parkingLot.GetEmptySlots()[0];
parkingLot.Vehicle = v1; // WHAT!??

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 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!

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.

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

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.

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.