One topic I've been thinking about for the last little bit is System Design. Throughout my informational interviews, I've gotten little tidbits of information to help me prepare for the interview process' at said company. One of these bits of information pertained to system design often phrased in the manner of "be prepared to architect Twitter or FaceBook."
According to the University of Waterloo: Systems design is identified as the philosophy, methods, and approaches to solving problems that are intrinsically multi-disciplinary. Through the consideration of the objective and subjective performance requirements, a design solution is constructed to meet the needs of the customer, the user, and society. Some of the main tools include strategies, procedures, and techniques that help in architecting a specific product or project.
Ask clarifying questions to eliminate ambiguity with the interviewer. Who are the users? What is its primary purpose? How will it be used? What are the likely inputs and outputs?
Now that basic understanding has been established, this is a good opportunity to ask questions about the features of the application. It's imperative that what you are suggesting is along the lines with what the interviewer wants before you move forward. What type of clients does this application want to support(mobile, web, etc)? Are we requiring authentication? Do we want to incorporate analytics? Are we integrating with existing systems?
We need to determine the scale to gauge if our data is compatible and can fit on one machine. What is the read-to-write ratio? How many simultaneous requests should we expect? Average response time? Limit on data we allow users to provide?
Begin with the end-to-end processes determined from the goals set in step 1. This might cover APIs, backend services, network architecture, data stores, outlining different clients, etc. and how they all join together to meet the requirements of those stated goals. This is where the conversation will end up covering potential performance bottlenecks and decisions about the delegation of responsibilities. Whatever way you approach this step, remember to start simple and build it out from there.
Runtime and memory complexity are super important in designing software systems. The efficiency and usability of the application (depending on the scale of the project) are completely dependent on a deep understanding and implementation of DS&A.
Just about every decision you make will have trade-offs. It's important to be able to talk about them in real-time, offer solutions for them and demonstrate that you are aware of the complexities of systems and how they often require compromise and showcase your understanding through the pros and cons of each approach. Remember, there is no correct answer, just be prepared to explain yourself to show the interviewer that you're logical and will use the appropriate tools to get the job done.
This can be broken down into four main compartments and are best illustrated by this image:
- task definition
- conceptual stage
- design stage
- implementation stage
For the example portion, I am going to keep it simple and stick to Twitter and showcase some smaller examples. As I'm sure you know by now, architecting an entire social media page would be quite extensive and this goes back to step 2 of the Main Steps portion of this blog and establishing the scope. Remember to ask lots of questions so you aren't diving deeper than you need to and wasting interview time.
I hope this blog post gave you some clarity on the subject and a better understanding of how to tackle this prompt next time you encounter it.