Solutions Eng @ FB is Hiring: If you want to learn more about the role, my experiences and how to apply, go here

Content Index:
  1. Background
  2. Resume Writing​​​ (70 Hours)​
    1. ​Format and Design
    2. ​Content
  3. Getting an Interview (20 Hours)
    1. ​Referrals
    2. Reaching out to recruiters
  4. Preparing for an Interview (300 Hours)
    1. ​Why Prepare for an interview
    2. Google's Grading Rubric
    3. Brushing up Algorithms and Data Structures
    4. Improving Coding Skills
    5. Importance of Mock Interviews
    6. Day of interview
    7. Resources
    8. Must Do Questions
  5. Frequently Asked Topics
    1. ​What language to use in interviews
    2. Common Pitfalls to avoid
    3. When to Start Preparing

Background:
Beginning with some background introduction. I did my undergrad from LUMS in Pakistan majoring in CS, although a good school but not on the radar of all recruiters here in Bay Area. In the middle of my second year as a PhD student at University of Southern California, I decided to apply for jobs and graduate with a Masters instead. I wouldn't say I was particularly a hot candidate for companies since I never interned at top tier companies, infact over years I failed to clear Microsoft and Google interviews even for internships. I applied to 25 companies and 8 of them responded. I cleared HR and phone screens for all of them and visited their campuses for onsite interviews. Overall, I went through 56 interviews in total and secured job offers from Facebook, Microsoft, Amazon, VMware and Cisco. I spent around 8 weeks in the whole job search process where 6 weeks went to preparation and 2 weeks for interviewing. I used to prepare 60 hours a weeks in the preparation phase which means an overall effort of ~375 hours. For reference, here is my resume. 

​
Resume Writing
Spending time on resumes is one of the most undervalued aspects of job hunts. The multiplier on gains you get on the time spent refining your resume down to the last word is huge. Writing a resume is one time effort and then it would be used in practically every application. The quality of your resume determines whether a recruiter calls you back or not and that can be the difference between getting the job. I would have spent around 75 hours refining my resume. While writing a resume, keep in mind that this resume is mostly for you to get an interview and is targeted for recruiters, there is very little value of your resume after you get an interview. I will summarize some of the aspects of resume writing but I highly recommend going through blogs/quora online for at least 20 hours to get a feel of what recruiters are looking for in resumes.

  • Organization: As a rule of thumb, keep your resume to one page and readable within 30 seconds. Here is a suggested format template I used and here is my own resume for reference. There is some great advice on resume writing from Gayle Laakmann (Author of Cracking the Coding interview).
 
  • Content: Remember recruiters are your target audiences and they have piles of resumes like yours so you have very limited time to distinguish yourself. You can't afford to dilute your resume with fillers and just focus on the strongest points. I can't emphasize enough on how crisp each and every bullet should be. Moreover, the resume should be as non  technical as you can make it because the recruiter is just looking for keywords. Each bullet has a format, it starts with an action word for example,  "implemented, designed etc". If any of your bullets is not starting with an action word you should seriously reconsider that line. Then, it is followed by what you did in 4-5 words which is the body of bullett. This body is usually a good place to add keywords. The ending of your bullet is crucially  important. It should be presented as a valuable result or finding to make overall the bullet an achievement; Something like "improved throughput by 10 times". It is super important that each and every bullet is an achievement not a responsibility. The worst thing you can do to yourself is to write a bullet which seems like an Activity. In my experience, most of the activity bullets can be rephrased to become achievement bullets.
    
  1. Activity (Discouraged):  Used DPDK and cache aware access mechanism to reduce the the number of cache misses and hardware interrupts
  2. ​Achievement (Encouraged): Implemented an efficient cache access mechanism on top of DPDK to achieve 8 times higher throughput in some distributed systems
 
  • Get Feedback (Super important): It is important to get multiple rounds of feedback from people with different backgrounds. Every time I finished a draft of my resume, I thought this is the best version I can come up with, however after getting feedback there was always something I could improve and eventually I had to do 8 iterations over my resume. You would want one person who can check your grammar, typos, and sentence structures. Then you have resume reviewers at almost all universities career offices, who will give you insights on how a recruiter will look at your resume and then finally a technical person who helps you build a coherent story about your technical background. Don't have any more than these 3 reviewers, one for each aspect and have them review your resume twice and incorporate their comments. Its great to have a google doc version of your resume to get feedback easily from everyone through comments so you can have a follow up discussion.
 
  • Skills: This is something unique that I tried. Recruiters seem to pay a lot of attention to your Skills section and see if you match the job description. They don’t know what Cloud computing is but if it appears on both your resume and the job description then you are highly likely to get a call. I gathered all the 15 job descriptions I was interested in, parsed them for keywords. This will give you an extensive list of skills needed but you can't use more than one line on your resume for this so I consolidated multiple skills into something more general, like hadoop, mapreduce, hive etc all get covered by "Big Data Analytics". Similarly for all other skills. This line will essentially define what sort of job you are looking for and if it’s very different from the job description you might not get an interview. Think of them as keywords you would use to lookup the job on LinkedIn that you want to end up with. Here is the skills section from my resume.
  1. Languages: Java, C, C++, Go, Python, Bash, MySQL, MATLAB, HTML, CSS
  2. Unix, OS Virtualization, Kernel Programming, Big Data Analytics, Cloud Infrastructure, Networking, DPDK
Getting an interview:
You might think applying through the online portal is enough but it's not true. Millions of people leave their resumes at those portals and most probably some automated systems filter out many of them before a human gets to read them. Apply through the online portal but donot solely  rely on it to get you noticed.
  • Referrals: Best way to get a job interview is through a referral. According to Forbes, around 50% of jobs at Cisco are filled through a referral. So reach out to your friends, colleagues, etc. and search for people you may know at a company on Linkedin and ask them if they are willing to refer you. They get referral bonuses if you are hired so they have incentive as well. At times friends of friends might be able to refer you as well so don't hesitate in asking friends if they know somebody at company XYZ. Moreover,  ask your Professors if they are willing to refer you to their contacts in the industry. One of the referrals from my Professor was so strong that they offered me a job without even interviewing. Professors tend to have contacts with more senior employees and as you might expect, referral coming from a senior employee has much more weightage as compared to a referral from a new hire.
  • Reaching out to recruiters: The next best thing is to find recruiters of different companies on LinkedIn and parse through their profiles for email addresses. Send them a mini cover letter saying why you are a good fit for their company and attach your resume as well. The hit ratio for such emails is very low, may be only 5% recruiters will reply but even if you get one interview out of this it's worth it. I landed a job at Facebook by a similar email and otherwise I don't think I would even have got a chance to interview with them. I have added the email as a reference. Moreover, I got an interview call from Google using a similar email.
​
"Hi <Recruiter>,

Hope you are doing well. I am a Master’s Student in CS at University of Southern California and will be graduating in May 2016. Currently I have a 4.0 GPA and have taken many relevant advanced courses like advanced distributed systems which provide a good background for Facebook. I have also done research assistantships focusing on scaling large scale distributed systems. It would be great if you could have a look at my resume.

Regards,
Mohsin"

The important thing is to not get disappointed by lack of replies, these recruiters get a bunch of emails like this. I must have sent over 75 such emails but only 6-7 replied but in the end it got me the job I wanted all along. Also, don't hesitate to send emails to multiple recruiters from the same company.



Preparing for an Interview:
  • Why spend time on preparation: First of all, you have to realize how important it is to prepare for interviews. I used to think over years that I am good at coding, so interviewing would not be a problem for me. It took a rejection for Internship from Microsoft and a rejection for internship from Google during grad school for me to realize I needed to prepare for interviews. Actually there is very little correlation of how good a programmer you are at school with your performance in an interview. It is a totally different skill in a completely different setting and you have to work hard to acquire this skill. Its very simple to but not easy. You have to be consistent, sit down and practice a lot. The thing is that you are graded at a relative scale during the other interviews and all other candidates spend a significant amount of time preparing. Even if you get the most optimal solution during the interview, other candidates might have already seen that question and they would crush their interview in less than half the time you took resulting in you getting a rejection. There is a finite set of "Interview Questions" which is not more than 300 or so questions, the more you practice the better shape you are in for the interview.  Actually 60% of the interviewers asked me a question very similar to some question I already had seen during my prep so I would quickly solve it and move to the next question. Therefore, within the first 15 minutes of the interview I was already ahead of a lot of the other candidates. Google is an exception to this, all their questions are new and tricky so doing enough practice would also develop a good sense of solving unknown problems.
  • Even if you think that somehow you are very good at interviewing and don't need to prepare, your performance in the interview actually determines what SDE level will you be brought in as and what salary package is offered to you. A recruiter from Facebook actually told me that they extend salary packages ranging from 100k to 125k for new grads depending on how they perform in their interviews. Not only this, the signing bonuses and stocks you get which can be vary from 5k to 150k depend on your performance in an interview.
 
  • Google's Grading Rubric In order to prepare for the interview it's important to figure out what metrics are companies assessing you on. Grading rubric for Google looks like something below:
 
  1. Problem solving and analytical abilities (1 point)
  2. Data structures and Algorithms (1 point)
  3. Coding (1 point)
    1. Ability to translate algorithms into code
    2. Ability to write bug free code
    3. Ability to write formal code (not pseudocode)
    4. Ability to write elegant code
  4. Communications skills (1 point)
    1. How well can you "teach" them your solution?
    2. Also known as "Would I want to work with this person?"

All interviewers score you out of 4.0 and 3.5+ is an enthusiastic hire. In order to get a job at Google it's often said that you need all 4 interviewers to give you an enthusiastic hire leading to Google's obscenely high hiring bars. However situation in other companies is much better. 

  • 1. Brushing up Algorithms and Data Structures Cracking the coding interview by Gayle Laakmann should be your Bible to the interview prep. Anything written in that book should be on your fingertips. I went through the book cover to cover twice but mainly focusing on first 10 chapters. Book has 150 questions and if you solve them on your own and code them on paper before looking at the answers it would brush up your problem solving skills and provide a good start. Never forget to go through all the answers in the solutions section because that is the time you are learning the most. You already knew the code you wrote so merely solving the question does not help you learn anything new but going through the solutions and realizing what you could have done better adds a lot of value to the preparation. Analytical abilities include how you can reason about the space time and runtime complexities of a solution and discuss their tradeoffs and the book goes into a lot of detail on this. Infact any advice that Gayle Laakmann gives is great, I followed her careercup posts, quora posts, Youtube videos to get insights into the interview processes.
  • It’s a great idea to brush up on basic data structures from CLRS which does not take a long time. However just reading them up is not enough. This grading rubric is a cryptic way of saying "Did the candidate use most efficient DS to solve the problem". Therefore, it’s important that you get enough practice on using the right DS at the right time. Moreover, you should know all the internals of all basic data structures and how they are actually implemented (yes some interviewers do ask you to implement them). If in your undergrad data structures you were not asked to implement them from scratch now would be a good time to do that before you jump into the real interview questions which use them. Even all this is not enough to ace this point, practice using these data structures is the key and will be discussed in more detail it in the next paragraph
 
  • 2. Improving Coding Skills: As students we are used to writing code that just works. In an interview each and every line of code that you write matters alot. You need to practice writing elegant and clean code and force yourself to use the good programming practices we all know but are too lazy to actually adopt. I strongly suggest InterviewBit for practicing to code. It has extensive coverage of all the interview style questions and their format is such that you get addicted to solving problems since there are daily goals and each question yields some points depending on how well you did in that question. Most of my prep was on this website and it significantly improved my coding habits as well. They have questions based on all the interview topics and commonly used tricks. Like you might not know "Backtracking" and "Two pointers" are 2 very popular classes of interview questions. In order to complete the interviewbit "course" you are forced to clear at least one question from each sub topic. Recently facebook also started collaborating with them to provide their own questions. I know there are others like leetcode and hacker rank but questions here are very targeted.
  • Another common pitfall for us students is that we are not used to test our code. You need to acquire the skill of coming up with complete and mutually exclusive set of test cases which would test all scenarios of your code. Interviewbit actually helps you acquire this as they rigorously test your implementation with all sorts of corner cases and struggling through uncommon test cases like invalid inputs you get trained to write bug free code in the actual interview. Also, even when you get all the test cases running don't forget to go through the solution code and learn from the good practices they use in their code. For example, I adopted the habit of using ternary operators whenever possible which made my code look much more cleaner. Overall I solved around 100 questions twice from Cracking the Coding Interview and around 125 questions from Interview Bit which translated to around 22000 points. Its very important to stay consistent in your prep solving 3 questions every day (21 in week) is much better than solving 21 questions over the weekend and not doing anything else for the rest of the week.
 
  • 3. Importance of Mock interviews: People tend to bomb their first few onsite interviews. Infact I bombed my first 4 sets of onsite interviews before I got enough practice to ace the next 6. You should use mock interviews as much as possible to bomb so you actually learn from your mistakes before going in. Also companies never give you feedback on what you did wrong but your friend / Prof / Colleague can give his honest opinion on where you lacked. Moreover, If you are not well rehearsed you might take pauses here and there or stutter a few times. These are not good indicators for the interviews as it seems to make you less confident about what you are talking about. Communication skills are extremely important to an interviewer so it is important for you to practice them.
  • Have an interview buddy and schedule a at least 15 odd of mock interviews before your first onsite. Mock interviews also help develop a set format on how you would walk an interviewer through the solution and how you would solve ANY problem and use these mock interviews to practice your strategy. I also highly recommend going through these Paid Interview Videos by Gayle Laakmann where she conducts mock interviews and gives feedbacks. Tells you a lot about the interview process and what the interviewer is looking for.
  • Personally my format to attempt any problem was to divide the board into 4 sections, Code, Test cases, Examples and Candidate solutions with time and space complexities. Then the goal was to start from an example, figure out the algorithm to solve the problem, add the solution to the solution section, keep iterating until you find the most optimal solution, have the interviewer on board with your algorithm, write test cases and THEN start coding followed by thorough testing. Its super important that you don't jump into code before actually having a clear picture of your algorithm in mind. I realize it's super tempting to do this specially when you have limited time  therefore the mock interview are to practice and learn to resist this temptation. Writing test cases before writing the code is something that people in industry really appreciate. I had quite a lot of interviewers compliment me when I went to the board and wrote test cases before the function prototype. Moreover, when you are done with the code the worst mistake you can make is to say you are done without actually dry running all your test cases. If your code is already correct chances are interviewer will stop you and move on to the next question or you find a bug so it’s a win-win. Having test cases already on the board helps you remember that you have to run them once you are done with writing the code.
  • Once you have done enough of these mock interviews, you will be on auto pilot mode for your interviews and everything should  go very smoothly. Definitely buy a whiteboard and use it for these mock interviews, coding on paper and computer is very different from whiteboard coding as space is very limited. You need to familiarize yourself to whiteboard coding before actually going onsite. Also help out your friends by interviewing them, it's a great learning experience since you realize how things look when you are sitting on the other side and it helps you improve your interviewing skills. I would recommend scheduling free mock interviews on www.pramp.com which matches you with other students preparing for the same company and then you conduct mock interviews for each other in a 1 hour long session. This reduces the nervousness level when you give an actual interview.


Going in for the interview
A lot of tips in the mock interview section are valuable when going in the actual interview. Its important that you familiarise yourself with the specific interview process of the company before going in. Glassdoor is a great resource as well as quora to read up on others' experiences. You should also do research on the company before going in. For example, the team I was interviewing for at Facebook was working on Facebook ads so I read up on the ads infrastructure of Facebook which really helped since I was asked very targeted questions on improving them. Similarly don't forget to do research on the team before going in and have some very specific questions prepared for them as your questions at the end of interview show what things are important for you and you are being judged on the questions you ask. Just be calm and make sure you are oozing with confidence before you step in because it makes all the difference and for me extensive preparation was the only source of getting this confidence.

  • Resources

Following  are all the resources I used for my interview preparation in the order of importance.



Must do interview questions
Each topic has some building block questions which end up being used by a lot of solutions. It is important that you already know solutions to all these problems so you don't waste time thinking up the solution to these problems and focus on the question interviewer has given you because you will be judged on that. I have included some of these questions but if you go through Interview Bit in detail you would eventually come across/cover most of these questions

  • Arrays/Strings:
  • Determine if a string is a palindrome
  • Merge two sorted arrays
  • Reverse an array in place
  • Find substring
  • All sorting algorithms
  • Binary search in a sorted rotated array
  • Max profit stock problem
  • Matrix multiplication
  • Find all duplicates in an array
  • Print a matrix in a spiral manner
 
  • Linked List:
    • Reverse a singly linked list
    • Delete/Insert a node in a linked list
    • Detect if there is a cycle in the list and return its starting point
    • Merge two sorted lists
    • Split a list into two lists one has even indexes other has odd indexes
 
  • Trees:
    • Check if tree is balanced
    • All traversals, recursive and iterative implementations
    • BFS/DFS
    • Construct a BST from a sorted array
    • Check if two trees are mirror image of each other
    • Find max path sum in the tree, negative nodes possible
    • Lowest common ancestor of 2 nodes in a tree
 
  • Backtracking:
    • Find all permutations or combinations
    • Find all possible subsets
    • N queens problem
    • Convert numbers into words according to letters on an old phone keypad
 
  • Hashtables
    • Questions where you need to keep track of multiple occurences of same object
    • Questions where you want to have a 2 tuple as a key
 
  • Dynamic programming:
    • Given you can climb 1,2, or 3 stairs in one step, how many ways of reaching the top
    • How many ways to go from top left of a grid to bottom right of the grid with some obstacles in between
    • Implement both bottom up and top down solutions for both of the above




Keep in mind that this is not an exhaustive list, only a starting point. You should be doing at least an order of magnitude more questions than the ones listed above.



Choosing a language for interview questions

Generally it's recommended that you use the language that you are most comfortable in or have most experience with but there are some other metrics to consider here as well. In my opinion these metrics are built in Data Structure support, risk of running into language specific bugs and elegance of code on white board. I would try to compare Java, Python and C++ on these metrics. Disclaimer: I am biased towards Java so you might see it outperforming in some/all metrics but this is just my opinion, you can do this analysis by yourself as well. Interviewers generally don’t bound you to any specific language so you can choose any language you want.

  • Experience: This would vary from person to person. Just make sure you don’t solely choose on this factor. I chose C++ just because of this and it took me many failed interviews to realize C++ was not a good choice for me. Don’t be scared to jump into any other language just because you spent only one course using that language. I had little experience with Java but practicing interview questions taught me all the java I needed to know.
  • Built in DS support: In my experience, I found Java’s DS support to be great. Javadocs provide excellent support to understand all the basic functionalities you might need from a DS and its intuitive as well. I didn’t feel comfortable with C++’s DS support as they have weird naming like ordered_set and unintuitive method names. Its also important to see what/how a language allows you to extend their built in DS, I had one interview where I had to design a funky Hash table and when I just extended the Java Hash table by overloading its hash code method to get the implementation done interviewer was happy since I did not try to reinvent the wheel. So it's important to know the all the DS inside out for your language of choice. I have heard python has good libraries as well but don’t have much experience in it to comment on that.
  • Risk of language specific errors: In C++, you need to be very careful with how you manage your memory. You can run into errors like not allocating enough memory, not freeing up memory after using it, failing to check after each malloc if the allocation was successful, running in to dangling pointers and I am sure there would be more. Java on the other hand, has none of these issues.
  • Elegance: This might not be that important but do consider that you would be writing the code on a white board where space is extremely limited and at times it becomes hard to fit in things like std::unordered_set<Node> hash map = …

Also if you have to add extra checks like checking if malloc works, they take up precious space on your board and are not helping interview see how awesome you can code.

I was very happy with my experience using Java but think about all these metrics and think long and hard before diving in your prep with any language.


Common pitfalls to avoid during an interview

These are some of the critical mistakes I used to make and thought it would be good to share them with everyone

  • Not being super efficient with your time: This was a big one, I used to write on the board slowly and neatly, tried to calmly teach the interviewer my algorithm in detail so he was on board on what I was about to do. These are good things but they come at a huge cost, time. Remember, these questions are such that any reasonable programmer would be able to solve so you have to distinguish yourself by producing bug free code in as little time as possible. In a 45 minute interview if you spend 30 minutes on your first question then interviewer will probably not throw a second question at you and just ask you to iterate on the first one giving you very little opportunity to show off your programming skills. On the other hand if a candidate gets it done in 20 minutes, interviewer will give another question and if he is able to solve even the second one in next 25 minutes then he made a great impression on the interviewer. Just think yourself who would you hire the person who did one question or 2 questions. In the interest of saving time, I started explaining the algo much faster aiming to get interviewer’s approval asap and started writing code as fast as I could not caring about how neat it was. Having said that please don’t rush through the interview stay calm and think through everything you do and say but just be super efficient about it and don’t even waste a second of interview time because its going to make a huge difference in the end.

  • Not stubbing out helper functions and wasting time writing irrelevant code: Consider a problem where you have to find all the possible orderings of a string that is also a palindrome. Now the interviewer wants to see how you do backtracking and handle the caveats associated with it. Its likely that he already has confidence in you that you can code isPalindrome function easily otherwise you wouldn’t have made it to the onsite interviews. Its great to just use the isPalindrome function as if it was already implemented and just ask when you are done with the main problem if the interviewer wants you to write out the helper isPalindrome function as well. Most of the time they won’t and you would proceed to the next planned problem. However, if you just start implementing the isPalindrome within your main code you would take 5 precious minutes of your time and if it pushes you over the 25 minute threshold it might cost you the job. So keep an eye out for what is important code and what is just error checks or mundane code that won’t show interviewer how great you are and would just eat up your time

Building a preparation timeline

It's important to create a proper timeline so that you can pace yourself accordingly. I would provide a sample timeline for somebody who starts preparing in October ’16 and wants a job by May ’17. You can translate these dates to the start date you are aiming for. We will backtrack from the anticipated start date. If you want to trigger a bidding war from different companies you need a solid timeline so that you give their interviews in round about same time so you start receiving offers at the same time as well. Otherwise one company will give you an exploding offer with a deadline and you might have to accept it before waiting for other companies.

Anticipated Start Date: 1st May 2017
Receive Offer letter by: 15th March 2017
  • Jobs tend to get filled up a month or 2 before start date
Give last interview by: 1st March 2017 (2 week review time)
Give first onsite interview by: 10th Feb 2017
Start appearing for phone screens: 1st Jan 2017 

January is the prime time for job postings and most of them get filled up by the end of the month. Make sure you are fully prepared before January starts. Last year I had a phone interview scheduled with Linkedin for 4th January and they had to cancel it because the position got filled even before I could interview. 

Start emailing random recruiters with mini cover letter: 15th Dec 2016 
Start Mock interviews: 15th Dec 2016
  • Should do atleast 1 mock interview every day from here on

Apply at the portal of all companies: 15th Nov 2016. 
Start interviewbit.com: 1st Nov 2016 (Get done in 6 weeks)
Start bugging your contacts for referrals: 1st Nov 2016

Its important to get referrals before applying on portals because then your friends would be able to get referral bonus so they have some additional motivation to refer you. Also ask them if you should apply to the portal at times there are different portals for people coming through referrals.

Start CtCi:15th Oct 2016 (Get done in 2 weeks)
Start Writing your resume: 1st Oct 2016 (Get done in 2 weeks)






Best of luck in your job search, if you need any more information, feel free to drop me an email at mohsin80211@gmail.com.
site ip stats