I've collected a bunch of interview questions like "Describe how you would design a photo album application", "Describe how you would design this particular feature of this particular website" (e.g. likes on Facebook, recommendation on Amazon, shopping cart, game of black jack). Then, what if there are millions of this thing? What would you change?

It looks like this is either expecting a database schema or a bunch of class definitions (or both?). I have learned about databases in school but I've never actually architected an application before and am having trouble knowing where to start, whether the designs I come up with are "good" and what I can change to make it scalable.

Is there a general approach or thought process when designing these systems? And general issues/problems that seem to come up a lot in the design that I should try to avoid? Could someone maybe walk me through one (or preferably all, while comparing the needs of each) of these and explain:

1) How do you come up with what entities are needed? 2) How do you decide on what relationships everything will have? 3) How do you incorporate performance optimization into your design? 4) Do I do this using classes or databases? Does it make a difference (i.e. would I have a class that can't really be translated to a database table, for example?)

The main reason I'm asking is because I was going through "Cracking the Coding Interview" and my answers were completely different from the author's - I had very different ideas of what classes were important.

MY ATTEMPT: With the photo sharing app, I would have the classes/tables: Photo and User for sure.

Then, I think if we're trying to create a schema, there would be a table linking photo and user if we assume each person in the photo is linked to the photo (is this table necessary? If not, is it still common practice to have a separate table for many-to-many relationships or not?).

But if we're trying to take an object oriented approach, maybe instead we'd have a class called album which does all the work and has all the info from the two other tables/classes. This is one thing I noticed in the book- there are a bunch of classes and then one class which basically has all the info and connects the other classes- is this common? For example, in my examples above, does this seem like it would apply?

I'm just hoping for some general rules/guidelines to follow because right now I have no idea how to tell what a good architecture for a large system looks like.

  • 1
    Suppose you were coding a photo album as a hobby project. Instead of asking "am I on the right track?" (well, of course, because all the requirements are on track to be met, in some way), you would probably ask "it feels like this aspect of the design makes things unnecessarily awkward; could we change things around to make everything simpler?" But how do you know that there is some ungainly aspect of the design? By working through thought experiments like use-cases and worst-cases. Also: "this login requirement is quite common; could we find a library instead of reinventing it ourselves?" – Evgeni Sergeev Nov 24 '16 at 12:01

The point of such questions is to assess whether you have real-world skills in writing a software application. You have learned some theory, but theoretical knowledge can only go so far. The only way to truly understand software development is by doing it.

There is no shortcut to this, because there are no stock answers to questions like "what entities are needed?" Instead, you have to apply your experience of various tools and paradigms, and how they work together, to come up with a practical solution to the problem at hand.

A question like "Do I do this using classes or databases?" suggests that you lack a basic knowledge of what things are and how they work. Classes are a paradigm for organizing your code; databases are a method of data storage. They are two inherently unrelated concepts (though they can work together). This is not an either/or question.

I don't mean to be harsh, but I think you need to develop your coding experience in order to succeed in such a job interview. You certainly have the potential--your discussion of the photo sharing app has some of the right ideas and is headed in the right direction. But you need to learn how this works firsthand. The best way to prepare for your interview is to actually create an application from start to finish. A photo sharing app would be an appropriately sized project, or you could choose something else. Your knowledge will really expand as you see how all the parts can work together to make a working application.


It looks like this is either expecting a database schema or a bunch of class definitions (or both?)

I think you're too focused on details here. With that question, the recruiter is not expecting a complete description of all classes you would write (otherwise they would ask you to code it, not talk about it).

Your answer first needs to be about the big picture - architecture, tiers, layers, even the project lifecycle and development process you would put in place. Don't hesitate to ask questions about the requirements and the environment the application is supposed to run in to adjust your answer. As dan1111 pointed out, there is no general recipe for a correct application design. All designs are context dependent.

Only if the recruiter starts asking really specific questions should you go into details about what classes, entities or database tables you would use under the hood.

Also, if you have little experience, it's only normal to say "I'll show you a solution using the type of application design I've been taught and used until now. I know of this and that other approaches which I can describe you in the large but have never really applied them. I'm also open to discovering and applying others".

There's nothing wrong with acknowledging that there are only so many tools in your toolbox that your experience allows you to have - in fact, it's better than spitting out a rehearsed answer which you have no clue how it works in practice.


I thought I'd make a quick comment on your first question:

1) How do you come up with what entities are needed?

The first thing I do for a new project is, either on a white board or big blank piece of paper, write down all the physical and conceptual things about that particular project that I and my team can think of. It's a brainstorm session.

Nouns tend to be objects, verbs tend to be use cases or methods.

Physical: photo (obvious!), display type, system, photo file, file format, user, date....
Conceptual: add, delete, save/store, retrieve, sort, modify, view/display photo....

Make connections between nouns and verbs. User Adds Photo. (Well - there's a use case!)

I would also suggest looking at UML and Design Patterns and how they can be used in generic OOD. (Notice - I didn't mention a language or a database anywhere above. Don't pick a language and then do your OOD. Do your OOD in a way that the design can be implemented by any OOL.

Not the answer you're looking for? Browse other questions tagged or ask your own question.