Mashable/Bryan did a nice job on this article, but I wanted to share a few notes on the process:
1) Phone screens: If you aren't referred or we don't really get a good feel from your resume what kind of developer you are, there are preliminary phones screens which can seem...insulting to experienced programmers. Then you get a phone screen with an engineer.
2) On-sites: These are often with people who are -not- on the team you may be joining. We try to avoid team interviews for a number of reasons. But you are likely to talk with 1 or 2 people from a future team .
3) In engineering interviews, you shouldn't see stupid manhole questions. You should see 'how would you do' questions, preferably ones that allow you to talk about how it should be solved, write on the whiteboard code that would solve it, and then what kind of optimizations you would apply to the problem, etc... Through this discussion we can see what kind of developer you are. This should ideally be a discussion among peers about how to approach a programming/Google relevant/computer science problem.
4) Get a reference. Want the best kind? Write open source code that gets used and point it out in your cv/res. That'll lead to Googlers who you can use to put your resume in the system (the best way to go, trust me) A reference that has familiarity with your code and a subsequent link to that code in your cv is gold if you are a decent programmer. I've see people who interview really poorly be saved by their code submissions.
Hello cdibona!
Your notes make a lot of sense and will prove to be useful!Thank you for that! Also, I think point number 1 is pretty rarely done nowadays, correct me if i am wrong! Plus, Google's way of recruiting is changing continuously and i think we can't make a certain comment on how it would be in the future. What you are telling here applies for now, and it's good and i really think no. 4 is a brilliant point!
Thanks!
3 comments
[ 3.1 ms ] story [ 11.5 ms ] thread1) Phone screens: If you aren't referred or we don't really get a good feel from your resume what kind of developer you are, there are preliminary phones screens which can seem...insulting to experienced programmers. Then you get a phone screen with an engineer.
2) On-sites: These are often with people who are -not- on the team you may be joining. We try to avoid team interviews for a number of reasons. But you are likely to talk with 1 or 2 people from a future team .
3) In engineering interviews, you shouldn't see stupid manhole questions. You should see 'how would you do' questions, preferably ones that allow you to talk about how it should be solved, write on the whiteboard code that would solve it, and then what kind of optimizations you would apply to the problem, etc... Through this discussion we can see what kind of developer you are. This should ideally be a discussion among peers about how to approach a programming/Google relevant/computer science problem.
4) Get a reference. Want the best kind? Write open source code that gets used and point it out in your cv/res. That'll lead to Googlers who you can use to put your resume in the system (the best way to go, trust me) A reference that has familiarity with your code and a subsequent link to that code in your cv is gold if you are a decent programmer. I've see people who interview really poorly be saved by their code submissions.
Happy to answer other questions.