I attended a Google interview coaching session yesterday (if you get in touch with a recruiter, they'll send you an link to RSVP for one in session, and I think they're all recorded). It was led by, if I remember correctly, a fairly senior manager whose team was working on machine learning for recruiting, so he had some fairly specific experience with this.
Two things he mentioned that stand out for your question: first, Google attempts to hire generalists, or at least "fungible specialists". Three of your five SE interviews will be general CS algorithms questions; the other two are likely to be specialized if you're interviewing for a specialized role. I don't think that it's likely to be different from the other "Software Engineer, Foo" interviews (e.g., "Software Engineer, Front End" or "Software Engineer, Mobile"), where at least one of the remaining two interviews will probably be specific to Foo.
Second, he specifically complained about people who show up and say "I want to do machine learning" and then say they have no machine learning experience / background. There are apparently a very small number of teams who will train a bright person how to do ML, but in general you're expected to have some background with it.
This seems like the sort of thing you should ask your recruiter (after getting in touch with one) and perhaps ask at a coaching session, if there's one in your city. I am a little genuinely confused that they seem to think their interviews need a coaching session, but hey, at least it's progress.
That's related to the engineering practices at Google (3.1 below)
> "Engineers are permitted to spend up to 20% of their time working on any project of their choice, without needing approval from their manager or anyone else"
Ph.D.'s are not, by definition, specialists; they have, of course, demonstrated depth in at least one narrow specialty, but that is not inconsistent with also having breadth (and I think Google's preference isn't for breadth instead of depth, but for both together.)
I've heard it said that the point of a Ph.D. is less about the specific thesis topic than the fact that you can spend 8 years going deep on some arbitrary thing and come out successful. If someone needs a problem solved that takes 8 years of focus to do, a Ph.D. is a pretty good indicator that you can do it reliably. If you're the sort of person who enjoys taking (up to) 8 years to make a contribution to the world, a Ph.D. is a good way to do it, and also to prove to others you can do it.
Most of my college professors, I believe, had thesis topics that are only loosely related to their current field of research. To pick a random example, Ron Rivest's thesis was on searching large files or something, which is somewhat related to one of his most famous publications (the algorithms textbook), completely unrelated to the other (the RSA algorithm), and mostly, I think, unrelated to his current research (secure electronic voting).
I disagree that is the point of a PhD is some kind of struggle to get through, I honestly enjoyed mine and don't think the topics are so interchangeable.
Research topics drift over time, but the starting point is still significant.
So you have letters after your name and people take you seriously and no-one can say you wasted your life exhuming lifeless ideas and padding them out into a massive document that no-one will ever read. Or something.
Generalist and specialist are not mutually exclusive. Someone can simultaneously have some knowledge of many different areas, and deep knowledge of one particular area. This is in contrast to someone who has no deep knowledge in any area ("knows something about everything") or someone who only has extremely deep knowledge of only one area ("knows everything about nothing").
I interviewed at all the big bay companies (and the seattle one) for machine learning earlier this year and few of the questions were classical machine learning questions. Most of the questions were programming an computation.
Each company does the 5 interview format and some of them, an Apple data science group for example, ask or a presentation of your research.
Random people from the team, group or larger org will interview you, seemingly to remove any bias. Consequently, you get a large variety of interviewers w/ different backgrounds. On average I would say only 1 out of 5 five interviewers had machine learning background and asked those questions. Most of the interviews were traditional software engineers (or Data Engineers) and asked the typical "Cracking the coding interview" questions. Sad state of affairs :(
Not an employee, but I'm pretty sure that the interview is the same for all engineering roles, unless you're very senior/specialized. I doubt that your interviewers will even know that you're up for a ML position specifically.
More seriously, I was brought in for an iOS app development job interview and I was asked all algorithm questions and nothing about iOS.
I also tried doing the whiteboard questions in my strongest language at the time, Objective-C, which in hindsight was a huge mistake (Objective-C is ridiculously wordy, I kept running out of space on the whiteboard). A couple of the interviewers said they weren't too familiar with Objective-C either, so I clearly wasn't getting interviewed by their iOS teams.
If I were to do it again I'd probably use a much more terse language like Python.
Google has apparently very recently rolled out Chromebooks as an alternative to the whiteboard format. The devices don't compile anything or run test cases for you, but they've got an editor with syntax highlighting that projects on the screen. (They reportedly care a bit about clear variable names, which I never do on a whiteboard for wordiness, so even in Python I'm inclined to opt for the Chromebook.)
Another thing that surprised me is that the interviewer records your actual whiteboard code (by transcribing it into their notebook by hand) or your Chromebook code (by clicking a button), and the hiring committee sees it and evaluates it. And it seems the hiring committee has the ability to re-evaluate the result of the interview and second-guess the interviewer in the room, if they feel that it's necessary. It's entirely possible that your code was seen by folks who did know Objective-C well, although yeah, it seems like it would have gotten them more signal if they put people who knew Objective-C in the room with you....
But that wasn't the only reason I wasn't hired, I'm sure. I was only given a week and a half to prepare, while working a stressful job at the same time, where the Google recruiter basically gave me ten links (including a long TopCoder algorithms link I think) and said "Prepare by doing and reading everything on these links")
During the interview, I struggled with a couple of the problems in particular, and I was late to the first interview because I under-estimated just how bad the traffic would be and how lost I'd get on Google's campus.
Google's gotten in touch since, and I basically just have to tell this one recruiter to set me up for another interview if I wanted one, but I've been hesitant to go through that again and I'm no longer sure if I want to move out to SV (I'm from Chicago).
> I was brought in for an iOS app development job interview
> A couple of the interviewers said they weren't too familiar with Objective-C either, so I clearly wasn't getting interviewed by their iOS teams.
Google's onboarding process is such an enigma to me. I went through a few of the remote interviews for SWE a few years back (I didn't commit to an on-site one in mountain view though). It seemed very odd to me that, near as I could tell, they don't really give an indication about what you would be working on until after you are hired and oriented.
I actually prefer the way Google does it. They are really looking for generalists and the process is optimized for that. Once they have determined you have met the hiring bar, then they proceed with a "matching" process which is awesome. You get to list of your interests and get placed on a team in the company that aligns with your preferences and skills.
This is way better IMO to the reverse which is applying to ten different interesting positions at another big tech company and having to speak to individual hiring managers for each position.
As an iOS engineer who mostly does Swift at a big company (not west coastal) I would never even bother with Google. Might be a nice place to work but not worth the effort.
I thought it was funny enough to deserve having been posted, since it implied a nice misreading (or perhaps even a garden path sentence).
You could also consider it a wry social comment on the Rise of the Robots.
(I notice your comment has been downvoted. I will up vote it -- I disagree with it, but it's also reasonable question as questioning the standards and practices of the group are a way to converge on good practice. Every team should be doing that).
The original comment has positive rep because it's actually pretty good. What HN doesn't like is a wall of memes and in-jokes that are actually pretty repetitive and boring. Without a high bar for humor that is what all tech communities will devolve to, witness Slashdot, Reddit, etc.
The reason i didn't like this particular brand was that it's at the expense of the OP, who I presumed was tense about the interview. At the time I commented, there was 1 useful answer and this useless (and funny, but not that original, there is a interview-bashing thread once in two days) one was at the top.
I didn't intend it to be at the expense of the OP. If anything it was meant to be at the expense of Google. Although I wasn't trying to be malicious about it.
Yes, your recruitment manager is your #1 resource and a coach of sorts. Absolutely bring up questions with them and make sure you are clear on what may come up in the interview.
Don't bring perceptions of joke answers online into your real job interview!
Eh, when I interviewed my recruiter was definitely friendly and willing to answer questions, but didn't really have any actionable information about what to expect in the interview. Answers on Quora/blog posts were actually a lot more useful. However, later on in the process during team matching and negotiating an offer the recruiter was much more helpful.
Coach is a good word, at least with the experience my wife had. She felt she was talking to a "friend" that wants you at Google, vs someone on the other side.
You get one TopCoder problem and the automated DeepCoder robot with q=0 is your first opponent. Once you beat it, they increase q to 1. You have 6 rounds with 1 hour lunch break where they tweak DeepCoder to respond to your thinking better. Once you beat all DeepCoder levels, they hire you and your task is to improve DeepCoder so that it beats you every single time.
Given they've acquired Kaggle, I would imagine if you can solve Kaggle questions you're getting a solid preview of the ML-specific questions they might ask you in addition to the standard data structure/algo and unix questions they'll ask you.
Purely by inference based on ML/MV interactions with various bits of teh Googz, it will depend very much who is asking these questions - the closer you get to the tensor processing unit and its enclosing code, the more you're going to have to really know your stuff - further away in some of the ex-moon shots struggling to survive, I'd personally be surprised if the staff runs a reliable enough A* alg in their own heads to actually get to the room you're seated in - in short, googz is big - closer you get to the core the more hard core I would expect it to be, conversely as you move to the fringes, well that might be what you get :-)
They give you an assignment to complete at your pace for a few days, and review your solutions and implementation with a group of your (future?) peers. This takes the form a small Q&A presentation and allows to assess your technical and communication skills.
Then, you spend another week as a paid 'freelancer' to do some actual work and interact with your team. At the end of the week you are assessed by your peers and are presented with an offer, in case all went 'well'.
The reality is certainly much grimmer (to me anyways).
Ideal scenario? Are you seriously suggesting that it should be reasonable for a potential employer to expect you to burn a week's worth of vacation time on the possibility of going to work for them? No way!
Compared to the current situation, where you have to study for a month to answer "Cracking the coding interview" questions, yes, this would be a much better scenario.
I spend a few minutes a day reading through some problems for a week or two before an interview that I suspect will be challenging. Less if I've been interviewing a lot lately. Who the heck studies for a month for an interview??
I'm exaggerating. My point is that doing some studying spread out over periods of free time is more practical than using a more concentrated chunk of time where I already have commitments.
I'd also argue that your friends are in a "special category" of their own, if they're willing to devote months of study time into getting a specific job.
I'm at grad school currently, and all recent graduates I know who wanted to get a job at top SV companies studied really hard for SE interviews. And even after all that studying, most of them didn't pass technical interviews at big 4.
We are talking about solid knowledge of algorithms and data structures. If you haven't just gotten an A in that class you will need a while to really hammer it down.
This whole subthread makes more sense if we're talking about college hires. I can see why the idea of a homework assignment and a week of paid consulting might seem appealing for people who don't already have a job and haven't already been through the interview process a few times.
This is not an unreasonable suggestion. Google seems to have taken the Yegge stuff and Cracking the Coding Interview to heart and published a lot of info on the interview experience.
We have. In addition, some offices offer interview coaching sessions for candidates who are scheduled for an on-site, which are basically rehashes of the material we publish plus some Q&A time with an interviewer.
I would encourage OP to ask their recruiter about them, if they think it'd be helpful.
Purely a personal anecdote and single data point, however I would not recommend going to the coaching sessions in order to gauge the type/difficulty of the questions you will be asked in the interview. I've done this before and it was not representative whatsoever. If anything, it gave me a false sense of confidence because the questions were so simplistic.
We lost control(reliability of the Algo, understand-ability of the Algo, reproduce-ability of the Algo) on the P in Input Processing Output. Can you write Data filters and Automated Tests to Abstract that problem away?
As someone going into the field, can you explain what this means? Specifically, I'd assume we're trying to isolate some outliers that are causing a funky bias in the learner. In what way would you automate their discovery (what does it mean to "discover" the outliers in this scenario?)?
Just looking for clarification because I feel like I should know this. Trying to couch the problem in terms I'm more familiar with.
If you can't study to reverse a linked list efficiently... You're gonna have a bad time...
I ask 'reverse a linked list' when the interview is going so poorly that there is no chance the candidate will be able to answer my 'normal' questions.
Funny, because whenever I get asked questions like that, I just start nesting for loops to an arbitrary depth, until that trolls my way out of the interview.
Then I wrap the outer-most closure in an exception that swallows the error, and bid good afternoon.
Two things he mentioned that stand out for your question: first, Google attempts to hire generalists, or at least "fungible specialists". Three of your five SE interviews will be general CS algorithms questions; the other two are likely to be specialized if you're interviewing for a specialized role. I don't think that it's likely to be different from the other "Software Engineer, Foo" interviews (e.g., "Software Engineer, Front End" or "Software Engineer, Mobile"), where at least one of the remaining two interviews will probably be specific to Foo.
Second, he specifically complained about people who show up and say "I want to do machine learning" and then say they have no machine learning experience / background. There are apparently a very small number of teams who will train a bright person how to do ML, but in general you're expected to have some background with it.
This seems like the sort of thing you should ask your recruiter (after getting in touch with one) and perhaps ask at a coaching session, if there's one in your city. I am a little genuinely confused that they seem to think their interviews need a coaching session, but hey, at least it's progress.