"Resurfacing": Mastering Frontend Design interviews - A perspective from the interviewer

Resurfacing one of the popular articles of “Typescript Daily” again for this newsletter edition.

For this edition, we will cover typical candidate-interviewer interactions that happen during a front-end-system design round. Again, this is mainly for educational purposes as different companies differ in the interview styles. Regardless, this article should give you a high-level perspective of how to approach a “Frontend System design interview” if you are applying for roles like “Senior frontend Engineer”, “Frontend architect”, and similar ones.

Before we read further into this article, let’s establish some context:

1. Interviewer - is the one who is interviewing

2. Candidate - is the one who is attending the interview (specifically the frontend system design round)

3. Comment - This is just a suggestion on what is the general expectation for each interaction/discussion. We will try to include both Good and Bad parts so that you can be well-informed of some of the expectations.

Since it is a system design interview round, it is the candidate who should be leading the round and not the interviewer. Imagine this way before you attempt any system design round. The aim of this round is not to implement the flawless solution but to demonstrate the considerations that are taken in order to arrive at some solution. Of course, the implementation is important as well but the primary motive is to brainstorm on the design.

Based on my experience interviewing over 200 people in various companies, this is the place where I find most of the candidates lacking experience. Even the candidates who perform remarkably well in the other rounds (like problem-solving, domain rounds, …) fail to switch their mindsets to view this round from a different angle.

As a candidate, you should understand the difference between problem-solving rounds and design rounds.

“Imagine in your day-to-day work, if you are asked to design an “XYZ” feature and nobody is there to guide/review you, how will you design the feature making sure that that is usable, scalable, performant, secure, extensible, fault-tolerant, modern, …”

Overall, the intention of the design round is to understand the design thinking skills more than your problem-solving skills. Sometimes both go hand-in-hand, but you understand the gist.

Ok, with this in mind, let’s cover a mock-styled interview and see how that works out.

Interviewer: Your task today is to design and implement a simplified version of a scheduling tool like Calendly. Here's a basic wireframe.

Candidate: Okay, to start with, I assume this application allows a user to set their available time slots and lets other users book those slots. Is that correct?

Interviewer: Yes, that’s correct.

Comment:
Good: The candidate began by confirming the core functionality of the system, ensuring that they have a clear understanding of what they are designing.
Bad: If the candidate didn’t confirm the basic functionality, they could end up making assumptions that lead to a design that doesn’t align with the actual requirements. Also, if they immediately start with coding (which happens a lot of times), that is seen as a red flag.

Candidate: Given the nature of the application, I believe responsiveness is key. The application should work smoothly across various devices, including desktops, tablets, and mobile phones. I am thinking of starting with a mobile-first approach for the UI design. Does that align with our target user base?

Interviewer: Yes, a significant portion of our users will likely be using mobile devices.

Comment:
Good: The candidate is considering the user base and device compatibility upfront, which is essential for user experience.
Bad: If the candidate didn’t consider the range of devices the application should support, it might lead to a less-than-optimal user experience for some users.

Candidate: Great. For the UI, I am considering a Single Page Application (SPA) approach, likely using React for its virtual DOM and efficient updates. To manage the state, I might use Redux or Context API. What do you think about this approach?

Interviewer: Why did you choose SPA for this? Could you elaborate on that?

Candidate: Sure. A SPA would load the necessary HTML, CSS, and JavaScript once and then dynamically update as the user interacts with the app. This should result in a more fluid user experience, reducing the load times as users navigate through their scheduling settings and view appointments. It’s especially beneficial for a scheduling tool where users might frequently update their availability.

Comment:
Good: The candidate explains the rationale behind choosing SPA, highlighting the user experience benefits, which is essential for a tool with frequent interactions.
Bad: If the candidate didn't explain why they chose a SPA approach, it could appear that they are choosing technologies without considering the implications for the user experience.

Candidate: In terms of performance, I’m considering lazy-loading non-critical assets and components, so that the initial page load is as quick as possible. Additionally, I think employing code splitting and tree shaking would help reduce the size of our JavaScript bundles. What are your thoughts on this?

Comment:
Good: The candidate is proactively considering techniques to optimize the initial page load, which is critical for user retention and engagement.
Bad: If the candidate didn’t bring up strategies like lazy-loading, code splitting, or tree shaking, it may suggest a lack of awareness regarding front-end performance optimizations.

Interviewer: Sounds promising. Can you elaborate on how you plan to measure and monitor the performance?

Candidate: Sure. I would use tools like Google Lighthouse, WebPageTest, or custom Real User Monitoring (RUM) to collect performance data. We should monitor metrics like First Contentful Paint (FCP), Time to Interactive (TTI), and Core Web Vitals. This data could be reviewed regularly and used to inform our optimization efforts.

Comment: Good: The candidate is suggesting specific tools and metrics for monitoring performance, indicating a data-driven approach to performance optimization. Bad: If the candidate didn’t have a plan for measuring and monitoring performance, it could result in performance regressions going unnoticed.

Candidate: Moving to the data layer, considering that we need real-time updates (e.g., when someone books a slot, that slot should be marked as unavailable immediately), I am thinking of using WebSockets or similar technology to push updates to the client.

Interviewer: How would you ensure the security of this real-time data?