Problem solving:
First book - Cracking the coding interview (CCI) is invaluable for the tips it provides for the preparations. The best being - stop coding in an editor. Code on paper. I did that diligently for about 50 problems. Write once, scratch it, write again, scratch again and write again, work through the tests, make sure things are good before calling it done.
What did I really write on the paper?
HiredInTech algorithms course is a beautiful course which provides the right structure to approach a problem - Algorithm canvas. Diligently followed this. Really really invaluable.
What problems did I select?
I picked problems from CCI, searched for similar problems on Leetcode and coded them on paper and then submitted them online. Sometimes, I wouldn't see the code on paper and later figure out that I had omitted a single line which was causing WA :-) My code on paper was pretty close to being AC (Accepted.)
I bought a book from Leetcode containing 50 problems from different areas and coded them on paper first, then submitted them online. The best part of the book is that it gives you the list of questions that you can ask before starting to solve a problem.
Why Leetcode?
The problems seem to be picked from multiple tech companies that people usually target.
In case you get a wrong answer, the failed test case shows up.
After you get a problem right, you can compare your solution with other solutions and look for the ones that got the best time.
Really good discussion forum with top answers.
You can see your percentage of accuracy and aim to improve it.
In case you opt for the premium subscription, you have options to filter questions based on company, you can start a timed mock interview based on a random problem, there is an exclusive Google interview track and probably more things being added.
Other resources:
Book - Elements of programming interviews
Course - Paid course on educative
System design:
Courses:
HiredInTech's system design course again gives a very good structure
Paid course on educative is really good to provide the basic building blocks and then moves on to provide solutions to many commonly asked questions.
Recently, I found a beautiful place to learn system design: The architecture of Open Source applications. It has 4 books filled with knowledge.
Extra resources
I came across this video that shows 2 Google employees showing you how an interview works. One of them becomes the interviewer and the other becomes the interviewee. Many invaluable lessons embedded in it. I made copious notes from each minute.
Did I get a job?
Google - NO
My first phone screen interview was with Google and I performed really badly there. I bungled it up and lost that opportunity.
Amazon - YES
After 2 phone screens and 5 onsite interviews, I got an offer from Amazon, Canada.
Target - YES
I landed a job at Target and met some really cool people there. Had lots of fun.
Interview experiences:
Google:
This happened via Google hangout and you get the see the interviewer. Coding was on Google docs (simple as a notepad without any formatting.)
Questions started with basic C++, then moved to class design and coding the methods.
I made some really basic errors that I don't want to write here.
On second thoughts, the basic mistakes I made was to not think of problems in a very fundamental manner. Like one question wanted me to see how I can manage to work on strings and ints. I said templates in C++ and bungled it up. All it needed was overloading.
Then, I wrote a swap method which created a new vector which had the issue of picking an element multiple times from a vector due to the probability of a random number occurring multiple times. After the interviewer showed me that bug, I removed the element from the source vector and placed it into the target vector. Need I talk about the issues here? You now know why I failed.
Beautiful learning.
Target:
Phone screen followed by 2 onsite interviews. The first onsite interview lasted 2 hours - the first hour was spent in coding, the next was spent in discussing the approach I took and other options. The second onsite interview was partly technical and partly managerial (because I had applied for an engineering manager's role.)
Amazon:
Phone screens:
Callers were from Seattle with one principal engineer and an SDE3. The first one lasted 60 min and the second one lasted 90 min (many thanks to the interviewer to give me the opportunity to finish the discussion and the code.)
Great discussions in all.
What I liked is that they were more like discussions and not like someone grilling you for answers. They were looking to see how I approached the problems and how I tackled all the bottlenecks. In fact, I identified many bottlenecks and figured how to get over them too.
Onsite:
Again, all the interviews felt like discussions rather than grilling me. All of them focussed on my approach to problem-solving and provided helpful tips when things were not going well.
Major problem came in the system design round as the problem took me by surprise completely. I was NOT driving the conversation. This was a huge problem. I needed to drive the conversation but never did that.
Other crazy things I did:
I took a paid ($180) mock interview with Gainlo where the interviewer (ex Amazon) gave me a OOD (Object Oriented Design) problem. Somehow, I thought he was busy doing other stuff during the interview (I may be wrong here.) I was hoping he'd help me with prep tips, but he pointed me to Cracking coding interview and told me about his $180/hr classes where he helps people 1x1 to solve problems in a better way. Overall, not a great experience personally.
So, that's my story. I will try to add more details as time goes. Looks like a good start so far.
v2.0. Updated: April 5th 2018.
