1. 22
  1.  

  2. 15

    I worked at Google from 2008-2010, after a 15-year tenure at Apple. The whole experience was weird. What struck me the most about the interview process was that I wasn’t being considered for a particular team, and the people interviewing me were from various groups around the company (and I never met them again.) It wasn’t until after I passed that the recruiter started talking about specific positions.

    The attitude seemed to be that engineers are a generic commodity — as long as they’re smart enough, as established by whiteboarding sort algorithms, the company can grab them up and drop them into any project.

    And while it’s true that smart people are good at learning stuff quickly, that attitude has a disregard of human factors and team dynamics. It’s the only company I’ve ever worked for where I wasn’t interviewed by people whom I’d be working with.

    I don’t know what Google is like now, but back then it felthuge and impersonal, somehow simultaneously chaotic and bureaucratic, and I never felt I fit in. I left for a startup after 21 months and never looked back.

    1. 3

      The rationale behind this was that it was necessary for internal mobility to be high. Now that the company is so much bigger than it was back then, this is a bit less the case & people are allocated to a specific product area in advance, at least.

    2. 12

      Eight interviews?! Who on earth puts themselves through that?

      1. 9

        Someone trying for a super stable megacorp job? Yeah, I’ve been through the Google wringer a few times. The only positive I can really say I got out of it was to stop basing my worth on passing interviews and just optimize for culture fit. People who you love to work with are rare but they make coming into work much more worth it. Life’s too short to hate your job, usual caveats apply (like being early in your career, having few opportunities, etc).

      2. 8

        Should probably be marked [2008], even though it’s apparently updated 2 weeks ago.

        1. 2

          Came to mention exactly the same thing. Funny that the article begins with “Two weeks ago (in October 2008)”, and the subheading has the same “Two weeks ago”

        2. 6

          I’m going through the wringer at FB and G right now. I want this Leetcode purgatory to end already.

          1. 3

            It sucks, doesn’t it? You know that you’re just being put through a camouflaged IQ test that you’re expected to have spent weeks (or even months) drilling for. On top of that you’re being asked to “perform” in front of an audience, which is something a lot of tech-types find inherently difficult and stressful.

            That none of it has anything to do with real on-the-job ability makes the whole thing especially insulting.

            1. 2

              They are testing for obedience, not ability.

              Developers with a strong moral code have become a big problem for tech management of late.

              1. 2

                Why don’t they just give candidates IQ tests if that’s what these toy problems are indirectly measuring?

                1. 3

                  The Supreme Court ruled in Griggs v. Duke Power Co. that a use of IQ tests was discriminatory.
                  The result is that most US corporations avoid them.

                  1. 2

                    It is (IIRC) illegal to use IQ tests as an interview filter in the United States, as they are believed to discriminate on racial grounds. (IQ tests have a long and fairly depressing history of being used as tools of racial oppression sadly.)

                    So the tech companies use “programming tests” as deniable IQ tests, and as filters for “will jump through technical hoops on demand even if obviously irrelevant to the job at hand if requested to by senior management”

                    These aren’t necessarily /bad/ things from the company’s POV - management usually prefers having conformist employees who won’t rock the boat for obvious reasons & general intelligence is not in and of itself a bad thing to have. But it’s good to go in with your eyes open - these programming tests have little or nothing to do with the job itself.

                    1. 1

                      I think there may have been a law banning this in the US or something.

                    2. 1

                      Yep. It’s all a game. I’m planning on putting a year in at one of these companies, getting the line-item on my resume, then getting out. After that, I hope I’ll never have to work for one of these companies for the rest of my life.

                  2. 7

                    When I paint a mental image of these big-tech-interviews, I imagine a monkey jumping through hoops.

                    It still has to be proven that implementing algorithms quickly and explaining how a 3-way-handshake works is relevantly correlated with the position at hand. I’m sad to see that the computer-science-interview process has more and more adapted to this mode rather than check if a candidate as a person brings in the right philosophy.

                    Indeed, there needs to be qualification at hand, and it would be possible to check this in a small subsection of an interview, however, making it almost the sole aspect is worrying. When these people rise up higher in the hierarchy of these companies, other skills are more relevant (soft skills, emotional intelligence, understanding office politics).

                    When these big-tech-companies don’t make selections based on that we shouldn’t be surprised when we end up with managers who lack said skills, are unable to make good business decision and might even be cold-hearted sociopaths.

                    1. 14

                      I haven’t seen it, but I know (several of my colleagues were there when it happened) that they did an internal study at a former workplace, some time before I’d joined, as part of a wider effort to (potentially) revamp the interviewing process after a large reorg. The findings were pretty much unsurprising. It turned out, first of all, that there wasn’t much correlation between the performance in the algorithm-heavy test and post-hiring activity. Worse, though, it turned out that performance in the interview-heavy test wasn’t a good predictor for the hire/no hire feedback, either. People who did very poorly usually got a no hire, but once you got past the “doesn’t know what a linked list is” level, lots of people did great, or at least okay, and got a no hire feedback, and lots of people did poorly but got a “hire” feedback.

                      Eventually, the whole mechanism remained in place (!!), for two reasons.

                      First, no one had an acceptable suggestion for how to go about evaluating fresh graduates (for various reasons, tests that you could take home with your weren’t considered a good idea).

                      Second, while virtually all programmers agreed that the tests were useless, virtually all hiring managers wanted them to stay. Realistically, if you cut through the standard corporate doublespeak, they wanted it to stay for for two reasons. The most important one was that the test and the hire/no hire feedback gave them a rock-solid paper trail for every decision – no matter what happened, they provided the perfect cover. If job performance was terrible, then:

                      • Terrible score, good feedback? I trust my team to make the right decision, mistakes come with the territory of that, and numbers never paint the full picture of a person anyway.
                      • Good score, bad feedback? They did good on the interview, we had our doubts but we have to stay metrics-driven in our decisions.
                      • Good score, good feedback? They looked great in the interview.

                      Bad score and bad feedback obviously didn’t get you hired, and hiring people who did great on the job was obviously considered a success so nobody bothered to examine how that happened.

                      The other reason, which I have heard on more than one occasion (and not just there), is that, I quote, “people know that you have to learn these things if you want to get your foot in the door in our industry and we want to hire people who are willing to do that kind of work”.

                      1. 2

                        Even within Google there’s been recognition (over the past few years) that these whiteboard algorithm interviews are not very predictive of future job performance. We’ve been experimenting with a few alternate approaches, including (for new grads only) an evidence-based path to hiring: even if you don’t seem to be good at algorithms-on-whiteboard during interviews (but can at least write decent code on a laptop & display evidence of being able to learn new concepts during an interview) you can get a 1-year contract to actually work on upto 2 different teams. After that it’s much easier to base a hiring decision on your actual work.

                        1. 1

                          Did we work at the same company?

                          1. 2

                            I don’t know, but the stuff above describes almost every large company I’ve seen – so I guess in a way we did :-).

                        2. 8

                          Apple’s the only FAANG I’ve never been in the pipeline for, so I can’t comment on them. Facebook and Google both seem to be exactly what the stereotypes say: endless laborious algorithm-challenge stuff.

                          Netflix, though, I don’t know if it was just the specific team or not, but their process was really quick. I think something like ten days total from first phone call to onsite. And all the technical sessions involved realistic things the team would actually be doing, and seemed to evaluate on things that would actually matter on-the-job.

                          1. 3

                            Netflix generally does things differently to the big tech companies I believe. It doesn’t surprise me to hear that their hiring process is well thought out too.

                            1. 1

                              I feel like Netflix shouldn’t be compared to the other 4 companies in the list. It’s a lot smaller than them. Thinking of what the acronym would be without the N does explain why people feel the need to include it though.

                            2. 7

                              When I used to interview engineers for FB, the most obvious thing I could tell was when someone had found our interview questions and rehearsed the answers. Beyond that, they weren’t that useful.

                              1. 1

                                How did you judge people who you suspected had rehearsed? Did you see them as cheaters, capable, etc.?

                                1. 4

                                  Where they had clearly regurgitated a memorised answer to the interview question, I noted that I didn’t have any information on their ability to solve novel programming problems.

                              2. 4

                                I feel the same way, even though I think for an SRE the question regarding the TCP three-way-handshake is relevant.

                                However, I also think that the interview process of a big tech company would for the goals of the process and the company not at all benefit from philosophy. “Monkeys jumping through hoops” fits a lot better. Unless you created some widely used programming language, kernel, or are otherwise very distinct in first place in big companies by nature you are a tiny gear and as such an interview process tries to find out whether you can be a tiny gear.

                                Also when you are a big (as in many employees) company what’s important is to have people that quickly can, come, go, be replaced, if needed, simply because it happens more often. While inside a team philosophical alignment probably makes sense, especially in smaller teams where you get to know all the people, to work efficiently, which I guess is why the “eating together” happened I don’t think it is really relevant to have this on a company-wide level.

                                At the end of the day as a regular SRE at a big company you want to know TCP, BGP in and out to troubleshoot problems that occur. I assume the parameters would be something like “doesn’t require long at on-boarding”, “has experience with something that looks like what we have”, “will try to do his best to do what this position requires”, so overall is cost-effective.

                                I also assume that consistent quality work is more important for that position, than for example having people excel , because they perfectly fit also on a personal level At least to me the generic introduction by the recruiters sounds like a “one of many SRE engineers” position, potentially with part of the pay is being able to list Google in the CV.

                                What I want to say is that this process might work very well for Google, because of its size, company structure, form and goals. And given that you sound like you would not want to go through such a process you might not be part of their target audience.

                                Maybe it’s possible to compare this with developing and using Kubernetes or a programming language like Go (just random examples) is not the right decision for everyone, no even somewhat similar companies, when it might be for Google.