7 ms·

Yet another "trust the system" message from the authority figure who enables the system. Similar: - Police officer: Just follow our instructions, be cooperativ

• rrix2 8y ago
  I read it as "I'm trying to make sure I don't hire someone who isn't willing to work with me, and the system allows me to do that." I can't speak for anyone but myself obviously, but I think I interview at Uber a similar rate to your average Google engineer (2-3 times a week), and our interviewing process is pretty similar to what's laid out here. In cases where the interviewer is hiring for their own team, I feel like it's reasonable to assume that the interviewer is trying to hire people they want to work with. Acting in their own self interests, as it were. In some cases that may mean "I want to make sure you are someone I'm able to collaborate with." In some cases that may be "LeetCoding like hell". Regardless, if that's what the interviewer is looking for, the candidate gets a really important insight in to the team they'd be working for and not necessarily indicative of some larger corporate conspiracy.
  • halflings 8y ago
    Google engineers don't interview people they work with (except rare cases). Interview notes go through a committee, so your job as an interviewer is only to describe how things went with the candidate (as explained in this twitter thread).
• SquishyPanda23 8y ago
  FWIW, I went through the interview process and I actually really enjoyed it. My attitude going in was that I was evaluating what it would be like to work there, and I treated the interviewer as a coworker solving a technical problem, where I was taking the lead. The questions I got were pretty much exactly the sort of hing you see on LeetCode, but I hadn't seen any of the questions before. I know from studying for other technical exams that once you reach a certain number of practice problems, pattern recognition takes you a long way. I had a similar experience at Facebook. Everybody was super nice, they all wanted you to do well, and they all responded well to being enthusiastic and genuinely interested in the problems you're solving.
  • MarkSweep 8y ago
    > Everybody was super nice, they all wanted you to do well I had the same experience. Afterwords I thought I did pretty well because I got to a solution to all the problems eventually. Later when I discussed not getting the offer when a friend who works at Google. He said they try to guide the interviewee to a solution before the time limit. Which is reasonable, you want the interviewee to feel more confident and not get tilted by messing up just one question. However in hindsight the interview is a lot less enjoyable. You can't show any weakness solving a problem, less they offer you a "helpful hint" and record a black mark against you. The interviewer is there to smile and act like your colleague solving a problem while all the while making a list of why your a bad problem solver. I'm not that bitter though. The interviewers that asked me questions actually related to the position I was interviewing (embedded software) did actually feel fun and collaborative. I accept that if I want to interview well at companies that employ these types of interview processes I will need to do every problem in CLRS (or at least more than zero).
    • chaosite 8y ago
      Getting the interviewee to a solution was not part of how I was trained to interview at Google.
    • SquishyPanda23 8y ago
      I haven't been on the interviewing side, so I can't really comment on some of this. But the impression I got as the interviewee was that every question ramped up in difficulty. The slope of the ramp-up depended on the question. So maybe in your case, you didn't get as far on the difficulty ladder as other people that were interviewed. I was pretty shameless in asking for hints when I needed them, but it was typically of the form "I see this tradeoff here, and my gut says to do X, is that reasonable?" I'm sure some of that counted against me, but I was blunt about what I needed to make a decision and solve the problem, and I think overall that reflected well on my ability to problem solve on a team. I would definitely not recommend doing every problem in CLRS. I would recommend doing just about every problem in Cracking the Code Interview (because they have nice answers), and then getting into a rhythm of doing LeetCode problems every day until the interview.
• ganeshkrishnan 8y ago
  Not sure about Google but in IBM when I was conducting tech interviews I was looking more for team members to help me complete the project rather than trying to project an authority figure. The relationship was never adversarial and if you know how desperate we were to get good skills there is not much option to take the high ground. The poster is correct that open ended questions that reveals the work ethic of team members are much more important than solving algorithms and hard problems. Intelligence is over rated.
  • colechristensen 8y ago
    My (pre?) interview with Google was little more than trivia questions. Example: the numerical value of SIGTERM. I could have talked about signals and how they were used for 20 minutes, but a nontechnical phone interviewer just wanted trivia answers.
    • closeparen 8y ago
      I want to think that’s a terrible question - checking whether they have the signal table memorized is a hilariously bad way of trying to assess someone’s fitness as an engineer. On the other hand, there’s some signal (sorry) on the nature of the work you’re doing in whether SIGTERM (15) is imprinted in your brain from near-daily appearance on your screen, or not.
      • Cursuviam 8y ago
        Yeah, the only reason I can remember SIGKILL (9) is because of kill -9.
      • akvadrako 8y ago
        I don't think so, unless you are referring to some kind of atypical terminal work. I just tried killing a console program and I see "Terminated: 15". That's not a line I even recognise - it's not common or important enough to bring to my attention. I would say a vital command-line skill is having a good filter to ignore what's irrelevant.
    • 8y ago
• pfarnsworth 8y ago
  Yeah, I call bullshit as well. Try getting to the onsite if you don't solve the phone screen question exactly as expected. I have a friend who solved/memorized ~600 leetcode questions and got offers from Google, Facebook, etc. He was average, not dumb but not well above average. When I apply to both, I will definitely be leetcoding as many question as possible as well, to maximize my chances.
  • foobarbazetc 8y ago
    If that’s all it took maybe those interview funnels aren’t actually that great. IME, my worst interview process ever was at Google. All I remember from it was some question about burning a piece of string. The coding part was relatively easy. The best interview process I ever did was at Yahoo in 2008. Everyone was very friendly but the questions were tough. I found the “expert” level of the people interviewing me higher than at Google at the time. It was grueling though - 9am to 7pm. Got an offer to “join any team I wanted”. Turned it down for a startup. Good decision in hindsight.
    • ReverseCold 8y ago
      The string problem where you burn it in creative ways in order to measure a certain amount of time?
      • komali2 8y ago
        Probably: You have two identical ropes. If you light a rope on fire, it will finish burning in exactly one hour. The burn rate is inconsistent - there is no relationship between how much of the rope has burned, and how much time has passed, until the rope has fully burned away. How can you use the two ropes to measure 15 minutes? Given that it's printed in cracking the coding interview, Google has almost certainly banned this problem.
        • joatmon-snoo 8y ago
          That's also a brain teaser type problem that we killed over ten years ago.
• AmericanChopper 8y ago
  Your examples aren’t particularly on point. You should (nearly) always do what police officers tell you because even if they’re wrong, the only thing you can do on the scene is make it worse for yourself, and your car salesman example is simply suggesting that you shouldn’t negotiate. The fact is that Googles interview process isn’t designed to work for you or I, it’s desiged to work for them. The key factors that influence it are that they get tons of applicants, and they have a strong preference to eliminate false positives (which they can afford due to the previous point). I’m not sure why somebody (seemingly earnestly) trying to help potential applicants understand the process should be the target of anti-authority criticism.
• ender7 8y ago
  Some perspective from the interviewer's side may help here: - A Google interviewer's (and I would assume any interviewer's) primary goal is to come out of the interview with enough confidence to give a positive or negative score. If they sit down to write feedback and have to give a neutral score, the interview wasn't productive. This means that the interviewer is just as eager to find evidence for a positive score as a negative one -- there isn't an incentive to "getcha" with cheap or tricky questions. - Doing interviews at Google is volunteer work. You are not interacting with a professional interviewer, you're interacting with someone whose day job is being an engineer. They don't have an evil agenda; they are doing this because they want to help Google hire the best candidates, and by inference make sure their future coworkers are good people to work with. - Interviewers overwhelmingly _want_ their candidates to succeed. It's a true joy when I have a candidate who glides through a question (or finds a solution that was even better than mine). When candidates struggle, it's not a pleasant experience for the interviewer either. - In the end, the point of technical interviews is to avoid the terrible experience that is working with an incompetent or uncooperative teammate. Interviewers are trying to find people that (a) can work well with others and (b) can get the work done. - The system is _highly_ prejudiced towards suppressing false positives. This is the right decision, but it comes at the cost of a high rate of false negatives. Were myself or any of my colleagues to re-interview for our jobs, I would expect about a 60% hire rate. This is not even taking into account the constant ebb and flow of hiring demand. Sometimes there just isn't any headcount. And sometimes you just happen to get questions that you don't click with. This is also the reason that recruiters are so eager to bring you back to interview 6 months later. - Recruiters and interviewers have very different incentives. Recruiters want to maximize the number of people they get hired; interviewers want to hire people they want to work with. This can lead to behavior that seems schizophrenic from the outside: the recruitment side of the pipeline constantly pestering people to interview, but once the candidate enters the interviewing pipeline the process is slow, deliberate, and careful.
  • vezycash 8y ago
    Aren't recruiters paid a commission for successful hires? Also, do interviewees who choose to interview a second time have a higher pass rate? Consider their financial incentives first before ascribing some altruistic motives.
• curiousDog 8y ago
  Exactly. The bottom line is every interviewer is different and comes with their own quirks and biases. Writing another me too post just because you squeaked through the 5hr gambit isn't going to help anyone. I've met some interviewers (Google and elsewhere) who were incredibly arrogant, some who just wanted to see the solution and copy it down for proof etc. It's not black and white. Something has to change here.
• dukoid 8y ago
  The list contains good tips for avoiding getting nervous about something that's just normal practice, wasting time or running into a dead end. If you are concerned about the process, company culture or have any other concerns, use the time for questions at the end of the "main" interview. Interviewers will have better insights into the actual life of an engineer at G than recruiters. They don't have any incentive to misrepresent anything.