Here are some quick tips that have served me well in past system design interviews.

The interview would start with an open ended question – by the end of the interview, you should have covered:

1. The exact feature-set at least for the minimum viable product/feature.
2. The API design – what are the required APIs if any and their specifics (inputs, outputs etc)
3. The high level design of the app to cover the agreed upon feature set.
4. UI Architectural choice – what works best for this particular problem? MVC, MVVM or something else?
5. Low level design or a walkthrough of the most critical user flow of the app – this should include how the data flows through the app from the network to persistence (if the app persists data locally) to the UI.
6. Details on how would you build the UI – so that it is performant and easy to maintain/modify.
7. Details on how you would unit/scenario test the app (so that you can catch regressions before they ship into production) and specifics on what the oncall team should track to support the product.
8. Pointers on what could be improved/changed in the design when the scale/team size increases.
   

Chances are you might not cover all of it, but I think 1 to 5 are non-negotiable if you are applying for senior/staff roles.

Some general tips:

1. Be decisive. This means -> make architectural choices/design decisions for the product being designed – do not rely on the interviewer to make those decision.
2. Call out assumptions. As you define the system, call out any assumptions that you have in your mind. Do not assume the interviewer understands your reasoning.
3. Be upfront about the reasoning behind your choices. As you make decisions (tip #1), explain why you made that choice and what other options were considered. Don’t wait for the interviewer to ask ‘why you chose this path instead of that’?
4. Lead the interview. Act like the senior engineer you are interviewing for:
   • List out all the topics you want to cover right at the beginning.
   • Time yourself and pace the interview so that all topics are covered
5. Be flexible with your approach – be aware of the direction the interviewer is nudging you in. The interviewer may be throwing a hint when they feel you are going down the wrong path or if the design has a specific issue that you have’t caught yet. Remember it isn’t purely technical interview – the interviewer is also trying to figure out if they would want to work with you in the future – everyone loves to work with a team player.

In a future post, I will go through a concrete example – a real question – to explain these guidelines in a bit more detail.