Coding Interview: Design Challenge

There is no hack for finding a position, please be honest in every interaction.

A design challenge for a software engineer does not actually mean they want you to come up with an appearance for a website. It means they want to know how you would approach architecting an app or a process that is pretty vague to start.

I actually use a process that is almost identical to the Coding Challenge for these Design Challenges.

1. Listen well to the challenge they are giving to you.
   • Example Challenge: Design Instagram.
2. Describe your understanding of the ask. Remember, to solve this challenge, you do not need to be an expert at, or even know what Instagram is. If you have not heard of the thing they want you to design, ask them to describe the overall application.
3. Ask Questions. You want to have a clear understanding of what they are asking of you, to make sure you can answer all of the things that come up in solving this challenge. These challenges are often a problem that might be WAY too big for a 1 hour interview. So be clear that you will need to ask for clarity and make assumptions.
4. For any areas that you receive a “We are not sure yet” or “We don’t know” it is important that you identify the assumptions you are making to assure you can move forward. If an assumption has options that would drastically change the outcome of your design. Be very clear with them that you are creating a design that you can see potential holes in due to some assumptions you have to make. (And it is also worth discussing how you can architect this solution without creating a potential hold.)
5. Talk about the large picture first. Most applications need to account for more than the front-end design. There is a Front-end, a Back end, and Api to communicate in between, a database, maybe some object storage solutions that need to be leveraged and the interviewer will need to understand that you have at least a shallow idea how they can connect together. This conversation can also talk about hardware solutions and networking, not just code. As this type of interview is about the larger picture, I am very confident that you will be asked about things you do not know. For those areas, identify what you think they should do, what you understand of it, and then identify that you are not clear on the details of that implementation.
6. You can start discussing how the different areas of the application would communicate. This does not have to be a code level interview.
   • You could identify that you need the database to store information on users, media, how those are linked together, and knowing that users might tag other users in their posts about media, we will need some means of referencing other users on any media item.
   • You could identify that you will need API’s that can return information on a user, information on media, maybe information on friends lists, and any other data that should be available for the front end to gain access to.
   • You could identify how your front-end will receive the API data based on a contract that is predefined, and how it can start building CRUD (Create Read Update Delete) operations, and/or User Feeds with that information.
7. This interview will most-likely be a more interactive interview where you are having more of a conversation with the Interviewer. They might hear where you are going and ask points of clarification to gain further understanding of your plan. It is ok to pause to explain more information on that question if you have more information.
8. Don’t hesitate to ask for advice, and definitely don’t deny advice given. If you are stuck on a piece you don’t know, start communicating. If the interviewer offers up advice, even if it is not clearly part of your plan, explore it. Ignoring their advice, even if it really is in a wrong direction, allows you to open that conversation further, and see if you can understand what they are trying to share with you.
9. As you get further into this interview, you may or may not find edge cases that you want to discuss and address. Not every edge case is worth spending time on, but I have found that it is helpful to at least identify or ask about a potential edge case to see if you should incorporate that into your current plan.
10. If at any point you want to do something that might involve looking something up, or pulling up a site that is not in the interview. Communicate that, and ask if that is ok as part of this interview.