I was contacted right after the Elopcalypse, when all Nokia engineers and subcontractors were fair game and easy pickings.
Had one recruiter phone screen with some easy questions, a technical phone interview and then was informed they decided to skip the second phone interview. Got called on-site in Dublin directly instead.
My experience from there pretty much resembles what the author describes. First interview was about my knowledge of C, memory mappings and the related security implications. Let's just say that it helped I had experience from both little-endian and big-endian architectures. The second one was the fairly well known python interview. The problem is devious but really interesting. I botched that one, because I failed to follow my instinct and sketch a visualisation out first. That caused my attempts to derail pretty badly and by the time I realised I would need to rethink and simplify much of the logic, we were out of time.
Third one was a fascinating trouble-shooting problem. It was not just about the technical problem or the symptoms, but also about how to deal with people who may have these kinds of problems due to being frightfully clever at getting themselves set up with the problems in the first place. I think I nailed that one. We had a nice chat about the history of the problem with the interviewer because we had some time to spare.
Fourth one was a system design problem, and it was a true pleasure. The interviewer wasn't as much asking me questions, as he was more laying out the problem and the proposed architecture. We went through the requirements, limitations and he even showed me one neat trick which I hadn't ever thought before. (The actual architecture in question was effectively a DHT with an interesting twist. I thought it was brilliant.)
The fifth one was basically about how well I understood the system internals of unix and linux. However, the approach chosen was not the off-the-shelf one I've seen elsewhere - the dive into internals started with task_struct. Yes, the one which nobody is supposed to understand completely. (At least according to Robert Love in Linux Kernel Development.) I got it right, evevntually.
I was, of course, rejected due to "not good enough at coding". I don't hold that against the interviewers or the process. I know I'm a slow starter with any code - and I seem to suck at whiteboard coding. Whiteboard is great for doing visualisations and writing down short snippets where they are relevant, but for actual programming it just doesn't work for me. My most important design tools to this day are a large paper pad and a good pencil. After that it comes down to debug logs...
What may sound strange, is that the on-site day remains one of the most enjoyable experiences of my life. The interviews were designed to keep my brain spinning at overdrive, and the interviewers themselves were good enough not to actively mislead (they did keep me asking questions and stating the reasons for my approaches, which was crucial). Loved it.
I've told all this to my hacker-type friends and still remain convinced that any engineer worth his title should experience the Google on-site day. It's a challenging, but also extremely satisfying experience. Some of them have tried, and at least one has been actively courted. I'm convinced he would ace the interviews without a hitch. The requirement to move is the one thing keeping him away.
Had one recruiter phone screen with some easy questions, a technical phone interview and then was informed they decided to skip the second phone interview. Got called on-site in Dublin directly instead.
My experience from there pretty much resembles what the author describes. First interview was about my knowledge of C, memory mappings and the related security implications. Let's just say that it helped I had experience from both little-endian and big-endian architectures. The second one was the fairly well known python interview. The problem is devious but really interesting. I botched that one, because I failed to follow my instinct and sketch a visualisation out first. That caused my attempts to derail pretty badly and by the time I realised I would need to rethink and simplify much of the logic, we were out of time.
Third one was a fascinating trouble-shooting problem. It was not just about the technical problem or the symptoms, but also about how to deal with people who may have these kinds of problems due to being frightfully clever at getting themselves set up with the problems in the first place. I think I nailed that one. We had a nice chat about the history of the problem with the interviewer because we had some time to spare.
Fourth one was a system design problem, and it was a true pleasure. The interviewer wasn't as much asking me questions, as he was more laying out the problem and the proposed architecture. We went through the requirements, limitations and he even showed me one neat trick which I hadn't ever thought before. (The actual architecture in question was effectively a DHT with an interesting twist. I thought it was brilliant.)
The fifth one was basically about how well I understood the system internals of unix and linux. However, the approach chosen was not the off-the-shelf one I've seen elsewhere - the dive into internals started with task_struct. Yes, the one which nobody is supposed to understand completely. (At least according to Robert Love in Linux Kernel Development.) I got it right, evevntually.
I was, of course, rejected due to "not good enough at coding". I don't hold that against the interviewers or the process. I know I'm a slow starter with any code - and I seem to suck at whiteboard coding. Whiteboard is great for doing visualisations and writing down short snippets where they are relevant, but for actual programming it just doesn't work for me. My most important design tools to this day are a large paper pad and a good pencil. After that it comes down to debug logs...
What may sound strange, is that the on-site day remains one of the most enjoyable experiences of my life. The interviews were designed to keep my brain spinning at overdrive, and the interviewers themselves were good enough not to actively mislead (they did keep me asking questions and stating the reasons for my approaches, which was crucial). Loved it.
I've told all this to my hacker-type friends and still remain convinced that any engineer worth his title should experience the Google on-site day. It's a challenging, but also extremely satisfying experience. Some of them have tried, and at least one has been actively courted. I'm convinced he would ace the interviews without a hitch. The requirement to move is the one thing keeping him away.