Important Tips to Rock the Coding Technical Interview!
Google interviews are the source of fable and mystery if you search the Web. A quick "Google" will return a myriad of pages documenting war stories, impossible brain teasers, inconsistent hiring methods, and too many rejection emails and phone calls.
I myself have interviewed with Google twice for a Software Engineer position and have not received an offer. So you're thinking - "he didnt get in. What qualifies him to write about getting into Google?"; in a word - nothing. This is just my humble collection of tips, artifacts, and experiences from my friends and peers who have made it into the Google Utopia, in hopes that it will help the next person get in. "Dont be evil" right??
My Experience
First Google Interview -
I got a call from a recruiter and was super excited, little did I know the obsession to get in that would follow. 2 phone interviews came and went. Didn't hear from Google assumed they didn't care or weren't interested, so I moved on. No biggie.
I got a call from a recruiter saying "We have it here on record that you did well on the phone interviews last year, would you like to interview again?". OK fair enough there was a glitch in the Google process, no worries, lets do this again. 2 more phone interviews go by but this time I magically made it on-site. Life is good. Then the actual full day interview started. After a very long day of being asked various questions I am feeling pretty good. HR person calls tells me that 3 out of 5 gave good feedback but 2 gave really poor feedback so there would be no offer. He mentioned that I should apply back in a year so that I can sharpen up on my skills. Def a bruise to the ego but fair enough.
At this point I consistently ignored Google recruiters who emailed me cause I wasn't ready to go through the Google gauntlet just yet. I needed a break from that. Besides I didnt have a problem finding satisfying jobs in the interim. However Google still remained my elusive unicorn.
Second Google Interview - After some time I decided to get back on the Google horse, so I emailed one of the few of them I had in my LinkedIn connections. I had no problem getting a phone interview. At this point I had studied almost a full month, knew CS fundamentals sufficiently well, and was prepared. Didnt get past phone interview. When HR recruiter calls tells me that "I didnt do bad or anything but we cant continue with the interview process." - color me confused. I figured I must have made a simple mistake and thats what caused me the interview. Alas this isn't the end of my quest - a few months and ill flirt with them again.
Now the good stuff:
I wont repeat alot of the stuff already out there, but rather collect and list the sites, links, and books that I have found helpful.
General Resources
http://www.pgbovine.net/programming-interview-tips.htm
http://blog.geekli.st/post/34361344887/how-to-crack-the-toughest-coding-interviews-by-gayle (
ex-Google Engineer & hiring committee member)
http://www.pgbovine.net/programming-interview-tips.htm
http://blog.geekli.st/post/34361344887/how-to-crack-the-toughest-coding-interviews-by-gayle (
ex-Google Engineer & hiring committee member)
http://www.google.com/about/jobs/lifeatgoogle/hiringprocess/
http://courses.csail.mit.edu/iap/interview/ ( General Tips )
https://sites.google.com/site/coachingsessions1/home ( General Tips )
http://www.youtube.com/watch?v=w887NIa_V9w
https://google.backpackit.com/pub/727682
http://haufler.org/2012/05/22/interviewing-at-google-facebook-foursquare-dropbox-fog-creek-etc/
http://www.ofb.net/~niniane/interview_howto.html
http://sigizmund.com/preparing-for-interview/
Algorithm Resources
http://courses.csail.mit.edu/iap/interview/ ( General Tips )
https://sites.google.com/site/coachingsessions1/home ( General Tips )
http://www.youtube.com/watch?v=w887NIa_V9w
https://google.backpackit.com/pub/727682
http://haufler.org/2012/05/22/interviewing-at-google-facebook-foursquare-dropbox-fog-creek-etc/
http://www.ofb.net/~niniane/interview_howto.html
http://sigizmund.com/preparing-for-interview/
Algorithm Resources
http://www.amazon.com/s/ref=nb_sb_ss_i_0_14?url=search-alias%3Dstripbooks&field-keywords=programming%20interviews%20exposed&sprefix=programming+in%2Cstripbooks%2C182&r=i%3Astripbooks%2Ck%3Aprogramming%20interviews%20exposed
http://www.amazon.com/Cracking-Coding-Interview-Fourth-Programming/dp/145157827X/ref=sr_1_3?s=books&ie=UTF8&qid=1373242139&sr=1-3&keywords=Cracking+the+Coding+Interview
http://www.algorist.com/
http://www.amazon.com/Hackers-Delight-Henry-S-Warren/dp/0201914654/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1198053186&sr=1-1
http://www.algorist.com/
http://www.amazon.com/Hackers-Delight-Henry-S-Warren/dp/0201914654/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1198053186&sr=1-1
http://projecteuler.net/( Sharpen your actual coding and math skills )
https://facebook.interviewstreet.com/recruit/challenges/ ( timed coding and algorithm skills ) - They say you might catch a recruiters eye if you solve a hard one.
https://facebook.interviewstreet.com/recruit/challenges/ ( timed coding and algorithm skills ) - They say you might catch a recruiters eye if you solve a hard one.
Other fun/interesting links:
http://www.alltechienews.com/posts/hilarious-facts-about-google-s-baddest-engineer-jeff-dean
http://abcnews.go.com/blogs/business/2013/06/google-skips-waste-of-time-brainteaser-interview-questions/
Ill probably add more links and resources as I come across them, so check back every now and then.
http://abcnews.go.com/blogs/business/2013/06/google-skips-waste-of-time-brainteaser-interview-questions/
Ill probably add more links and resources as I come across them, so check back every now and then.
Tips I have come across:
- Be on LinkedIn and update your resume as often as possible. If you are a software engineer this will surely raise the attention of big name companies like Google, Facebook, Yahoo, Twitter, Amazon, etc... and their recruiters will at least email you.
- Do mock interviews with SW engineer friends
- Keep talking to the interviewer as you work - silence is not a good thing.
- Reason out things that you dont understand. Even if it seems hard, your interviewer will nudge you in the right direction if you put up an effort.
- Do not change the question - if they say your input is a linked list, dont change it to be an array to serve your purposes
- Don't write psuedo code, they want a coding sample. So be as complete as possible
- Unless you are the creator of the language you are using, DO NOT tell them you are a 10 out of 10. There is a chance, although minor, that the person interviewing you wrote the language or had a part in it.
- Check for bound cases whenever writing code,
- When using recursion, remember the stop case.
Although the Google interviews may seem frustrating and tedious, try to enjoy it and learn from it. That's the reason I keep going back. I find that it serves as CS refresher and keeps me sharp. So its ok that you( I ) didn't get in the first or second etc.. time. Whats important is that like many other things in life, the satisfaction comes from the struggle to the accomplishment. Think about it, if Google were so easy to get into, would it be as exciting if you got in? Ok enough now go and smash algorithms in O(1/n).
If anyone has any other good tips or resources, please feel free to add them to the comments section and Ill add them to the list.
If anyone has any other good tips or resources, please feel free to add them to the comments section and Ill add them to the list.
**UPDATE** - 8/24/2015
So my interview skills have improved tremendously. Now this is a tip to those of us that have been working for a while and have gotten a little lazy with our SW Engineering skills...
I was constantly getting interviews from big Tech companies but ultimately didnt progress past that. I was always told that my data structures and algorithms skills were very solid, however I wont be going forward. After many many MANY interviews I made it onsite to a Google Interview. They HR person was gracious enough to give me a golden piece of advice. He said to me "The consensus was that you are a smart guy. He said everyone basically said that if you spent more time on the design/analysis, then your code will be alot cleaner to write" Boom goes the dynamite! I have been going about this all wrong. I spent way too much time on algorithms/data structures and not enough time on code cleanliness.
Working day to day as a SW engineer at a variety of companies, I tended to just come up with a general idea of what I wanted to do, start writing code, compile, run, fix bugs and repeat. Unfortunately this breeds bad habits especially when code quality is being scrutinized during a programming interview. And since I got that feedback maybe that's something that shouldn't be a norm in my day to day job either. However I do want to emphasize this, DONT EXPECT TO ALWAYS BE ABLE TO WRITE BUG FREE CODE - it just not human, nor is it realistic for anything than the most trivial of code blocks. So don't feel bad if you cant. The goal is to write relatively bug free code. Besides your interviewers probably cant write completely bug free code either. Side note ( for high tech companies the probability that most engineers could get their job back if they re interviewed is 50% anyways - but I digress.)
I then spent quite a bit of time watching programming interviews on YouTube. I think this surprisingly helped me alot. Reading/Writing algorithms and such is great but watching a highlights reel on YouTube on good interviews was def the final nudge I needed. I would suggest YouTube as a major resource for getting the feel of good programming interviews.
But how do I spend so much time on analysis and design if I am being compared against my peers on the speed of which I answer the questions. Well it turns out while this is true, its not as dire or as cut throat as we make it in our minds. Interviewers wont ding you for taking you so long unless its really gross. Meaning if you take 30 mins to construct a For Loop, then maybe you need some more practice and/or more experience before interviewing. Otherwise generally they would rather see you take the time really nailing all the edge cases and write psuedo code before diving into the real code.
Therefore my humble guideline for a programming interview:
1. Ask all questions regarding the given problem
- Ex. Integers vs Floats vs Doubles etc...
- Ex. AlphaNumeric Strings vs AplhaNumeric + Spaces/Punctuation
- Ex .InPlace or using Auxillary data structures
- Ex. Memory vs Speed constraints
- etc...
2. Write Psuedo Code
This is your opportunity to be messy in figuring things out. Make sure you tell the interviewer you will be writing psuedo code so they don't think that's how you write real code. Here you should talk about everything you are thinking, whether it may sound dumb or not. They want to follow your thoughts, so its ok to say "hmm if I iterate over everything twice might work but wait that might not help so much"
Once you have a semi formed way of solving it. At a minimum do the following:
- Check Input - Is input NULL, length == 0,etc...Does the input datatype match what they asked for?
- Check Step by Step of the algorithm
- Here literally write out step by step of the algorithm explicitly. You may find bugs yourself here which scores big points with the interviewer.
- Recursion? Where is the stop condition?
- Check Output, are you returning an index or a number or .... Make sure it matches the requirements of the function
- Check Edge Cases, Linked Lists? What happens with 0 nodes, 1 node, n nodes. Search? What happens when element is not found.
3. Write Real Code
Once your interviewer feels confident your pseudo code is 90% there, they usually nudge you to start writing real code. This does not mean your pseudo code is actually complete. It just means its close enough.
I suggest to write code by translating line by line psuedo code to real code.This should make it alot more straight forward to write code vs fumbling around and modifying it like crazy which gives the impression of "sloppy code" which is programming interview death.
Once you have done that, now go back and again go line by line dissecting your code. This is the point at which you may discover that you need an extra variable to do a swap, need an extra condition in the for loop etc... Again here i suggest taking a break from writing real code but rather go back and modify your pseudo code to improve what you just found out. This shows the interviewer that when you get stuck you take a methodical way of resolving it vs just splashing around until you somehow get it to work. After all lots of interviewers often think how you would be to work with, so having a SW Engineer who just hacks it to work is scary especially when its a challenging problem with a deadline looming over them.
4. Optimize The Code
Once you have a working version the interviewer seems to like. Take some time to actually optimize your code. Do you need that extra loop, extra variable, maybe a reference is better to use vs a pointer. This demonstrates not only do you care about solving the problem but you care about the elegance of the actual code itself. Most interviewers will copy your code same if its a phone interview to show others. So make sure you do a good job of making a final draft.
With these steps you'd be surprised how smoothly you get through a phone interview. Give it a shot.
Now back to my story:
After my last Google onsite interview, I was told I had very strong analytical skills and a solid grasp of Data Structures and Algorithms. They also did mention that they couldnt give me an offer because I jumped too quickly into code rather then hashing out a good design before I started coding. So even though I didnt get the offer, the feedback they gave me was worth its weight in gold. I took some time to really nail my weak points. Last week I had a technical phone interview with Facebook. I already accepted a job offer from a different company so I was using this interview as a practice of what I was practicing on my own. Surprisingly I solved 2 programming questions within the time with time to spare - usually one question and I don't finish within the time. So I do feel very confident that there will be a follow up and if not then ya know what it's all good. I am learning more and more how to hone my craft, so that satisfying to me. Its not always about the destination its about the journey.
Yes - I am annoyingly optimistic about this. I figure I will keep interviewing even if it takes 100 times and many many small incremental steps, I want to get to the point of actually conquering the Technical Programming Interviews from the big Tech Companies.
Once your interviewer feels confident your pseudo code is 90% there, they usually nudge you to start writing real code. This does not mean your pseudo code is actually complete. It just means its close enough.
I suggest to write code by translating line by line psuedo code to real code.This should make it alot more straight forward to write code vs fumbling around and modifying it like crazy which gives the impression of "sloppy code" which is programming interview death.
Once you have done that, now go back and again go line by line dissecting your code. This is the point at which you may discover that you need an extra variable to do a swap, need an extra condition in the for loop etc... Again here i suggest taking a break from writing real code but rather go back and modify your pseudo code to improve what you just found out. This shows the interviewer that when you get stuck you take a methodical way of resolving it vs just splashing around until you somehow get it to work. After all lots of interviewers often think how you would be to work with, so having a SW Engineer who just hacks it to work is scary especially when its a challenging problem with a deadline looming over them.
4. Optimize The Code
Once you have a working version the interviewer seems to like. Take some time to actually optimize your code. Do you need that extra loop, extra variable, maybe a reference is better to use vs a pointer. This demonstrates not only do you care about solving the problem but you care about the elegance of the actual code itself. Most interviewers will copy your code same if its a phone interview to show others. So make sure you do a good job of making a final draft.
With these steps you'd be surprised how smoothly you get through a phone interview. Give it a shot.
Now back to my story:
After my last Google onsite interview, I was told I had very strong analytical skills and a solid grasp of Data Structures and Algorithms. They also did mention that they couldnt give me an offer because I jumped too quickly into code rather then hashing out a good design before I started coding. So even though I didnt get the offer, the feedback they gave me was worth its weight in gold. I took some time to really nail my weak points. Last week I had a technical phone interview with Facebook. I already accepted a job offer from a different company so I was using this interview as a practice of what I was practicing on my own. Surprisingly I solved 2 programming questions within the time with time to spare - usually one question and I don't finish within the time. So I do feel very confident that there will be a follow up and if not then ya know what it's all good. I am learning more and more how to hone my craft, so that satisfying to me. Its not always about the destination its about the journey.
Yes - I am annoyingly optimistic about this. I figure I will keep interviewing even if it takes 100 times and many many small incremental steps, I want to get to the point of actually conquering the Technical Programming Interviews from the big Tech Companies.
Nice post, buddy -- I like the positive perspective you're taking. It is a great CS refresher and keeps you sharp. Bravo -- here's to the third time being the charm :)
ReplyDelete