OOP Design Problems in Interviews

Tag: oop , architecture Author: f22ab Date: 2013-09-29

I am a software developer with an experience of 2 years. I have been involved in design and development of several "small" modules.

I have been giving technical interviews lately. I have been asked to model design of various problems (for example Apple Genius Recommendation System etc). My expertise so far has been in developing relatively small modules. I want to mention how I approach design problems in hand :

(1) Recognize most essential use case.

(2) Do dynamic modelling (like collaboration diagram) to model system on basis of behavior

(3) Draw class diagram based on dynamic modelling done in step 2.

(4) Find out more use cases and iterate this process.

(5) When I am satisfied, I ask my peers to have a review it.

Though I've done fair enough in my projects so far, but interviewers are not pretty happy with this approach. Am I missing something as I am modelling for a big problem?

I'ld appreciate any pointers.

P.S. : I don't start with class diagram because I find very centralized architecture by doing so, while dynamic modelling helps me to decentralize the design.

That sounds fine, what did they actually say?
Thanks for reply. Their concern was I am not able to capture whole system. There are plenty essential features left even after few iterations. Should I have enumerated several use cases before designing for most essential use case? Though as per my understanding, during interview "approach" must be evaluated as system cannot be designed perfectly in 1 hour window.
No problem. You can't mention everything but I've added an answer that might help.

Best Answer

Did you have been asked for high level model (module) design or low level model design? Tackling into a big problem or domain for high level model design is a good idea, since for low level model design usually takes smaller problem or domain.

Usually the requirement / problem comes from the asker (user / interviewer) so we don't need to define the business requirement anymore. But we still need to design the system.

High Level Model

I'm not quite familiar with "Apple Genius Recommendation System" so I will use different problem analogy, that is the common Point Of Sales problem. For the high level model, you will define the entire system. Usually about:

  • ordering
  • commiting order
  • down payment
  • goods delivery
  • return

That is all high level model / module. If i'm being asked by how I can achieve the model, here is the steps that I will do:

  1. Define the standard use case between user and systems
  2. Pour the use cases to some collaborated diagram such as rich picture (or anything familiar)
  3. Define the exceptions use cases. If the exceptions can be defined easily, put it immediaetly to model. If not, mark the model with the case exceptions to be further discussed with business teams

    some use case exceptions can be changing committed order, changing committed order after down payment, cancelling payed order, goods out of stock, etc.

  4. Iterate the process. Usually step 3 can become step 1 (the exception can / will be another use case)

    for example the changing committed order can be a use case, since the change of occuring is high.

  5. When the 3rd is completed without additional use case exceptions (all use case has been handled), usually I add value-additional operations.

    Those operations can be notification (email / on-screen), historical data maintenance, reminder, error-handling, etc. Some operations can be another use case as well, so maybe you will need to iterate over to no.1.

    Some example maybe when you get error during down payment settlement, maybe you will need another use case to input the down payment data manually. Or maybe you will need to maintain reminder system in another system.

  6. Move to low level model

For additional information, I usually use state diagram for use cases / functionality, such as order state.

Low Level Model

Low level model will tackle smaller problem from high level. Easily said, you take one use case from high level (maybe ordering) and begin designing low level from it. Rather than defining class diagram first, I usually tackle with some form of sequence diagram. Here is some reasons why:

  1. sequence gives you concurrency view about getting the input, getting data, and giving response
  2. It gives good picture about relations with other systems such as database and webservice
  3. It can give you pictures about entry point or interface, in which can be very useful for basic architecture of your apps
  4. You can base your class diagram from it and find pitfalls easily during sequence design rather than class diagram

Then I will continue to system state diagram (editable, viewable, etc).

Last, I will continue to database design and class diagram.

Why is class diagram is in the last step?

Class diagram (and database design) is very dependent on your entire process. How concurrency occurs, notifications, outer system interactions, etc can affect the design of interfaces and class diagram. It is also the nearest design with your codebase.

Hope this help and this is entirely my experience and opinion.

comments:

Thank you Very Much. I had one interview today and I could do better this time with your advice.

Other Answer1

I think your approach could miss non-functional requirements. I would also mention how these can be captured.

comments:

Thank you Very Much. I had one interview today and I could do better this time with your advice.

Other Answer2

I would say that maybe you are expected to give a general perspective/overview and then go deeper. Like the example that you give "Apple Genius Recommendation System", I think that you should start with a general design (the big picture of the system), in order to determine a proper architecture for the system, for instance determine what components are needed, what protocols, etc. You need to identify components, connectors, and the configuration of theses. Then, you can start going in deep by suggesting patterns and tools. Finally, validate the architecture with scenarios, user cases, etc.

comments:

Thank you Very Much. I had one interview today and I could do better this time with your advice.

Other Answer3

From what I gather from your question is that you are asking for a "model" and not the "methodology" or "process" as you have outlined.

Hence, all they have to do is design (probably using UML) a scenario where Apple Genius Recommendation System can handle various problems. Tip, if this is the case, the main part of the design is to have an interface called Problem with core interface methods that's related to the problem. For example, getSeverity, getDescription, getDateReported, getDateSolved, etc. Naturally, they will need other classes that collaborate with this interface to complete the design.

I hope the above helps you.