Redbubble is not unique in expecting interview candidates to be able to analyze and design a model for a complicated problem on the fly. It’s a useful and interesting mental exercise for developers, and it gives us an amazing insight into how candidates go about solving problems. But it can also be stressful for candidates who aren’t used to it.
The interview will begin like this: We will give you some ‘business rules’ for a system we would like designed, maybe also a few constraints, and then we will ask you to design it for us.
The final design you come up with will be different for every problem-person combination, so I can’t tell you what the answer will be. There are also dozens of different strategies to get to an answer, and if you have a strategy that works for you, then you should use it!
However, if you haven’t had a lot of experience in whiteboard designing, here is a process that will help you to shine as brightly as you can.
Before going any further though, I must stress; there is almost certainly no ‘right’ answer to the problem you’re given. Every time you come up with a solution which seems to work, we will introduce a new change to requirements which will make you think again. This is because the solution is not our primary interest. (If it were, we would set it as a homework task.) What we care about most is the process you follow to turn a problem into a solution design.
- Do you explain your thinking?
- Is your thinking sound?
- Are you considering all your options?
- Are you choosing the best option?
- For the right reasons?
Those are the things that matter.
For the rest of this piece, let’s assume that you have a problem description that looks like this:
“Users should be able to make custom products, by picking a piece of art and a garment design, then choosing the correct size.”
Interview problems will generally be longer and more complex than this, but the basic steps will likely be the same.
Step 1. Clarify the problem.
The above description sort of makes sense, but there are some points of confusion. Start by clarifying any specific language you don’t understand. What is a ‘custom product’? Where are they picking art from? What kind of art are you talking about? What makes a size ‘correct’?
Then, try to run through an actual, practical scenario from the user’s point of view. You can make up an imaginary user here if it helps. The goal here is to understand exactly what the solution looks like. If you don’t know what the solution looks like, you won’t know when you get there.
The end result of this step should be a clearer statement, either written out or in your head. In this case, let’s say we end up with something like this:
“A user must be able to design a unique, customized product, by first selecting a piece of artwork from a gallery, then selecting a garment from our range to print the art on, and selecting a size for that garment from a list.”
Step 2. Find the nouns.
In many cases, the nouns (names of things) in your problem definition are going to become your classes. If I go through and bold all the nouns in that sentence, you’ll start to see a few likely candidates:
“A customer must be able to design a unique, customised product, by first selecting an artwork from a gallery, then selecting the type of garment from our range to print that artwork on, then selecting a size for that garment from a list.”
So let’s pull out those words and remove any duplicates:
Some of these words are obviously good fits for classes, and some of these are going to be attributes. Try out a few options in your head, then discuss the pros and cons of class versus attribute with your interviewer for any tricky corner cases. Your interviewer will be glad to hear your thought process on this front.
Once you’ve got a good idea of your classes, make sure they’re all up on the whiteboard and keep going.
Step 3. Find the verbs.
Where nouns point you to class names, verbs (actions) point you to methods. Let’s pick out the verbs here:
Now you need to link the verbs to the classes they belong to. Take a close look at this particular phrase:
“selecting an artwork from a gallery”
In this phrase, it is clear that the verb “select” belongs to either the “artwork” noun or the “gallery” noun. Let’s imagine what those two options might look like in code:
Once again, this is a place where you should talk to the interviewer about the benefits and disadvantages of these options. How would these methods work? Which other objects would need to call this method? What data would those objects have access to? Which method would result in more readable code? If it’s not immediately obvious that one is better than the other, then maybe apply SOLID principles.
Once you’ve figured out where that method belongs, update your diagram and explain your decisions, then keep going.
Step 4. Play out the scenario.
By this point, you should have the key classes and methods in place. Now it’s time to run through the specific scenario you identified in step one, and show how the messages would flow in this scenario. Where does code execution start? What objects get instantiated, and where? Who calls which methods, and when?
This is the point where you can prove that your solution is a good one. Sell the interviewers on its elegance, its clarity of use, and its simplicity. Interviewers love simple, elegant solutions!
Step 5. Extend.
At this point, you’ll probably find that your interviewers add extra complexity into the problem, or identify some aspect of the original problem definition that your current solution cannot correctly handle. At this stage, you should go back to step 1 with the new information, and keep looping until the interview is over.
Don’t be afraid to change something that is already on the whiteboard. Whiteboards aren’t paper, they’re meant for ephemeral content. As you get more information about the problem, you may find more elegant solutions to the problem. Every time this happens, explain to your interviewers why you’ve changed your mind, and why your new solution is superior to your previous solution.
Even if you think of an alternative and then discard it as not good enough, share that insight with your interviewers. The paths not taken can say a whole lot more about you than the paths taken!
These steps should see you through most software design interviews. I’ll just end with a few useful tips.
- If there is a simple way to do something and a cool way to do something, pick the simple way. Talk about the cool way by all means, but simple designs make for simple systems. Everyone loves a simple system.
- Focus on things you are confident with. You may have just learned about some amazing new language feature or design pattern or tool, and you want to show off your knowledge. Don’t do that. You will almost certainly fall into the ‘cool’ trap. Simple > Cool. Plus, there’s a good chance that you’re treating the new tool like a hammer. When you have a hammer, every problem looks like a nail.
- Solve the simplest part of the problem first. At the start of the interview, you might find that you’re overwhelmed by the size of the problem description. There are so many possible decision points and concepts to worry about. Just pick one clear, self-contained part of the problem to focus on, then complete steps 1 through 4 for that specific part of the problem. When that’s done, it’s time to roll the next part of the problem statement into your existing solution as part of step 5.
- Listen to your interviewer’s questions. When you’re doing well, we’ll ask you questions so you can shine. If you’re going down a very unwise path, we’ll try to warn you by asking questions about the part of your plan which won’t work. Think carefully about the questions, and you’ll normally be able to tell which is which.
- There are dozens of ways you can show your model and design. Dot point lists, class diagrams, sequence diagrams, pseudo code, circles and arrows, venn diagrams, wibbly cloud shapes, interpretive dance… Once again, use only what you are most confident with. If it helps you explain your thoughts quickly and easily, then it’s the right tool. If you’re not confident and you’re trying to use something to impress us, then you’re probably picking ‘cool’ over ‘simple’ again. (Although you should try to steer clear of pseudo code if you can. It takes a long time to write, and often doesn’t make sense to someone else without a lot of context).
- Try to relax. If you start to get nervous, and you almost certainly will, remind yourself of these steps. If you start to stray too far from the plan when you’re already stressed, you’re just going to make that stress worse.
When you’ve got a good handle on whiteboarding design, why not practice your new skill at a Redbubble interview? We’re pretty much always hiring, and we love to hear from enthusiastic engineers!