How to get a job at Facebook or Google in 6 months? I need a concise work-plan to build a good enough skill set. Should I join some other start-up or build my own projects/start-up? Should I just focus on practicing data structures and algorithms

Some answers here are already really good, but I think it could be valuable to have the perspective from someone who trained for these interviews very recently and got a job offer as a direct result. So I'm gonna one-up your question and tell you how you can get a job at Google and Facebook in 1 month (1 month's prep, that is.) By the way, brevity isn't my strong suit, so this post might take you a while to get through, but I promise it's worth it, and I'll do my best to answer questions you post in the comments about specifics, because I'm almost definitely going to forget to mention some important things (I prepped for the interviews some 5 months ago so this is based on my memory only.)

I'm going to detail how I prepared for technical interviews in ~1 month, after which I got a job at Facebook. The process of getting an interview all the way up to getting an offer will probably take 1-2 months extra after that. For my own experience during the actual interview process, see Jimmy Saade's answer to What is the software engineering interview process like at Facebook London? Note that this is for the general Software Engineering position (in my case, new grad), and nothing specific like Android/iOS developer, or Infrastructure Engineer, or so on.

The cool and not-so-convenient thing about tech interviews is that you really never know what you're going to get, so you have to be prepared for a huge range of possible topics, some of which are more likely to occur than others. I'll touch on these below and then outline some very important question-types that may arise and that you should be prepared to deal with.

So let's say your interview is in one month. Here's how I would plan said month (assuming a full-time schedule). Note that this is what I would do (and did, actually), so it might not be the optimum approach for you, but I suggest working similarly and switching it up a bit based on how you feel you'd grasp concepts better (e.g. solve and code in parallel, as opposed to what I did which is solve everything then code everything…)

Days -∞ to 0 – Prerequisites

I assume that you have taken an algorithms course and know your way around major data structures including but not limited to: binary trees, binary search trees, hash tables, heaps, stacks, queues, graphs, lists, tries… as well as all algorithms related to them (insert, delete, search, find, find max, find min…) and the time complexity for each of these, at least at a high level. For graphs you need to know searches (BFS and its properties, DFS and its properties including cycle detection and the like) and shortest path algorithms (Dijkstra, Bellman-Ford, and A*) at a bare minimum. If you don't know all these, along with Dynamic Programming, you're going to need longer than a month. Pick up Introduction to Algorithms (CLRS) and start studying them first. (Update: I posted an answer here: Jimmy Saade's answer to What should I know from CLRS 3rd edition book if my aim is to get into Google? in regards to which parts of CLRS are relevant for technical interviews.) This is the easy part, as it's all academic and it's just expected that you know all of it. The part that follows below (Day 1 onwards) is the actually valuable part that I can offer you.

I also assume that you know a programming language like C++ (or Java) and the built-in functions which actually make it useful (i.e. STL or its Java equivalents). (Update 2: I posted info relevant to this here: Jimmy Saade's answer to What are the most important concepts in C and C++ that should be learnt and understood before a programming interview?). If you don't know STL, spend time learning vectors, maps, sets, unordered maps, unordered sets, queues, stacks, and the entire "algorithm" library (seriously, all of it). These are essentially implementations of what you just learned in CLRS, so that if you need to use a heap you won't actually start to code one during an interview (just use a map or priority queue). You also need to know how to implement a linked list, BST, and a trie in 5 minutes flat, which is a lot easier than it sounds (just build a Node class and an insert function and for interview purposes, you're good.)

I do not assume that you know anything about the following topics: parallel programming, computer networks (HTTP/TCP/IP/Ethernet), operating systems/scheduling, threads/processes/parallelism/concurrency, assembly, hardware and hardware-descriptive languages, or whatever else. While these are all valuable concepts to know as a computer scientist (as are machine learning and AI and others), the chances that they come up are close to none unless you state them as skills on your resume, so your time is better spent elsewhere (i.e. working on the topics below). You do need to have some awareness of distributed computing, though, so scroll down to the System Design section for that and make sure you read the MapReduce paper at the very least.

Day 1 – The Book

Buy this book: Elements of Programming Interviews. Phew. That was hard.
In all seriousness, this is the best book on the subject in my opinion, and I'm actually really surprised so little people know about it or use it. (I have no affiliation with this book.) The collection of questions is excellent and to-the-point, it is large (300+ problems, which is the most I've seen in one book), they focus on the right concepts (e.g. several problems are on binary search, which is extremely likely to come up in an interview – more so than any other algorithm), and their answers (and the code provided) are almost all correct and excellent. I say "almost" because there are 1 or 2 problems which have much simpler solutions than the book details, but it's not an issue, especially when you compare it with other programming interview books, which have several answers which are downright incorrect. Plus the online support community is pretty good, with Java code available for all problems (the book has them in C++ only) and an online forum for discussions over at Home – Elements of Programming Interviews. They also forgo all the 'teaching' stuff that other books have where they try to teach you big-O notation and data structures, and focus almost completely on the problems part, which is much, much, much, much more important. The big-O notation and data structures you should learn from CLRS, which is the best resource for them, period. No other book, especially not programming interview books, come close to its quality in teaching that stuff.

I also know (through various sources) that several of these problems are actually asked as-is (or in a disguised form) during interviews, which shows how on-point it is. (I imagine a reason for that may actually be its low popularity compared to other interview books, as companies ban questions that are 'out there' from being asked in interviews, which is why you probably won't see questions from Cracking the Coding Interview.) If this happens to you, however, I suggest you tell your interviewer, as it's very easy for them to tell if you know the problem before or not, and if you just recite the answer it defeats the purpose of the interview. Luckily for me, I wasn't asked any of the problems I'd done from the book.

Days 2-14 – Algorithms Stage

Go through the book chapter by chapter, one chapter per day[1], starting at Chapter 5, ending at Chapter 19. Do every single problem. All of them. (To be completely honest, I might've skipped a few, but this was more by accident than anything else, and I definitely did like 98%+ of them.) Don't code, solve the problems only (i.e. find the algorithm). Give yourself a deadline per problem, depending on how hard the problem is (for example, 10 minutes for non-ninja[2] problems, 20 minutes for gray-ninja problems, 30-40 minutes for black-ninja problems) – if you haven't found the solution by then, look at the answer and understand it. If you don't you won't improve. It's important to think of the problems on your own, because it's the way of thinking that matters, as you can't go and recite the book on interview day. If you found a solution, make sure it's correct, and that you have thought of all corner cases.

Note 1: The new version of the book (which I linked to) has all the ninja problems in a separate chapter (Ch. 22). This, in my opinion, is a terrible idea. The book I had had the problems which are currently in Ch. 22 spread across the book, each in its relevant chapter. I suggest you go through the relevant ninja problems of each chapter while doing said chapter. For example, on Day 2, do Chapter 5, and the Chapter 5-related problems in Chapter 22. On Day 3, do Chapter 6, and the Chapter 6-related problems in Chapter 22, and so on. I believe the problems in Ch. 22 are ordered accordingly (the ninja problems of Ch. 5 come first, then those of Ch. 6, and so on), so this shouldn't be too hard, but I'm not 100% sure as I have the older copy of the book.
Note 2: I sometimes spent hours on a single problem, just because I thought the problem was really interesting and I insisted on cracking it myself. I find these random endeavors useful in the long run, as it develops your critical thinking a lot more than the easier problems, but it also takes time, so you likely can't do this for every problem, if you even want to do it at all.

Days 14-24 – Coding Stage

Repeat the book, this time with coding. You already know the answers, so you should be able to remember the algorithm for each problem pretty quickly (if you don't, look it up. It happens, and it can happen sometimes even if you'd previously figured the problem out by yourself.) This is the coding stage, so don't waste time re-deriving algorithms.

I do not suggest you code all problems, especially if you're experienced with ACM-ICPC, TopCoder, or Codeforces and the like (and really, if you're familiar enough with STL, you probably have a decent skill set). Only write the code for problems you feel have complex algorithms, a new data structure you haven't used before (e.g. unordered map for hashing maybe), problems with tricky corner cases (binary search is at the top of this list as its variants are asked often and can be much trickier than you think) or a programming concept you're not comfortable with (these include, but are not limited to, operator overloading, custom comparators, custom hash functions, custom == functions, and much more…) If a problem proves tricky for you, or you implemented it in a way which you feel isn't optimal, look at the solutions the book provides, which are excellent and clean, and will teach you all of the above-mentioned concepts. I suggest you mimic their style of writing code a bit. Some important-if-obvious notes are: use descriptive variable names (none of that 1-letter-variable-name crap) and indent properly, and don't forget to close parentheses and brackets.

I also suggest you code all problems from the Greedy Algorithms chapter and almost all ninja-marked problems. The Dynamic Programming chapter is also important if you're not familiar with DP, and can be tough to grasp, so make sure you give it its time.

Day 25 – Onto more questions

So now that you've exhausted the best question reserve and are comfortable enough to step into an interview, you… need to prep even more. Go to Google Interview Questions (Career Cup). This is a dangerous place. Some very good problems exist, but there's also a class of problems that my ACM trainer likes to call "Chuck Norris problems": Problems written where the OP has no idea what's going on and suggests the interviewer required linear time for problems that clearly cannot be done in linear time (like this, which is clearly not linear time:…), or similar.

Now that you've finished Elements of Programming Interviews, you should be easily be able to differentiate between good problems and terrible problems. On Day 25, go through "all" (the last 20 pages or so) the Google Questions (even if you're preparing for Facebook) and make a list of the ones you deem 'good', and by 'good' I mean problems you feel might have actually been asked in a Google interview. You know the question style from the book, so you should be able to tell which are legit and which are questionable. I assume you should have a list of something like 80-120 questions in the end, some simple, some not so much.

Also note that very few problems actually have correct answers posted on the site, so mainly you'll have to rely on your know-how to figure them out and make sure they're correct, but given your previous prep you won't find it too difficult to know when you should be sure of your answer and when you shouldn't. This is actually valuable prep for the actual interview, which is a similar experience.

Days 26-30 – Solving Career Cup Questions

Solve all the problems you jotted down on Day 25. Find the algorithm. If you feel it's too difficult, seek help. If you feel it's impossible or the best solution is exponential time, it really might be that the OP was mistaken. Shake it off, move on to another problem. If you still feel like it, code some of the more challenging problems.
Several of the Career Cup questions are similar to ones in the book, so you shouldn't have too much trouble with most problems.

Day 30.5 – Skip Lists (Google-only)

I've heard that Google has recently gotten into the habit of asking about Skip Lists (not sure why). Watch this video:

and understand it and know the analysis of the expected run times. After that, implement and test your very own Skip List. I did this just to practice and because Skip Lists are interesting anyway.

To be honest, Google can be pretty unpredictable with their questions sometimes, in my experience. They might ask general questions about object-oriented programming or computer networking, Linux commands like grep, theoretical things like the proof of the sorting lower bound, coding questions that rely on some math concept you may have forgotten to be solved, or in-depth programming language questions (e.g. functors/operator overloading in C++). I guess it depends on your resume and what you claim to be proficient in, so my advice is not to put anything on there that you’re not at least somewhat proficient in. It helps to have a degree in Computer Science or Electrical and Computer Engineering, really, just based on the huge variety in the possible questions. I suggest a read-through of Get that job at Google (Steve Yegge) and Five Essential Phone Screen Questions (Steve Yegge). You should probably know most of the topics covered here (I wouldn’t put my money on things like threads/processes/parallelism coming up unless you explicitly state it on your resume, though.) Most of the coding questions in the second link are too easy to come up in an interview, I think, so don’t get too excited by them, and I’d skip the “Special Fast Track Version” section. It’s humorous but I thought it’s way too cynical and off-point. Your choice of text editor, knowledge of OS, or knowledge of one vs. multiple languages will not, in and of themselves, make you fail an interview.

On a small note, though I believe Google may ask a lot of non-algorithmic questions as above, the bulk of the interview will still be data structures/algorithms/coding, so all the other things mentioned in Yegge’s blog you should know, but they’re not the main focus.

Day 31 – The Non-Technical Stuff

Okay, so I'm cheating a bit by adding Day 31, but you should also take a day or so to prepare for the non-technical part of the interviews, especially if you're interviewing at Facebook, where there's a non-technical interview. First, prepare questions you want to ask your interviewers about Facebook and about their job and what they do all day. See my Facebook London post for more examples on this. Second, think over your experiences in college/work/whatever – projects you've worked on, teams you've worked with or managed, conflicts you've addressed, hard bugs you've had to deal with, etc. Google-search "behavioral questions" and you'll find thousands of possible questions.

Prepare a non-generic answer for "Why Facebook" (hint: the fast pace and culture, the great talent in the company, the mission to connect the world…) and "Why Google" (hint: the diversity of the endeavors, the awesomeness of search and Android, the mission to do awesome things, the company culture…). I wasn't asked these questions in either company (to my disappointment since I was really passionate about both and couldn't wait to show it), but I squeezed in my interest while asking my questions to the interviewer, so use that opportunity if you really want to impart something that you didn't get the chance to.

Tips for the Interviews

Numbers 3,4,7,8,9 are the most important points.

  1. You might be nervous before an interview, but it'll pass. I was nervous before every single interview. Once the interviewer stepped in and we started talking, I generally had a blast because I really loved talking with them and solving these kinds of problems. Try your best not to be too nervous: do mock interviews and the like. I also recommend scheduling interviews in an increasing-priority order, so that you get used to it and find out your shortcomings by the time you reach your most-wanted company.
  2. Practice coding without a compiler/on a whiteboard/paper. I did neither, but I have the C++ syntax memorized and I'm used to coding on a paper in ACM competitions, so you might not need to do this if you're already comfortable enough with your favorite language (you only need to know one language well, by the way, as long as it's reasonably well-known, like C++/Java/Python. They let you use whatever language you like during the interview.)
  3. Corner cases can kill you. You really have to practice on finding and dealing with corner cases, and/or recognizing what I call "corner-case-prone problems". Some problems are dead simple algorithmically but can be very tricky to code, and I got 2 of these problems, once in my Google phone interviews, and once in my Facebook phone interviews.
  4. After finding the algorithm, stop, pause, and think about how to code it, before you actually do. This is especially true for the harder problems, and I would've failed one of my interviews had I not done this, and as a result, would never have gotten a job at FB. I also might've passed an interview at Google which I failed, if I'd taken my advice in this step at the time.
  5. Think out loud about algorithms/ideas as you come up with them. It's fine to pause and think quietly for a bit, but don't stand there for 3 minutes without a word. Always at least give the simple solution, which very well might not have a great run-time, but it won't hurt. I did it in all my interviews no matter how simple the answer was, but I said them directly and noted that there's probably a better solution, then proceeded to think of that. (e.g: Okay, to search a sorted array, we can scan it linearly, but this is an O(n) solution and there's likely something faster). Also, don't be cocky about it (question yourself out loud until you're sure of your method and have a rough proof that your method works). Don't argue with your interviewer. 99.99% of the time, they're right, and you're wrong. One possible exception to this is if they’re challenging your code: they’re either really pointing out a bug to you, or trying to make it seem that way to see how confident you are in your code and if you’ll agree blindly or protest that your code is actually correct (if this happens, don’t panic, just think well about your answer before you give it.)
  6. Don't talk through your code line by line as you write it. Interviewers know how to read your code and what if-statements and for-loops are. Only speak about the general structure of the code (which you should've mentioned before anyway, as per Tip #4) while coding. Do, however, mention what you're doing in intricate lines of code (for example, if you want to test if 'x' is a power of 2 via "if(x & (x-1))==0", you might want to mention that.)
  7. Questions are so often underspecified, and this is a huge weakness of Elements of Programming Interviews: all problems are specified completely, so you have next to no training on this. Always think of questions you might ask or conditions that might make your algorithm fail if not true. Some examples are: Are all numbers positive? Are they distinct? What is the type of the input (integer/double…)? Can you revisit a grid cell? The book has questions where these properties are specified explicitly in the question: think about what would happen if these conditions weren't there: the solution often breaks down.
  8. Don't give up if you don't think of the answer directly. In my last Facebook interview, I got the most challenging problem yet, and it took me about 5 minutes to get to the answer, and I ended up hired. That was actually possibly *the* interview that got me hired, and it was also the one I most enjoyed.
  9. Two really important concepts to know well are binary search (and its variants) and searching the state-space using Breadth-First-Search to find some shortest sequence of 'moves' (like this problem: ACM-ICPC Live Archive – Kermit the Frog). Both come up very often.
  10. Luck matters. The interview process isn't perfect, and you might not pass it even if you're really good, as it depends on your interviewers and what questions you get (and what type of questions you're strong in, etc.) You can mitigate this factor a lot by prepping a huge amount, but it's always there, and it's important to know. I suggest you read Get that job at Google (Steve Yegge's blog) if you want some more detail about this factor.
  11. Ignore Ch. 20 and 21 in the book. They're not great. (Maybe read through Ch. 21 a bit to get an idea but that's it.) Scroll down to the System Design section if you also have to prepare for a system design interview.
  12. Undersell yourself on your CV (or at least, don't oversell yourself), especially if applying through a referral. If you write 'expert in C++', they're going to call up their senior-most C++ engineer to get you to crash and burn. I've never met anyone who got anything related to multithreading and parallelism in an interview for SWE, except one person who listed it as a skill. And lo and behold, he was asked about it, and it didn’t go so well.
  13. Oftentimes, you'll get a problem which is a variant of a problem you've seen before in the book or on Career Cup, or is the same problem but in a "disguised form" (i.e. it's worded differently but it has the same or a mostly similar solution.) Be careful about these subtle differences; you might figure out (or think that you've figured out) the solution for the problem because you found it very similar to one you've seen before, but a small difference in the problem statement actually means its solution is really really different. As an example, check out question 17.5Search for a sequence in a 2D array – in Elements of Programming Interviews. It includes the statement "It is acceptable to visit an entry in A more than once." With it, the solution is DP. If that statement is not included (i.e. it's not acceptable to visit an entry more than once), the solution is branch-and-bound, and there's no DP involved at all. If you wrongly answer DP instead of branch-and-bound or vice versa, the interviewer will know you've seen the other problem before and think you've just memorized the solution, so that's probably enough by itself to give you a "no-hire" recommendation from that interviewer. (I'd also venture a guess that that statement wouldn't be stated by the interviewer at all first, exactly for this reason, and you'd have to ask whether or not you can visit an entry more than once, as per tip #7. The goal is to see whether or not you'll figure out that there's a huge difference in solutions depending on the interviewer's answer to this question.)

Again, I probably forgot a whole lot of stuff, so if there's anything specific you want to know, leave a comment. I'll also do my best to keep this post updated with whatever other important things I remember later.

System Design

Even though I didn't have one myself, I did prepare for the System Design interviews. I prepared by visiting this site: Hired In Tech, which is decent (not great) and by reading several papers on this site, straight from Google: Distributed Systems and Parallel Computing, mainly the first MapReduce paper (near the very end of the page) and the Chubby paper. MapReduce is very important and I really suggest you read it and understand how it works. After those steps, look up databases, specifically SQL and NoSQL, get acquainted with the CAP theorem, scalability topics, and maybe read up on Hadoop and some problems you can solve with it (Hadoop In Practice is a decent book for these purposes). Try some questions like the "Design a URL shortener" question on Hired In Tech, or something larger scale like "Design a web search engine" or "Design Google Maps", all questions which may be asked (also check Ch. 21 of the book for possible questions and a small idea of how to answer them – though the book's answers aren't great.) But in general, for the system design interview, practicing on questions is less meaningful than fundamentally understanding the above concepts and knowing how to discuss them, as the entire interview is something like a quick conversation between you and the interviewer, where he/she will change the question specifications on the fly to see how you deal with different scenarios.

Final Advice

So, if you really want that job, it’s going to take some time and dedication, but hopefully it’s the enjoyable kind. I personally really enjoyed preparing these kinds of questions and found that, job aside, I really learned a lot and got a good deal of knowledge out of the preparation, and you probably will too.

My final piece of advice is to just go into the interview and not be stressed out (this is obviously easier said than done). The engineers want you to be good and they want to hire you – hiring is a pretty expensive process. Some may be easygoing, and some may be less forgiving, but in all cases, the interview is very similar to a conversation between two engineers, and that’s exactly what these companies strive for the interview to be, so just treat it that way, and if you’ve prepared well, it’ll show.

[1] – One chapter per day is actually a bit slow since you're not coding, so for shorter chapters such as Chapters 5, 7, 8, 9, I suggest you do 2 per day, which is feasible.
[2] – In Elements of Programming Interviews, non-ninja problems are standard problems, gray-ninja problems are somewhat difficult, and black-ninja problems are difficult.

Disclaimer: This is my own opinion/advice, and is not endorsed by anyone else in any way.

19 Replies to “How to get a job at Facebook or Google in 6 months? I need a concise work-plan to build a good enough skill set. Should I join some other start-up or build my own projects/start-up? Should I just focus on practicing data structures and algorithms”

  1. Let's break this into sections or skip to my free guide here

    Coding Development:

    • Build up your knowledge of Java, Swift and HTML and algorithms and data structures
    • Enter competitive coding competitions to 'force progress'
    • Attend interviews at lower level companies to force yourself to brush up on code
    • Submit code to some open source projects
    • Develop an App or Website for a commercial project for a friend (so you feel morally obliged)  that sits just OUTSIDE your range of expertise

    Academic Development:

    • If you're in college/university aim to get top/as close to top GPA's/results across your courses as you can
    • It pays to know an 'in-demand' language such as Russian or Urdu or Spanish

    Personal Development:

    • Not everyone is applying for SDE jobs; so it pays to have an interesting outside skill
    • If you have a hobby you are involved in; pursue it more rigorously
    • e.g. if you do cross-fit; enter a cross-fit competition
    • If you run, enter 2x 10k races
    • If you play chess, enter a competitive chess competition
    • If you DON'T have a hobby. Find one

    Resume preparation:

    • 3 million people apply. 7k get jobs. Probably 20 people for every job are interviewed (educated guess)
    • Getting to interview is tough. You need an amazing resume
  2. Nick a template from here. Don't make THESE mistakes
  3. Once it's ready have it reviewed by a current/ex-googler/by me/on Quora. Don't ASSUME it's good enough
  4. Interview preparation:

    • I have 60 answers in the area of Google Recruiting on Quora where I'm a most viewed writer
    • Get reading
  5. Read anything by Gayle Laakmann McDowell
  6. Look up programming/otherwise questions on Glassdoor
  7. Practice with a friend
    • Then practice again


    • Get to know someone at Google to get a referral
    • Review your progress at 1/3/5 months
    • Smile; try and enjoy it 🙂

  8. Myth – It takes people of Very reputed Universities to get job at Facebook or Google.

    Reality – Far from truth, both these companies have a considerable number of people coming from not so reputed universities. The most intelligent people happen to be in top universities, hence they are seen more often.

    To get job in Google and Log In or Sign Up, you have to be really best in your field. Here it seems you are looking for a computer science job, be very clear with logics, Oops concepts, Data Structures and dynamic programming.

    If you can answer these questions at one go, you will get through any interview in world.

    If you still feel, you are good at logics, try answering these questions on your C++ or Java compiler.

    • Find the second largest number in an array and sort the array.
    • Write a Java program to print Fibonacci series upto 100?
    • Write a Java program to prevent deadlock in Java ?
    • In an array 1-100 exactly one number is duplicate how do you find it?
    • Calculate Factorial of a number
    • How do you sort Java object using Comparator?
    • Print out all leaf node of a binary tree?
    • Difference between linked list and array data structure?
    • How do you find middle element of a linked list in single pass?
    • Print all permutation of String both iterative and Recursive way?
    • Write a function to find out longest palindrome in a given string
    • How to check if two String are Anagram?
  9. Guys, I hope this doesn't come across as obtuse, I would just like to share with you what I've learned in my years of employment. Though I haven't worked for Google directly, I was previously a VP of a billion dollar software development company. A company Andy Rubin was very interested in I believe.

    If I understand Google correctly, and I believe I do given anecdotal evidence, they don't want thought followers – they want thought leaders. The kind of people who invent YouTube. As an aside, I would mention I conceptualized the YouTube idea in 2000. My girlfriend at the time thought the name I'd given it 'TubeTV' was funny…

    Bottom line, forget everything you ever heard in the 'text book' world of how to get a job. There are far too many people willing to follow that tired old line; it's sooo 20th century. Google think out of the box, you need to too. That means; develop yourself, your passions, your instincts and abilities.

    Be creative, be innovative! Give Google good reason to want you!!!

    Footnote: The greatest thinkers never even had to think out of the box.
    Why? They never knew 'the box' existed; they ignored the conventions.

  10. Being from a top school is far less important than is having made some impressive accomplishments or contributions to other projects. Create a cool product, or make some substantial advances in an open-source project.

    Getting a Google employee to submit your resume does help a lot in getting past the huge number of unsolicited resumes.

    You should know basic computer science very well before interviewing. Read Steve Yegge's great advice on how to prepare for the interview at

    Look at the first pages of Gayle Laakmann's book to understand Google's interview process,

  11. while(1)
    Programming Interview Questions | CareerCup;
    Sphere Online Judge (SPOJ)
    TopCoder, Inc. | Home of the world's largest development community.
              goto interview;
         catch (Exception disappointment) {
    //  Don't lose hope. Try again.

  12. This answer is my journey from the person who was scared of programming interviews, to my present state as having cracked the Google Interview and as a programming interview coach.

    A slow and steady practice for several months will help you a lot more than a intense practice for a few weeks. 6 months is an awful lot of time.

    With tens of thousands of programming questions, hundreds of websites, and dozens of books, preparing for programming interviews may be intimidating.   So I've created a checklist of the topics needed to prep for programming interviews.

    Topics to prepare for Programming Interview

    •Knowledge based questions
    oJava language questions
    oCore computer science concept questions

    •Data Structures
    oLinked Lists
    oHash Tables
    oTrees, Tries and Graphs
    oStacks & Queues

    oDynamic programming
    oTree traversal techniques
    oSearching and Sorting techniques

    •Behavioral questions (least important)

    •Code complexity

    •Design Questions

    oSystem design questions
    oObject Oriented design questions

    •Popular interview questions

    The details about this checklist is here:
    Hacking the Programming Interview – 1 by Ash Murthy on Random Rants

    Once you have familiarized yourself with the basic concepts, it is time for practice. Some popular websites to practice interview questions are:

    • Programming Interview Questions | CareerCup
    • LeetCode Online Judge
    • GeeksforGeeks | A computer science portal for geeks
    • Coding Interview preparation made easy

    Practice without your IDE (use online text editor – collabedit or something similar) to solve the problems and then try to run your code .  With practice, see yourself getting better and better — your code will become almost ready to compile and bug free!

    But of course, the long hours of problem solving can be frustrating. Network with others and solve problems in a group setting, and this won't feel so frustrating anymore.

    And in the last month or so:
    Lastly, ask a friend or better yet, hire a professional to help you with mock interviews.  Identify  areas of improvement and work on them.

    If you are in the San Francisco Bay Area, don't miss  the Programming Interview Prep Meetup.

    The group meets every other Friday, and each meeting focuses on a specific topic.  Participants form groups based on their skill level, and solve questions as a group.

     By participating in this meetup, you get to solve problems in a group setting (which is more effective and fun than lonely practice), and more importantly learn from other others.

  13. I'm assuming that you mean to get into Google with a CS related job.

    I would say there are 3 main ways to get into Google.

    1. Through internships. Google take in more than 2000 interns every year from a list of more than 50000 applicants from all over the globe. You shall have atmost 3 technical interviews and a couple of host matching interviews which are mostly informal in nature. If you do get in, you shall have the opportunity for a full-time conversion to get that job at Google.
    2. As a University Grad. These are students who are just out of the University and are seeking a job. It will be much more difficult to get in this way when compared with internship. The technical interviews shall be tougher, but you may be competing with fewer candidates.
    3. As an experienced hire. This will give you an edge to gain some experience working in some startups, learning new technologies, proving your leadership skills, cultural fit, ability to work well within a team, your programming expertise and so on. Recruiters all out to grab such experienced candidates. You always hear of stories about one working in X getting recruited by Y.

    For all the ways mentioned above, you need to have some basic qualities too.

    1) Have a strong grasp of data structures and algorithms

    I'm talking about lists, binary trees, heaps, hash tables, suffix trees, tries. You never can say what you shall get asked. Your friend might be asked about hash tables, but you may be asked about suffix trees.

    Start with understanding the basic theory behind each of these data structures. Try understanding how the creation, insertion, deletion and searching operation works in these data structures. Try understanding in terms of asymptotic analysis.

    Once you figure those out, try to code them in languages like C on paper. Dont forget the edge cases. Then code them in computer. Try breaking your program with valid inputs. When you find one, try incorporating that into your program.

    Rinse and repeat that for common data structures. Head over to LeetCode Online Judge and start doing those problems. You may have difficulty in the beginning, but with time you shall improve. Also use other competitive programming sites like TopCoder, SPOJ, Codeforces, CodeChef and HackerRank. Try reading books like Cracking the Coding Interview from Gayle Laakmann McDowell, Programming Interviews Exposed, Competitive Programming 2. Dont just read them, but code them!

    2) Open Source contributions

    These may not matter much to experienced candidates, but to prospective interns and graduate hires, it does. It shows Google how much passion you have. Plus, they can review your code and see how well of a programmer you are.

    Head over to GitHub, and start searching for projects that you can contribute. I would advise you to pick either C++ or Java, but Python may be a good choice too. Fork it, and read through the code and understand their style of programming. Try finding out bugs, commit and push!

    You can make your own projects too. Try thinking about a problem you may have. If you have a problem, chances are others may have the same too (If you look at how startup companies are born, you will understand). Try solving it and make that project.

    3) Internships

    I would say, this shall score well above open source contributions if you have done an internship at some good CS company (say X) with a meaningful post. You can list out the experiences gained, responsibilities held, and how the company benefited with your internship.

    Did your code improve the some of X's products? Did it make faster, more user-friendly? Did it make more profit or name for X?

    4) Resumes and CVs

    Already too much answers had been written about this topic in Quora. You can search for it, or just visit: Resumes and CVs. Definitely a topic worth following!

    5) Startups

    Did you start some startup and made a truckload of money?
    Did you start some startup and fail miserably?
    Did you create some app thats been downloaded more than a 10000 times?
    Did you start a website thats been visited by more than 10000 visitors each month?

    Put that on your resume!  People do want to hear about your experience.

    Put in hard work. You may not get in the first try, maybe not the second try either. Put in enough effort and you may be in the third time!

  14. While gaining 2 years professional experience, you should increase the number of people you know at each company to include at least 1 that will refer you internally for a job (in addition to getting a good grasp of algorithms and data structures, which seems to matter for Google). That is about the only way to be guaranteed an interview at each company. Once you've done that, then it's all about not failing the interview (mostly luck if you've studied the basics).

    From what I've heard, the Facebook interviews are fairly routine, the Google interviews have gotten a lot easier (and are almost laughable now), and you'll either cruise through, or crash and burn. It's almost as though they decide whether to hire you before you set one foot into the interview, and everything else revolves around that decision. For Facebook, because the questions aren't anything special, they'll expect you to solve them correctly the first time and without mistakes or hiccups (but this should be fairly easy if you've practiced/prepared well).

    Also, while these two companies still have positives surrounding their brand, they are getting on in size/BS and many qualified candidates are choosing to work elsewhere (…startups?). This means less competition overall and is a trend that will be even more noticeable/true in 2 years. So while you work on bettering your skills and network, you should also widen your perspective enough that you'll be aware of other great companies that come along, and will be less likely to waste time and energy trying to join any that are "old news" or that are no longer as advertised.

  15. Apply to google/FB now. Apply other places too.

    Get a job somewhere; possibly at a startup; possibly at your startup. If it's not at Google or FB, apply again in a year if you really want to.

    You can get yourself a DS and algorithms baseline by blitzing through an interview questions book or website in no more than 2 weeks, if you have exposure to these subject before (which you should since you have a CS degree).

    Emphasize your background, your strengths, and your portfolio.

    Don't stay free for 6 months unless you know you'll produce some really good projects to add to your portfolio, or unless you have some other reason not to get a job during that time.

    If you go the startup route, be aware it doesn't have to be "real". Many multi-million-dollar exits are for startups whose main product gets canned the instant its acquired; In retrospect these are all just glorified portfolio projects. Don't be afraid to call your own glorified portfolio project a startup. (I'm probably sounding cynical; I don't mean too, nor am I dismissing the very real talent of acqui-hired startups.).

  16. 1) Be perfect in one language .
    2) Refer Bible (Introduction to Algorithms is a book by Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein)
    3) learning concepts of approaching a problem is one part , solving exercise is another part .

    All the above will make you a strong contestant .

    Know how question varies for a particular situation by participating in online judges like Sphere Online Judge (SPOJ) , ,Project Euler .

    4) Show-case your caliber and passion by participating in top-coder .
    5) Refer Theory of computation (most important in my view)
    6) play with linux flavor O.S .

    Be updated with latest interview question from GeeksforGeeks – A computer science portal for geeks and Programming Interview Questions | CareerCup

     And last but not the least , try contributing to online forum something like Stack Overflow .Because teaching will sometimes make concepts clear that will give you reputation as well(being human) .

  17. I can't help to share my experience with you because I prepared my interviews within 2 months! Since you have more time, definitely you can do a better job.

    • If you are already quite familiar with data structure and algorithm, you can skip this point. Otherwise, do spend enough time on this. I can't emphasize more about this point since it is the most fundamental thing for a software engineer interview. If you fail to get a good grasp of those basic data structures you learnt at school, you just failed the whole interview. I'm not exaggerating, once you've been thru several technical interviews, you'll realize how important it is. Books about data structure and algorithm are everywhere, do make sure you are very clear about basic stuffs like binary tree, queue, stack, linked list and so on.
    • After the 1st point, I expect you to have at least 4 months left. Please dive into real interview questions as much as you can. There are tons of resources online like where you can access countless real interview questions from companies. Since you are targeting Facebook/Google, spend most of your time on real interview questions from these two companies. Don't expect to have the same interview question you prepared (though it's possible), but practicing with real interview questions will help you be aware of the difficulty, style of each company and what they really care about.
    • Practice writing code on whiteboard. This is what most people ignore. It looks quite simple at first glance, right? But it isn't once you try it. You'll miss so much about those fancy shortcuts on your favorite text editors and IDEs and what's more, it's so inconvenient to modify the code like inserting another piece of codes in between. But you have to get over it as most of the real interviews will ask you to write SOLID code on whiteboard. It doesn't need to be compiled, but it should be almost there. No pseudo code! This is even true for Google/Facebook interview as during the onside interview you're gonna be "locked" in a meeting room and keep writing code on whiteboard.
    • Practice with mock interviews. It's a great experience for you to practice in a way where you can't fail. You can do this with your friends and interview them back. I also got my mock interview from whose interviewers are working at Google, Facebook etc. and gave me tons of feedbacks.

    Personally mock interview is the most effective approach I've ever had because you will have totally different feeling when thinking and solving problems in front of a person. You'll be nervous, and you may fail even at the simplest question.

    Also interviewers from real interview won't give you any authentic feedback, they can only tell you those official response, which is no other than bullshit. However a mock interviewer will help you improve in every way especially he/she is experienced.

    In short, 6 months is way enough for you to prepare job interviews for Google/Facebook. Do spend enough time on data structure and algorithm, which is really foundation of every SWE interview.

  18. I worked at Google and did a lot of interviews so I think I can give good advice on this, at least assuming you are looking for a software engineer job. There are two steps.

    1. Get an interview
    2. Do really well in the interview

    Getting the interview is easier. If your resume can't get you an interview, you have to make your resume better. Either work on some open source or personal projects, or get a job that's a "step up" from your current job.

    Doing really well in the interview is harder. It helps to practice interview questions with people who are better programmers than you are. Find those people, get them to practice with you, and if they think you are nailing it, you probably are.

    In practice, there's not a quick fix. In the long run, try to find a job where you work with the smartest people possible, do a great job, and iterate.

  19. Write code.  Write a lot of code.  Solve a number academic problems – e.g. get one of the problem sets for dynamic programming, get an accessible book on algorithms like Sedgewick's and DO ALL THE PROBLEMS.  Even if you resort to typing in answers do them.  (It's not a bad idea to take the version for a different language and translate them into the language of your choice.)  Understand the sorting algorithms, understand Dijkstra's algorithm.

    Become fluent and comfortable in a language.  It's extremely unusual for implementation language to matter in an interview but saying you know say for example Go while not actually writing Go (or idiomatic Go) is a bad idea. If you're the kind of person who would pass a loop you're the kind of person who will be agile and able to pick up a new language.

    In my loop at Microsoft (successful, many many years ago) my worst interview was where I claimed to understand Lisp and then completely failed to deliver on finding if a list had a loop.  In my (successful, very recent) Google loop my worst interview was where the interviewer asked me to implement the one sub-technique to a sorting algorithm that I had skipped (humorously I remember it passing through my mind and I explicitly wrote it off…).  It flustered me and I tanked that one.  (I still made it but when I pass that interviewer in the halls I wonder if he wonders why I got the offer… :-} )

    If you are going for a research position then I think you need to demonstrate some serious CS theory chops but I'm more of an engineer/builder type so I didn't spend much time there other than getting over my fear of dynamic programming.  Do be ready with O(n) analysis, a lot of it, I was weaker than I should have been here.

    In the end you want to demonstrate problem solving skills and fluency in the solution space.  There's a lot of talk about which language is best but really to a large degree all the procedural languages have approximately the same shape, it's a matter of how much boilerplate you have to write so just pick one and get great at it.  I would pick either C++ or Java assuming you're starting from ground zero; Go is not a bad choice either although somewhat risky if your interviewer doesn't know it yet.  If you want to do front end programming, Javascript could be a good choice although lack of formal structure declarations makes it harder to get your data structures recorded somewhere.

    Hope this helps.

  20. No specific language is really required to get an Internship.  Knowing data structures and algorithms will help you a lot more.

    On the other hand, once you get an internship and want to do well in it (in order to get a full time offer), knowing a language well will definitely help you.

    For Google, that means you should know either Java or C++ well (for backend work), or Javascript (for FE work).  For Facebook and other companies it might vary a little bit (Facebook uses PHP, MS uses C#, Apple uses ObjectiveC, etc)

    What will really help you is having some real experience working on bigger projects.  Try either contributing to open source, creating your own side project, or helping out on something that's going on in your school.

  21. Thanks for the A2A.

    I cannot guarantee, in good faith, that you will get a job at Facebook, Google, or anywhere else, given any advice I might give you in this response.  (Consider the fact that others who are seeking employment there would be getting the same advice, and there may be more of those people than there are available positions.  If this is the case, some people would not get hired.)

    I would, however, suggest that you do things that would impress people at Google, Facebook, etc., such as working on open-source projects, code jams, etc., where you can showcase your skills.  If you can impress them with things that they feel are core to their business, that could also help.

  22. To crack the Google Interview you have to Eat, Drink, Sleep, Shower, Play, Love, Wear, Drive, Pee, poop and Vomit Code, Algorithm and DS.(e.g. In C++,JAVA,C#).

    This article explains detailed information to prepare Interviews for Google Software Engineering Jobs.

    Year 2015 version – How to crack the Google interview

    [ General Answer for the technical interviews in MS/Google/Amazon/Facebook/Apple etc]

    Remember : The technical interview depends on various parameters, From employer side e.g. job title, responsibility, department, project type, technology type, skills type, years of experience, mind set of interviewer/interviewers, immediate requirements, firm decision for hire-nohire and many more. From candidate side e.g. the way CV (resume) was presented, the way the candidate carried the technical/non-technical discussion and many more )

    I may not suggest any particular website/or toughest questions to prepare for such/interview preparation,However  most of the questions includes the trick,presence of mind, and how well you understand the most needed concepts of computer science, and most important one is : Algorithms and Data Structures. Questions may be different but all uses the very basics DS/Algo concepts to solve that)

    Still Sample Questions  (depends SDET or SDE  postion[ If SDET then test cases too))

    [+] Given a set S of n real numbers and another real number x, determine whether or not there exist. two elements in S whose sum is exactly x.

    [+] Given a list of numbers (a fixed list) and another list, write a function which determines whether any element in the second list appears in the fixed list.

    [+] use a trie data structure to store words. every node contains a list of all letters (pointers to the same node structure) and flags for each letter to indicate the length of the word. Write a method to insert into this kind of data structure. What would you use to store each node?

    Many more….


    You may design a approach which best suits to your skills/(and many others) related parameters

    Example: someone may use  the following approach, for a two months plan – around 250 hours to prepare software engineer/software engineer in test type of interviews for MS/Google/…

    Actually all these companies e.g. MS, Google, Amazon, Facebook, Apple follow an approach on which that measure the thought process of a candidate.

    And they use different means to evaluate that, but yes most of them uses Algorithms/Data Structures/Open-ended questions(If you have applied for a software engineering job) as one of the approach to evaluate the talent.( As those are the base to develop the technologies).

    To be accustomed with algos/data structure/coding , you must have understood/practiced the minimum e.g. :

    (Step-1): You should have practical understanding of the Algorithms (e.g. When to use BackTracking, When to Use Divide and Conquer, Why double hashing required?, Where brute force concept can be applied?) (50 Hours).

    (Step-2): You should have practical understanding of Data Structures e.g. (Practical use cases related to :when to use circular buffer , or when to use adjacently list or the combination of both or something else to solve the problem ).
    (50 Hours)

    (Step-3) : You must practice several coding problems to implement the things which learn from Step-1 , and Step-2 (you may do the following choose any coding language for the choice of yours (C, C++ or Java or Python or PHP or any one else ).
    (50 Hours)

    (Step-4): Solving the problem doesn't mean just to solve it, but to understand the best way to solve it e.g. The given technical problem can use various ways to come to solution, and you might want to use the optimal one. (How you connect the given solution with the computing/memory resources e.g. Memory/Processing Power)
    (50 Hours)

    However the Most Important One.

    However other than programming you might need to understand the main concept for the interview is to keep the interview active and this requires some action from your side, such as the following:

    You need to talk.

    You need to explain.

    You need to discuss.

    You need to express your views.

    You need to understand clearly the questions given to you.

    You need to understand the interviewer’s expression and mindset to un- derstand those questions.

    You might need to ask appropriate questions to understand the question or any other discussion item. (50 Hours)

    And also :

    Prepare : "Please tell me about your self" , "Your skills related positive/negative further interest" , Basics for the most needed computer science concepts or anything as you presented on your "CV/Resume".
    (10 Hours)

    Above is just a sample plan, you may customize the way you want(e.g. 50 hours to 10 hours or something else) – Click to Amazon, to find the best books you might need (e.g. cormen algorithms)

    (Here Google doesn't mean the Google, it means any company which is very creative to introduce the computer science related products ).

    (Assuming you are spending 4 hours everyday )

    Why Google will not hire you ?,

    Here Google doesn't mean the Google, it means any company which is very creative to introduce the computer science related products e.g. Google, Microsoft, Apple, Amazon, Facebook, ..or any one else which you feel to be a reasonable fit

    Please see the attached ppt, that provide few points that might be helpful to plan the missing things around you If exist.

    Why google will not hire you

  23. Let me be practical and precise to help you in real example:

    Job Requirement in Google right now:


    • Lead the test effort from planning and organization to execution and delivery. Develop effective test strategies.
    • Write or contribute to test plans and/or test cases in medium to large sized projects of moderate complexity.
    • Advocate for and educate product/project teams on test design and implementation. Work with those teams to evaluate testability of new features/implementations.
    • Use your knowledge of testing and testability to influence better software design, promote best engineering practices, bug prevention strategies, testability, and other quality attributes across products.
    • Demonstrate intuition and knowledge about how to break software by finding bugs, and apply this knowledge with measurable result, impacting the quality of the product.


    Minimum qualifications:

    • BS degree in Computer Science or equivalent practical experience.
    • 3 years of experience developing test automation in C++, Java or Python.
    • Experience in writing test plans, providing consultation, creating test cases and debugging
    • Experience testing methodologies and software development life cycle

    Preferred qualifications:

    • Master's degree in Computer Science, Mathematics, or related technical discipline.
    • 6 years of relevant work and industry experience.
    • Experience with Selenium/Webdriver.
    • Proven project and team leadership skills.


    Search Jobs – Google Careers

    Once you see this advertisement ,which means, you have six long years to construct yourself in following ways :

    Learn Selenium Webdriver:

    Some starting level books you can refer:

    Once learnt, apply for INTERN in Google:

    Search Jobs – Google Careers


    • Specific responsibilities vary by project area.


    Minimum qualifications:

    • Currently pursuing a Bachelor's or Master’s degree in Computer Science or related technical field.
    • Must be currently enrolled in a full time degree program and returning to the program after the completion of the internship.

    Preferred qualifications:

    • Experience in systems software.
    • Expected graduation date in the Spring/Summer of 2018 or late Fall/Winter 2017.
    • Completed projects or classes focused on Data Structures and Algorithms.
    • Knowledge of Unix/Linux or Windows environment, and APIs.
    • Familiarity with TCP/IP and network programming.
    • Implementation skills (C++, C, Java, Python).

    Once intern is completed, go to other companies to work for 6 more years and come back to Google as Senior Engineer!

    UPVOTE my answer if it is practical!

  24. Pitching Yourself To Facebook & Google

    According to Wharton School of Business (Student Engagement & Entrepreneurship Director) there are eight essential steps you need to take in order to Pitch Yourself Successfully;

    1. Developing a long-term strategy for engaging with the firms.
    2. Developing your own value-added pitch.
    3. Contacting the firms in a proper manner.
    4. Following Email Best-practices.
    5. Proper preparation for interviews.
    6. Correct follow-up processes.
    7. Opportunities to connect via Venture Capital companies (VC's).
    8. Other Best-practices.

    If you want to learn the secrets on how to get a job in that dream startup…then watch: Pitching Yourself to Startups

    The author has curated this video and has no affiliation with Wharton School.
    "Save time, Learn more"

  25. There's a few parts to this answer.  I can only speak to my experience at Facebook, though I doubt the other companies are very different.

     – Is there some criteria for a minimum number or particular set of languages to know?  Definitely not. What matters is your ability to solve problems, and to demonstrate expertise with some language. 

    – However, the work you do in your internship may have no relation to what you've done in past.  You might be asked to pickup an unfamiliar language, and that will be easier if you already have a few under your belt.

    – The only reason it might be valuable to learn a new language outside of pure necessity is if it teaches you something conceptually new.  On that basis, there's zero reason to learn both Python and Ruby, or java and C#, etc.  They are just too similar.  If you show up with experience in C++, JavaScript and Haskell that's way more interesting to me than Java, C++ and C#.

    – Focus on doing interesting, challenging projects.  If those happen to involve new languages, all the better.

    – The more specific the thing you want to work on, the more important specific languages will be.  If you want to do work on iOS apps at Apple I imagine knowing Objective C is helpful.

Leave a Reply

Your email address will not be published. Required fields are marked *