How I Cracked the Object Oriented Design Interview at Amazon

Find more useful articles at

The most prominent questions to last week’s article, “How I got into FAANG”, revolved around the Object Design interview. Namely, “what it is?”, “how to prepare for it?” as well as what the OOP interview at Amazon actually looks like.

Object Oriented Design

Object Oriented Programming is a programming paradigm based on the concept of objects, which can contain properties and functionality.

When designing the OOP way, we could define a class Human. With attributes such as height and hairColor and methods such as eat() and sleep().

Our desire could now be to extend the functionality of the Human Object by the method code(). But since we don't want every Human to be able to code(), we'd sub-class Human, to inherit all attributes and methods.

We then have the ability to add further functions or attributes, or override existing ones.

class SoftwareEngineer: Human {}

When designing objects, make sure to think about what kind of attributes should be exposed and what kind of parent properties can potentially be extracted into a super-class.

Let’s look at another example.

The Interview

It’s fair to say that the process is pretty much almost always the same. As interviewee, you’ll be presented with some kind of a real world scenario like “Design a Parking Lot”, and then you’ll be asked to create a technical design for that.

In this article, we’re going to design a “Puppy Hotel”.

The hotel has a clearly defined amount of hotel rooms for small dogs, rooms for medium sized dogs, and the same for large dogs.

In the interview, what is described above is literally all we’ll get as a scenario description. It is now on us to ask the right questions to the interviewer. These would include questions to clarify what functionality the design is expected to full-fill.

Never ever make assumptions. It’s part of the interview to see how you handle vague questions. Are you asking clarifying questions, or are you jumping straight into code, potentially wasting your interview coding into the wrong direction?

We’d ask the interviewer what ability the hotel needs to have and we learn that we need to be able to “check in” and to “check out”.

Once I know what I need to develop, I’m starting out with some code snippets as a conversation starter with the interviewer. While typing the code I’m explaining what I’m doing.

Next I’d design a quick type for the Dog.

Now that we have a type definition for the sizes of our dogs and the Dog construct itself, we need to add the data structures to the Hotel. Since we want to prove to the interviewer that we "Think Big", we will have a custom initializer passing the size definition for each room size. We can reuse this class for every hotel we might own at some point.

We’re using dictionaries as the data structure of choice, because every operation has a perfect constant Big O operation cost for each time and space.

During the interview, it’s important to verbally express your thinking. The interviewer wants to hear that you’re thinking about making a class or function generic. That means you don't hard code variables, like the amount of available rooms. It shows seniority, and that you're thinking about the bigger picture.

“Thinking small is a self-fulfilling prophecy. Leaders create and communicate a bold direction that inspires results. They think differently and look around corners for ways to serve customers.”- Amazon Leadership Principle: Think Big.

Next we’ll add the function declarations for the stubs of before.

The Follow Up Questions

With above basic construct in place and hopefully some time left in the interview, we’re expecting some follow up questions from the interviewer. The purpose of these questions is to see how well you understand writing scalable code.

Are you locking yourself into a corner, or are you able to identify opportunities for scalability already? How well are you communicating your thinking and planning process?

I intentionally left some room for improvement in the code snippets above. Right now in our design, if all rooms for small dogs are taken, the customer is sent away. To improve the user experience, we want to add the ability to have small dogs occupy medium sized rooms as well.

The hotel is now able to utilize room sizes based on demand, and we have optimized the code by setting the access levels of our functions.

The API clearly states that checkIn is a function available on any Hotel Object, while getRooms is a private function only available to the Hotel object.

What methods and attributes are public and what are private depends on the circumstances of the project, but a good rule is the "need-to-know" basis. Only expose functions and attributes the consumer NEEDS to know about.

Interview Preparation

There are many ways to prepare for Object Design interviews. If you’re just reading this because you’re curios, but you’re not forced to study up on this topic, then I’d suggest for you to take it easy.

Expertise comes through practice. The more often you design objects, and the more feedback you can gather, the more you’ll learn and the better your designs will become. A mentor or a study group is always a good idea for such trainings.

If you’re about to interview and you’d like some last minute ideas and influences, then YouTube provides a flood of content. I’d look for something short with a high view count. That typically gets to the point fairly fast.

Then try to design a few objects.

  • Design a Parking Lot
  • Design a Package Locker
  • Design an Airport

Try to predict some follow up questions an interviewer might ask.

  • How could you optimize?
  • How could you extend functionality?
  • Drawbacks?
  • Potential time/space improvements?

Ask friends, colleagues, or strangers on Twitter. There is a whole community of friendly students and trainers, as well as professionals available at pretty much every major social media platform.

There are tons of books available for this topic as well. Although, in my experience, the 5 minute introduction followed by “learning by doing” served me better than reading a book for a week.


In the end, it all narrows down to the same thoughts and principles, all the same ideas and concepts. No matter if you design a House, a Car or a Spaceship, you'll always go with a clearly defined API–private and public attributes that define the access level and functions with the best possible efficiency and security.

This article illustrated my process when faced with an Object Design situation. I’m typing some code snippets, I’m re-thinking, and I’m adjusting my code based on the verbal discussions and potential changes in scope.

In an interview or code review scenario, I’m trying my best to “think out loud”, and I’m defining and verbally justifying custom type definitions like the DogSize enum. This shows the interviewer that my code is type safe and scalable.

I’m setting expectations and I’m documenting my code well. That way, it’s easier to refactor and adjust the code later, as well as to debug crashes or issues.

Learning Object Design is not a step by step tutorial. It’s a process and as you’ll learn from mistakes of the past, from talks, articles and suggestions, you’ll naturally get better over time.

While you evolve, so does your understanding of Object Oriented Design.

Find more useful articles at

Software Engineer at Amazon (Alexa Mobile)

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store