Message on Whatsapp 8879355057 for DSA(OA + Interview) + Fullstack Dev Training + 1-1 Personalized Mentoring to get 10+LPA Job
1 like 0 dislike
1,639 views
by | 1,639 views

3 Answers

1 like 0 dislike
Best answer

I remember searching for the exact question when I was interviewing at Google a few years ago. It’s funny answering a question you originally wanted to ask.

Disclaimer - I managed to secure the offer even after messing up the timings of my preparation, but that shouldn’t reduce the weight of this advice. Trust me, last night preparation is not something you want to do. I recall being with a friend going through ‘Cracking the Coding Interview’ till late hours, a day before the interviews. Ironically, the sections we prepared weren’t even supposed to be part of the interviews, but that’s another story.

Looking back, I made a few mistakes leading to this last-minute ruckus. Once I had received the invitation for interviews, I had started off well. My strategy for interview prep was simple,

‘Plan, Execute, Win’

It consists of three stages, planning the preparation, sticking to the plan and finally, giving the interview with a clear-headed mind and securing an offer.

Pretty simple, right?

Unfortunately, I almost forgot the last two parts (out of only three!). I spent so long planning i.e. reading blogs, browsing Quora/Reddit for resources, that I missed what matters - following the plan!

However, I later realized I wasn’t the only one messing this up. Most of us are guilty of it. We continue to work on our perfect plan, reading countless life hacks, productivity tips, self-help books. All while missing the critical part, following the learnings in our lives.

Let me assure you that you’ll never get the perfect interview prep plan. No matter how many blogs, questions, interview resources you read. The best advice I can give is to stop planning and start executing.

If you’re looking for a prep plan to get you started. Here’s the most effective plan to prepare for a Google tech interview,

  1. Take a deep breath. Close your eyes. Relax your mind.
  2. Close the Quora app.
  3. Go to http://leetcode.com, solve the first question you see.
  4. Repeat every day.

That’s it. Trust me, this will be all you need. Once you gain momentum following the above routine, slowly increase the load and add additional tasks.

Take it from someone who’s been through this process a lot of times. No plan is better than an executed plan.

In the end, the interview worked out for me. A few last-minute heroics managed to save the day. Although, I’m sure you won’t need such acts of valor if you start now. Carpe diem!

“Do as I say, not as I did”

by
selected by
0 like 0 dislike

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

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.

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...)

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: http://www.careercup.com/question?id=14951746), or similar.

by
edited by anonymous
1 like 0 dislike

The following opinion is based on my experience sitting on a Google hiring committee for software engineers in 2013. I am no longer at Google, so things may have changed. Google is not a static organization, but it is a big company with lots of momentum. Culture and size can make any change slow.

It may be easier to get a job at Google than people think. Google seems to constantly be hiring. They troll the college campuses for young talent. If you get an interview, meet their requirements, and nothing unfortunate happens in an interview (e.g., bombing questions with more than one interviewer) then you will likely be offered a job.

What makes it hard for some people is that they don't meet the requirements and don't understand why that is so. For better or worse, Google has a type. It is hard to get through their interview process if you don't meet that type. Google's process produces few false positives. The downside is that it probably increases false negatives.

The best way to describe the type is "generalist". Software engineers are typically not hired for a specific position. They are interviewed for a certain breadth of knowledge and ability to solve problems. The type selects for people who are more systems oriented. If a person has a narrow domain expertise and has trouble thinking outside their domain, they very likely will not do well in the process.

Interviews are done by other engineers, most of whom are senior or higher. The engineers rate the candidate's answers to calibrated questions and give a numeric rating. Believe it or not, the candidate is graded less on the ability to quickly give the correct answer (which, btw, won't hurt) and more on their ability to think through the problem and produce a sufficient solution within a range of good answers. A non-optimal solution won't hurt you if you have demonstrated a logical thought process, and identified and solved the key problem points.

Your maturity as an engineer will be judged on your interactions with the interviewer. Typically a less senior candidate will just try to solve the posed problems. A more senior candidate will ask good questions to better define the scope of a problem and to ferret out reasonable assumptions. If you are junior and think you can fake this by asking lots of questions, you are mistaken.

The hiring committee reviews the reports and makes a determination to reject, interview further, or make an offer. If the candidate passes the hiring committee, their resume and interview reports go out to the groups that have open positions to see if anyone is interested in the candidate. I don't recall seeing a situation in which someone made it through the interview process successfully and there were not one or more groups interested in bringing the person on board.

A few points about the hiring committee process:

* One bad score is not a black ball. I was in a couple of conversations in which a single low score was questioned and the interviewer called in to give more information to resolve discrepancies between reports. Those typically result in having a further conversation with the candidate to resolve any concerns that may have been expressed by the interviewer.

* Because Google has a type, there were not many occasions in which a person had one bad score. Either all came back with varying degrees of positive, or there was more than one bad report. When there were multiple bad reports, any positive scores were on the low side of positive. That strength of correlation speaks to the culture of Google and its desire to protect their requirements and type.

* The people on the hiring committees are very conscientious. They are protective of Google culture and standards. They aren't looking for reasons to reject a candidate, but have no trouble rejecting someone who falls outside the Google type. If they think a person falls within type but there are concerns, they usually did a follow up. I thought this was extremely fair to the candidates. It is something people outside of Google probably don't realize.

One last point, if you don't get an offer, it doesn't mean you aren't a good engineer. You may fall outside of Google's type. That shouldn't be taken as a personal judgment against you professionally. Also, Google does have false negatives in the process. The number of good candidates who want a job at Google makes this only small problem for the company.

I did see candidates rejected by the hiring committee because weren't ready for a job at Google. Typically, that happens because the proper breadth of knowledge wasn't demonstrated, but everyone liked the candidate and thought they would be a good fit with a couple more years of experience. I don't know how well that is communicated when a candidate is rejected. But, if you have your heart set on getting a job at Google, it is good news for you. Try to get feedback about areas of deficiency. Work on those and reapply in a year. A reapplication after a year won't be rejected merely because you didn't pass muster the first time around.

by Expert (108,100 points)