The Facebook Onsite Interview will generally consist of three parts: Motivations, and Part 2 Coding/Algorithm, and Part 3 Product Design. This is the Part Three: Design.
The so-called Design problems are based on designing a product from scratch.
Resources for Design Problems
https://github.com/donnemartin/system-design-primer
http://highscalability.com/blog/category/example
http://www.hiredintech.com/system-design
https://code.facebook.com/backend/
https://code.facebook.com/posts/816473015039157/making-facebook-s-software-infrastructure-more-energy-efficient-with-autoscale/
Most design interview should consiste of 25% of the time in front end and client side, 50% will be on building an API, and 25% is on the server side.
You will need to design a system or a product, the problem will be a broad and ambiguous one where you will need to create something, end-to-end, that will scale. You should not assume anything. You should pin down the requirements, FB is looking for you to drive conversation throughout the interview. Be very vocal, say this is what you are doing/why/ your reasons. It should be your design, not half yours and half the interviewers. Try to cover both breadth and depth, Facebook does not have architects at Facebook, so you will need to talk about both high level concepts and details associated.
Design Requirements
- We are looking to get signal on both your technical and communication skills.
- We want to understand how you reason through a problem that you’ve not necessarily encountered before.
- Think about designing at very large scale as this is what you will be doing at Facebook.
- We expect you to drive the design of your solution and lead the discussion after clarifying the initial problem.
- Go into a level of technical depth for each element or component of your solution.
- Be aware of trade-offs and alternative solutions and express clearly the decisions you make and justify why you made them.
Interview hacks
FB doesn’t expect you to know crazy algorithms that are domain-specific (like Quad Trees or Paxos). FB expects you to know that you have a variety of tradeoffs like consistency, availability, partitioning, etc. FB expects that you’re working with a modern computer and know ballpark ideas on throughput/capacity for RAM, Hard Drive, Network, etc.
A good design shows that you
- Think about a the high level design
- Clearly understand the problem and break it down in a logical way
- Think about all relevant trade-offs
- Identify the bottlenecks as the system scales and can poke holes in the design
- Propose a design for a system that breaks the problem down into components, that can be built independently
- Calculate (back-of-the-envelope) the physical resources necessary to make this system work
- Draw diagrams that clearly describe the relationship between the different components in the system
- Understand how to adapt the solution when requirements are changed
Try not to “one-off” stuff. Break things down into large, isolated components and drill in on things that you think are hard or critical problems.
There’s a good book called “Cracking the Technical Interview” that has a section called “Large Scale & Memory Limits” with some questions very similar to a design interview, but they’re a little too coding focused where the design interview generally avoids coding but may ask data structures.
Sample Design Questions
Probably the best way to study is to work out the below problems on a paper and just think about the ways to break them down.
- Design a Newsfeed system
- Speed up this mobile app
- Implement Ads Targeting
- Design the backend for Google Photos
- Design a web crawler
Recommended Methodology
Understand the Requirements
Spent 1-2 minutes clarifying the requirements. Either give the interviewer an example of what they are asking (e.g. “To make sure I understand the question — I will design the newsfeed service in Facebook, so I will need to consider things like “what shows up in the feed”, “in what order”, “privacy”, “latency”, “scaling the systems to billions of requests”, “redundancy”, etc. — Is that what you meant”. Alternatively you can ask them for an example of the product or feature they want you to design. Spend no more than 1-2 minutes here.
Some further examples:
- Are there any requirements on running time (online vs offline paths)
- Where are the users?
- How many users are there?
- Storage requirements?
- Data access or retention requirements?
- Security requirements?
- Mobile vs Web?
- Any APIs we need to externally expose? Any integration options?
Finally, before you proceed: ask which of the requirements are stronger than others? For instance, is there a strong requirement around data consistency? Latency? Reliability? Data Privacy? Can you write an ordered list of the priorities? Don’t spend a lot of time here, but at least ask the questions — it’s important that you understand what tradeoffs exist when design systems.
For instance, when speed and consistency are paramount, you should be thinking about synchronous calls. If some latency and variation in responses is tolerable, then asynchronous/queues are ok.
Second: Know the facts/figure that can help you estimate
Useful resource: https://gist.github.com/jboner/2841832.
You could try putting these on note cards and memorizing them.
Useful resource 2: http://i.imgur.com/k0t1e.png
This makes it clearer that you want to be reading from SSD, not disk, and certainly not doing many data center round trips.
And you also want to be careful about mutexs and access to shared resources.
Now you will want to estimate the scale of the system you will need — even before you start to design it. Here are a few questions to ask:
- How many API requests will we expect? (e..g What is the QPS?)
- What data will be returned in these requests? (bytes or megabytes or gigabytes)
- Will there be read AND write operations or just read operations?
Chances are, you’ll be given big numbers here. But it will be good to show that you understand that not every problem needs to be solved with a distributed, scaled system (sometimes things fit onto a single machine).
Last Step: Deep Dive/Design
Everywhere that there is a question written below in this preparation email (e.g. “Which objects will be in the system?”), it’s fine for you to just ask the question out loud during the interview. There are many right answers, and it’s better to ask the question than jump straight to an answer.
There are many things you may want to think about. You could go to the whiteboard write down the appropriate concepts, such as:
- Requirements
- Scaling
- Entity Design
- API Design
- Data Storage
- Security/Privacy
- Logging/Analytics
- Reliability
These are a lot of the concepts that need to be covered in any design. You may not get to all of them, but it’s important you show you understand the “big picture”. Having the words written down can also help with the pace of the interview, and help you to remember to address as many of the concepts as you can.
When thinking about entity modeling and design (Which objects will be in the system, and what relationships do they have with each other?), write down a few of the objects and relationships between them. When designing an API, make sure you point out that the API can be used by external AND internal developers (e.g. can be used by the mobile app, the web app, and packaged as an SDK for external developers). Think about what happens when this API is called?
Here are two excellent articles on it:
- http://blog.gainlo.co/index.php/2016/03/29/design-news-feed-system-part-1-system-design-interview-questions/
- http://blog.gainlo.co/index.php/2016/04/05/design-news-feed-system-part-2/
Write out the overall system topology.
It will almost always look like this at a high level:
https://gist.github.com/vasanthk/485d1c25737e8e72759f
Data Storage
How will the data be stored physically on both the client and the server, and how will it be accessed. You will almost certainly be designing a distributed system, so you will want to think about how to distribute it (sometimes this is referred to loosely as “how to shard the solution”. All this means is — when you are given a request from a user, how will you decide which backend end server to send to the request? How will the “Load Balancer” in the above diagram work? Will you send it to a different server based on username? Geographic location? A combination of the two? The important thing here is to think about how the scale the requests evenly.
Think also about caching: both on the client and server? What data will you cache? And why? How will you invalidate the cache? (will it be based on time? If so, how long?)
Security/Privacy
Who can see what? What about permissions?
But what about employees? Which data do they have access to? Is there new types of data being introduced here?
Does the API need any special key to work? Will the user be granting a permission to an external company? If so, how will we monitor for abuse?
Logging Analytics
What metrics do we care about? How will we log this data so that these metrics can be computed?
How long do we retain the data?
Reliability
- We need monitoring for the new services we introduced
- We need to be able to measure latency
- We need to publish service level agreements and metrics
Further Suggested Articles
https://www.palantir.com/2011/10/how-to-ace-a-systems-design-interview/
https://gist.github.com/vasanthk/485d1c25737e8e72759f
http://highscalability.com/blog/2014/7/14/bitly-lessons-learned-building-a-distributed-system-that-han.html
FB is looking to see how you handle thinking about the big picture? Do you know:
- How to formulate the goals, non-goals?
- How to scale the solution? (where are the bottlenecks? Is it memory, cpu, storage?)
- How to break down the processes?
- What about security?
- What about privacy?
- What about logging? And analytics?
- Any specific technologies that you’d invest in?
- What type of caching would you use? Why?
- Inter-server communication?
You should make sure to talk about all the points in the design, even if you can’t elaborate on each one (e.g. Goals, Non-Goal, Security, Scalability, Privacy, Analytics/Logging, Mobile Consideration, Testing). Take your time at the board, describing everything that has to go into a “complete solution”, even if its a bullet point (e.g. “We’ll want to make sure we log the thing we care about and have some sort of pipeline that can aggregate the data). Other things you should think about:
Jeff Dean’s “Numbers every computer scientists should know”.
Use the whiteboard — make sure you draw what you are talking about. Make sure that you list every single element in the design headings.
LEAD THE INTERVIEW: We want to see you asking clarifying questions.
Particularly when it comes to requirements gathering.
You’ll be given a very high level problem to solve, and you must pick the kinds of questions that will lead towards solving things successfully.
Final things to not to forget!
- Load Balancers
- Sharding
- Caching / memache
- Grids
- Distribution of Data
- Speed / space / time trade-offs
- Pagination
- API’s
- Client / Server relationships
- Partitioning
Below I have highlighted 5 final key preparation areas for your interview:
Please thoroughly read this Blog: https://www.facebook.com/careers/life/preparing-for-your-software-engineering-interview-at-facebook
Here are some videos that give great advice around our coding interviews (the video password is FB_IPS):
Cracking the Facebook Coding Interview – The Approach: https://vimeo.com/interviewprepsession/theapproach
Cracking the Facebook Coding Interview- Problem Walk-Through: https://vimeo.com/interviewprepsession/problemwalkthrough
Example Design Questions
https://www.careercup.com/page?pid=facebook-interview-questions
https://codelab.interviewbit.com/registration/?type=professional
A few helpful hints directly from our interviewers:
I would also highly recommend looking at Jackson Gabbard’s Youtube videos. Jackson is an ex FB engineer who was here for approx 7 years and left FB recently to take some time out and travel. Jackson is really passionate about interviewing engineers and did approx 500+ interviews for us so has some really great insights into what we look for.
Finally, I would suggest signing up to FB live video interview prep session if you have not already. This happens bi-weekly, and you can sign in from home. https://www.eventbrite.com/o/facebook-london-master-your-fb-interview-8037667565
facebook-hacker
–EOF (The Ultimate Computing & Technology Blog) —
loading...
Last Post: How to Delete Nodes from Binary Tree and Make a Forest?
Next Post: How to Compute the Greatest Common Divisor of Strings?
