Facebook Interview Question Software Engineer / Developers
Country: United States
Interview Type: In-Person
is a comprehensive book on getting a job at a top tech company, while focuses on dev interviews and does this for PMs.
CareerCup's interview videos give you a real-life look at technical interviews. In these unscripted videos, watch how other candidates handle tough questions and how the interviewer thinks about their performance.
Most engineers make critical mistakes on their resumes -- we can fix your resume with our custom resume review service. And, we use fellow engineers as our resume reviewers, so you can be sure that we "get" what you're saying.
Our Mock Interviews will be conducted "in character" just like a real interview, and can focus on whatever topics you want. All our interviewers have worked for Microsoft, Google or Amazon, you know you'll get a true-to-life experience.
There are many possible solutions here. Supposing that we're only given a small amount of time, I would narrow it down to three candidate ideas.
- eugene.yarovoi November 07, 20121) Cookies
---------------
In other words, we store the data on the user's computer. This is the easiest solution and the cheapest for the website owner.
Some websites don't have logins and only track users through the fact that they use the same computer as they shop. Such websites use this solution by necessity. Even when you provide users with accounts that maintain cart information between sessions on different computers, you will probably want a cookie-based solution in addition to one of the other solutions below, because you wouldn't want people to be unable to add things to a cart until they log in. That's bad for business.
2) SQL Databases.
--------------------------
The advantages of databases is that they are well-understood by developers, offer powerful data retrieval capabilities, and offer many strong guarantees pertaining to the data.
At this scale you probably need multiple database servers. You could have some sort of rule-based system to determine which users reside on which server. For example, you could hash the username to obtain a number i from 0 to N-1, where you have N servers, and store the data for that username on server i. There are of course several issues to think through here: when you need more servers, user data will need to be moved between servers so that the new servers can have users for which they're responsible. A typical hash approach will mean that the server number for almost every username will change when you change the total number of servers. This means you will need to move most of the data between servers, probably meaning substantial downtime for most users as you copy terabytes of data.
You could use ideas such as "consistent hashing" to be able to move only small amounts of data at a time, or you could design a rule system for determining the server that doesn't use a typical hash, but (as a dumb example) is based on last name, for example. A goes to 0, B goes to 1...Then if you need to, you can change "A goes to 0" to "AA-AG goes to 0, AH-AZ goes to 232", and move over the small amount of data you need for that change, and do the changes in small amounts incrementally. It's important to think about how you will maintain and further scale these types of large systems.
3) Distributed Hash Tables
------------------------------------
A general distributed key-value store (usernames will be the key, values will be all relevant user data). Look this topic up if you're interested in learning more about it. Issues here include the strategy for distributing data among nodes, whether there will be data replication to ensure smooth failover, the performance of this system, and more.