3 ms·

I'm in the interviewer pool at Google. Other FAANGs might be different. I've had candidates ask me why we do this, and my answer is that once you're in the com

I'm in the interviewer pool at Google. Other FAANGs might be different. I've had candidates ask me why we do this, and my answer is that once you're in the company, transferring to another job on the same ladder is fairly trivial and requires no technical re-interviews. I go on to describe how I've been around for 10 years and am on my 5th team. None of those transfers required any sort of technical re-check. Teams trust me when I say what my abilities are. Sometimes they'll look at past CLs, and we certainly have a couple interviews to make sure that the fit is good, but nothing technical. In none of my positions has it been "crank out the code, pass it off, then on to the next piece". There has always been a clear sense of ownership of my code, where I've been responsible for both the code and a steward of where and how it's used and modified.

goldenManatee 6y ago
I’m not sure how unique that is, though. Most companies once you’re in doing technical, your peers will trust you to switch teams or broaden out a little. Re-testing a coworker would come off anywhere between amusing and insulting.
- mattst88 6y ago
  We would always interview internal candidates for technical abilities at Intel.
- chillacy 6y ago
  At larger companies I've worked at without central hiring committees it was common to get re-interviewed unless you were vouched for by someone pretty senior.
okareaman 6y ago
I don't doubt that you're required to maintain your own code after you've checked it in for others to use ("pass it off") but have you always designed your own solution or have you had to implement designs by higher ups for some not insignificant percentage of the time?
- ddalex 6y ago
  not OP, but currently a manager at Google (full disclosure, opinions are my own, company is not involved, etc) I fully expect that everybody at Google will create the designs for the problems they own, get the designs through peer review, work on implementing these designs, and verify that the solution is solved in process. What changes with the seniority level is the scope of the designs - a junior may be expected to design their piece of code, only their module, a mid level is expected to design an entire subsystem while delegating individual modules, a senior is expected to design an entire system delegating the subsystems, etc. Of course, it's not so clear cut all the time, but the critical piece we have here is that - Everybody, at all levels, are expected to share expertise, knowledge and acumen in order to help others grow. When you put everything together it creates a nice cycle of constant growth pressure. Absolutly I will not qualify anybody's work here as "droning", and if someone in my team would feel like that I would invite them to speak up and work together into making it better. About the quality of people here, what has impressed me most is the uniform high level of competence and niceness. In other companies where I've worked the skills would more-or-less all over the place, but here it's uniform good. I'd rate Googlers consistently in top 20% of the teams where I've worked with before. Also everybody is so very nice, a real pleasure to be around and work together. I still haven't discovered how recruiting selects for this, but everybody constantly passes the airport test my in book.
- shaftway 6y ago
  I've never been given a design doc to implement (though I prefer to code, so sometimes I wish I had). I've always been expected to do the research and figure out the design for myself. Sometimes I ask people to fill in parts of a design doc that I know they'll be implementing. This ensures they are aware of the design, it's correct, I haven't missed some critical details, and they have essentially written the design for their own work. Occasionally I've had a design review where a higher-up has said "this is why we aren't going to do it that way". I've always been given a reasonable reason (not always one I agree with, but reasonable). I've always been the one to re-write the design in these cases.

goldenManatee 6y ago

I’m not sure how unique that is, though. Most companies once you’re in doing technical, your peers will trust you to switch teams or broaden out a little. Re-testing a coworker would come off anywhere between amusing and insulting.

mattst88 6y ago
We would always interview internal candidates for technical abilities at Intel.
chillacy 6y ago
At larger companies I've worked at without central hiring committees it was common to get re-interviewed unless you were vouched for by someone pretty senior.

okareaman 6y ago

I don't doubt that you're required to maintain your own code after you've checked it in for others to use ("pass it off") but have you always designed your own solution or have you had to implement designs by higher ups for some not insignificant percentage of the time?

ddalex 6y ago
not OP, but currently a manager at Google (full disclosure, opinions are my own, company is not involved, etc) I fully expect that everybody at Google will create the designs for the problems they own, get the designs through peer review, work on implementing these designs, and verify that the solution is solved in process. What changes with the seniority level is the scope of the designs - a junior may be expected to design their piece of code, only their module, a mid level is expected to design an entire subsystem while delegating individual modules, a senior is expected to design an entire system delegating the subsystems, etc. Of course, it's not so clear cut all the time, but the critical piece we have here is that - Everybody, at all levels, are expected to share expertise, knowledge and acumen in order to help others grow. When you put everything together it creates a nice cycle of constant growth pressure. Absolutly I will not qualify anybody's work here as "droning", and if someone in my team would feel like that I would invite them to speak up and work together into making it better. About the quality of people here, what has impressed me most is the uniform high level of competence and niceness. In other companies where I've worked the skills would more-or-less all over the place, but here it's uniform good. I'd rate Googlers consistently in top 20% of the teams where I've worked with before. Also everybody is so very nice, a real pleasure to be around and work together. I still haven't discovered how recruiting selects for this, but everybody constantly passes the airport test my in book.
shaftway 6y ago
I've never been given a design doc to implement (though I prefer to code, so sometimes I wish I had). I've always been expected to do the research and figure out the design for myself. Sometimes I ask people to fill in parts of a design doc that I know they'll be implementing. This ensures they are aware of the design, it's correct, I haven't missed some critical details, and they have essentially written the design for their own work. Occasionally I've had a design review where a higher-up has said "this is why we aren't going to do it that way". I've always been given a reasonable reason (not always one I agree with, but reasonable). I've always been the one to re-write the design in these cases.