Tell me about yourself.
To some people this sentence probably brings them nightmare. Interview is a long and tiring process. You might study everything and companies still manage to find ways to reject you. Like many people, not only have I been interviewee multiple times but also conduct interviews. I will go over some common rounds in interviews and mention some tips for those.
This includes when talking to recruiter, hiring manager, or when talking about your experiences. Make a story. I don’t mean make up random stuff and sell it to them. I mean try to package it in a way that is easy to follow. From the only thing I’ve learned from my high school English class: a story always has a beginning, conflict, climax, and resolution. This might be better if I have an example.
Why did we migrate from monolithic and adopted micro-services? As the system grew, it was taking very long time to deploy any features, engineers lost focus when the codebase became more complicated, and sometimes tests of irrelevant codes would fail. This presented an opportunity to access the situation and we suggested micro services. At first this didn’t get much buy-in from engineers nor business side due to the nature of rewrite which would take long time and wouldn’t get immediate values. Some of us engineers believed it would be the future and and would serve us better in the long run. We started working on it on the side and secretly deployed it to production. The metrics supported our hypothesis and we got full support from everyone else. Nowadays, we have a service for frontend, a GraphQL layer, and many micro-services handling various things.
You can prepare a one-minute version, 2-minute, and a 5-minute that you can quickly pitch when asked and go into more details if interviewer wants to.
This session, probably goes without saying, it so test your coding ability. However this is also a chance for the interviewer to gauge whether they can work with you in a simulated working environment. So do not just read the question and start coding right away in silence. Try to ask clarifying questions and walk through the thinking process in between writing codes. Some interviewers would ask what or why you’ve done this way but please do take the initiative to explain what you’ve done. People who don’t communicate are usually less favorable.
When writing the solution, try to create something that works even though the performance may be pretty bad. We can always optimize it later and handle edge cases. It’s better to have something working than stuck in technicality. Of course there are some companies that would like you to write the algorithm having the best performance and memory management on the first try but that is rather rare.
For frontend you may be given a UI mockup and fake API response and you are asked to recreate it. I have seen more and more companies doing this since it is much more similar to what frontend engineers do on a day to day basis. You may also get LeetCode type of questions as well. I am not too sure what questions are used for backend engineers interview but I’ve heard it more or less a LeetCode type of question.
This may differ between frontend and backend but generally you will be asked to implement a feature or a system. You may be asked how to make a this twitter feed function or how to handle huge load for this e-commerce website during holiday season. The question and requirements are vague by design and should be driven by you for most of time including asking clarifying questions, asking more question to make proper assumptions, ask yet more question to scope out the features. Questions can be:
- Do we only need to focus on feed and not authorizations?
- How many people will be expected to use this now and future? How do we scale?
- Do we care if certain features are done on the frontend or backend?
First make a general proposal then we can do deep dive into certain parts of system to refine them. Sometimes interviewers will ask you to do deep dive in certain portions, if not it’s better to ask which part you should go specific on since each interviewer cares about different things. At the end of the day, your design should fulfill the problem with performance and scalability in mind.
Some questions I’ve heard of for system design round:
- How to support a infinite scrolling page like a twitter feed?
- How to improve a slow website?
- How to make this single player game into a multi-player online game?
- Design a notification system
- Design a chat system
- Design a URL shortener
Hope these help at all and ease your uncertainty of what to expect from interviews. Good luck!