Getting an interview is a function of luck. A lot of companies do automated scans to cut down their massive amounts of applications. Getting past this means having the right key words in your resume, or the right numbers and so forth. Once you get that interview, it is all on you, no more luck. From here if you don't get the job it is your fault.
Two weeks ago, I got contacted by a Google recruiter to follow up on my application and schedule interviews. The result was two interviews, one day apart. I had about a week and a half to prepare for them. Google was kind enough to send out a list of topics to review and study.
The interviews are a simple 45 minute sessions over the phone. Both of my interviewers were very interesting, friendly and nice. The interview itself was challenging but informative. The begnning is a quick 10 minutes about yourself, what you study, what you work on, your experience. Then there is about 10 minutes of simple basic CS questions, what is an iterator, what is a cache, explain search. The next part is one larger 15 minute question that you have to code in a google doc. This question involves coming up with a solution, analyzing it, and then improving it. Finally the interviewee gets to ask a few questions for 5 minutes.
The main focus is this last 15 minute coding question. Here are the ones i got in my two interviews.
1. Implement division, without using division.
I gave a basic preliminary version, and we started a back and forth seeing the efficiency of the version and improving.
2. Implement a LRU cache.
I gave another basic version, with the main operations and described the time efficiency. Then came the process of improving. Use data structures, and trickery to get it constant time for the main operations.
Let's just say that a short 45 minute interview was mostly able to cover 75% of intro to computer science. It was more difficult than any school exam up to this point, and far more creative and thought provoking. College has no room for creativity. I left one of these interviews spending the next three days thinking of better implementation for what i had given (and drove everybody around me insane). Courses are all about learn, and regurgitate, make sure to include all the details, and just spit out everything you read and heard. Interviews, and the real world involve take a bit you learned there, add it to two bits you learned over there, AND, OR, XOR it with a few bits (pun intended) you remember from here and morph it until it works.
Two weeks ago, I got contacted by a Google recruiter to follow up on my application and schedule interviews. The result was two interviews, one day apart. I had about a week and a half to prepare for them. Google was kind enough to send out a list of topics to review and study.
- Simple list of basic CS topics (arrays, linked lists, hashes, heaps....).
- Top Coder link providing an overview of algorithms, going from simple searching, to max flow, and closest pair.
- A book on interviewing for CS jobs, which covers all intro CS topics.
The interviews are a simple 45 minute sessions over the phone. Both of my interviewers were very interesting, friendly and nice. The interview itself was challenging but informative. The begnning is a quick 10 minutes about yourself, what you study, what you work on, your experience. Then there is about 10 minutes of simple basic CS questions, what is an iterator, what is a cache, explain search. The next part is one larger 15 minute question that you have to code in a google doc. This question involves coming up with a solution, analyzing it, and then improving it. Finally the interviewee gets to ask a few questions for 5 minutes.
The main focus is this last 15 minute coding question. Here are the ones i got in my two interviews.
1. Implement division, without using division.
I gave a basic preliminary version, and we started a back and forth seeing the efficiency of the version and improving.
2. Implement a LRU cache.
I gave another basic version, with the main operations and described the time efficiency. Then came the process of improving. Use data structures, and trickery to get it constant time for the main operations.
Let's just say that a short 45 minute interview was mostly able to cover 75% of intro to computer science. It was more difficult than any school exam up to this point, and far more creative and thought provoking. College has no room for creativity. I left one of these interviews spending the next three days thinking of better implementation for what i had given (and drove everybody around me insane). Courses are all about learn, and regurgitate, make sure to include all the details, and just spit out everything you read and heard. Interviews, and the real world involve take a bit you learned there, add it to two bits you learned over there, AND, OR, XOR it with a few bits (pun intended) you remember from here and morph it until it works.
This should add to the collective information the web stores about interviewing with competitive tech companies.
No comments:
Post a Comment