12 ms·

I interviewed at Google about a decade ago. I made it far enough that they flew me out to interview on-site at their Kirkland office. I remember feeling like I

• ridiculous_fish 5y ago
  An example context where it wouldn't work is if stdin is closed, e.g. `./a.out <&-`. Awful question, I'm sorry you got hit by it.
  • deleted 5y ago
    [deleted]
• tablespoon 5y ago
  > He was fixated on this one very specific piece of knowledge. IMHO, that's what makes writing interview questions so hard: you really have to know the topic inside and out to know (or at least recognize) all the answers. If you only know one, your question is shit and you might as well have the applicant play guess the number.
  • krisoft 5y ago
    That is silly. Trying to know all the possible answers is a losing game. If I as an interviewer ask that same question and get the freopen answer, and let's say its not one I'm familiar with I can just simply say "I'm not familiar with freopen, could you tell me more about it?" And then I listen to what they say. A competent developer who is worth their salt will be able to summarise the gist of it quickly. Then if I want even more info I might describe the solution I know about and ask the interviewee to compare the two solutions, describe the pros and cons as they see them. What I would be looking for is the proof that the person I'm talking with is able to communicate complicated things clearly, and can think about code. These skills are exactly what one needs in their everyday work, so why not use the opportunity to evaluate them? Does anyone really think that the goal of an interview question is to query if they know that specific trivia you happen to know? And besides if I have doubts about that they are just hoodwinking me with this freopen I can just crosscheck what they told me with the reference. If it turns out to be not a thing at all, that's not a good sign and I will not recommend them to be hired, but otherwise they passed with flying colours.
    • tablespoon 5y ago
      > That is silly. Trying to know all the possible answers is a losing game. That's why I also said "(or at least recognize) all the answers." You're describing some heuristics to recognize a valid yet unfamiliar answer. The point I was making is it's silly to make an applicant guess one answer you know out of many.
• clairity 5y ago
  i had a similar experience wrt a product position. interviewer was fixated on a particular 'right' answer to a trivia-based question. was gladly not a fit there.
  • angelzen 5y ago
    The interview loop is not necessarily an indication of the work environment. It is a chore, 1-2 interviews a week, about a couple hours each including prep & report writing, evaluating a candidate that will not work on your team, except in rare instances. I can see interviewers zoning into a specific answer simply because they have no energy and no interest to explore alternative avenues.
• tylerhou 5y ago
  That’s a terrible interview question. I haven’t been at Google long enough to comment on hiring practices a decade ago, but nowadays I wouldn’t be surprised if an engineer who asked that type of question got feedback from HC to change their question.
• akgerber 5y ago
  I had a similar experience in a problem in which I was requested to extract the digits of an integer before performing some other task. I proposed doing this by converting it to a string and extracting the digits from the string, and that was rejected arbitrarily even though it solved the problem at hand just fine. So I spent entirely too much time during that session recreating an algorithm to extract digits via repeated division/modulo operations that would likely be much slower in practice.
  • tylerhou 5y ago
    > repeated division/modulo operations that would likely be much slower in practice. … but that’s exactly how conversion to string works, so handrolling an algorithm would likely be around the same speed. I don’t know enough about the question, but it’s possible that the interviewer wanted to test this specifically. I’ve had interview questions which were literally “implement itoa.” In this case where itoa was part of a larger question, if I was conducting the interview I would let you convert to string for now so you could continue, but I would let you know that I wanted to revisit the digit conversion later.
    • kongin 5y ago
      >… but that’s exactly how conversion to string works, so handrolling an algorithm would likely be around the same speed. https://github.com/lattera/glibc/blob/master/stdio-common/_itoa.c https://github.com/lattera/glibc/blob/master/stdio-common/_i... It's all bit-shifts, bit-masks and a lot of other hacks to get the maximum performance out of the system you're compiling the code on. Could I write something with better performance on my system? Yeah, after a week to run tests and write esoteric macros.
      • adwn 5y ago
        An optimizing compiler will turn div-by-constant and mod-by-constant into multiplications and bitshifts. For example, the Rust compiler: https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=6ff274d702aec5de7078dba9300c9ac4 https://play.rust-lang.org/?version=stable&mode=release&edit... (select "Show assembly" on the top-left button). pub fn divmod10(x: u32) -> (u32, u32) { (x / 10, x % 10) } generates mov ecx, edi mov eax, 3435973837 imul rax, rcx shr rax, 35 lea ecx, [rax + rax] lea ecx, [rcx + 4\*rcx] sub edi, ecx mov edx, edi ret
• necrotic_comp 5y ago
  This happened with my onsite interview as well. I was working on local, user-based systems and hadn't done anything with networking/web-scale/sharding/etc. I did very well with data structure questions, and had one difficult interview and one question about sharding a globally scaled system. I had never dealt with anything on that scale, and didn't even know how to think about it. I realize that there was a gap in preparation, and I'm confident that that one interview out of 8 is what nixed my chances.
  • the_only_law 5y ago
    > I realize that there was a gap in preparation I had a similar, but not the exactly same issue recently, and about 2/3s through the interview I was stopped and the interviewer kinda poked at my resume and successfully deduced that my prior work experience was just not at the level/scale the company was looking for. How do you prepare for that without having actually worked on that scale. Oddly, I ended up getting an offer for a different position after that though. I can read about subject X all I want, but I would never be confident enough in an interview at just that. And large scale applications isn’t something I can just something I can replace with a side project.
• AJ007 5y ago
  I wonder how dependent Google’s hiring pipeline has been on just having a huge % of every qualified candidate attempting to get a job at Google? If that is the case, then the interviewing process just needs to be good enough to have a low false positive rate. The false negatives don’t hurt them.
  • MaxfordAndSons 5y ago
    Yes this is well documented and I think Google publicly admits it themselves - they optimize to reduce false positives.
  • dolni 5y ago
    I'd be willing to bet that has a lot to do with it. In my younger years I remember being in awe of the simple fact that a recruiter from Google actually reached out to _me_. A decade changes a lot, though. I don't think I would ever want to work at Google now. I'd be curious to know if my shift in perspective on Google is common, and if they're even aware of it.
    • native_samples 5y ago
      When I was young, a Google recruiter reached out to me and I joined the firm. It was the good years and I enjoyed it a lot, learned a lot too. When I was older I quit. I wouldn't want to work there now. The company seems to have changed in deep ways for the worse :(
    • tharkun__ 5y ago
      While I can't tell you how common it really is, I can tell you that we're at least two here. Same with the Amazon recruiters that reach out from time to time.
    • feoren 5y ago
      I absolutely do not want to work for Google. There's an office near me, and the few times I've been considering another job, I explicitly decided not to even send an application there. It sounds kinda like a dead-end hellhole to be honest. So it's not just you.
• the_af 5y ago
  Out of curiosity, which kind of position within Google were you applying for? And how did you sell your own expertise? This sounds like a really bizarre and very specific question for the interviewer to fixate on, unless it was particularly relevant for the position. Knowing the details of how to best do the redirect doesn't seem relevant for a generalist interview; this is the kind of thing you end up, well, googling when you need to do it. I suppose a kernel developer is supposed to know this though, were you applying for kernel development?
  • dolni 5y ago
    It was an SRE position. My technical experience has always been fairly general but largely infrastructure-focused and I had a computer science BS when I interviewed. C only came up because I was asked to provide a list of languages I knew, and rate on a scale of 1 to 10 how well I knew them. At the time when I interviewed, I said I knew a little C (I had used it in a bunch of my CSCI coursework and some small personal projects). So yes, it was an absolutely stupid thing to focus on.
• the_only_law 5y ago
  I understand this was a decade ago, but god this is the type of stuff that makes me want to leave the field.
• jimbokun 5y ago
  > The answer he was actually looking for depended on the knowledge that open() returns the smallest possible file descriptor number -- so close stdout, and simply call open() again. That should never pass any code review.
  • Brian_K_White 5y ago
    I almost wonder if he was really looking for an objection to that proposal, and specifically the reason for the objection. It's the kind of thing I might do but I'd freaking TELL you, and in time so that you know how to handle the rest of the interview. I don't think it's wrong to have a test that exceeds the range of the tested. Really no one should ever ace any test, else the test is insufficient. Thermometers don't just go up to room temp. So a sneaky question that only a truly insightful and thorough person might get, and ballsy enough to challenge the interviewer, and with good enough judgement to know when it's right to talk back, that I myself might not get, is fine. But it's there to identify the exceptional, to provide room in the plot for the spikes instead of clipping, not to kill everyone else. I sometimes give people way too much credit though. I bet it was all face value.
    • dolni 5y ago
      > I almost wonder if he was really looking for an objection to that proposal Nah, he wasn't. Near the end of our time slot, he shared the behavior of open() with me (that's how I learned about it). I told him that doing it that way was silly, because it made the code's intent less clear. He didn't seem impressed.
      • fanf2 5y ago
        Another point on your side is that close(); open(); is racy in threaded programs: to avoid the races you need to use dup2(), but that still has caveats related to losing errors from close().
  • rurban 5y ago
    Neither is it portable. Wonder how the interviewer got hired
• pengaru 5y ago
  Usually such a question is used not to fail you for not having the specific answer, but to observe your ability to reason about it and collaborate with the interviewer on pursuing the desired answer. What questions you ask, what resources you consult, experiments you perform, creativity you demonstrate, openness to alternatives, etc. If you just fixate on your specific first solution and choose to dig in and argue over it despite your interviewer not liking it, it's not a good sign you're someone pleasant or frictionless to collaborate with.
  • taurath 5y ago
    Eh, maybe, but I’m guessing not in this case. Poor interviewers abound.
  • dolni 5y ago
    > Usually such a question is used not to fail you for not having the specific answer, but to observe your ability to reason about it and collaborate with the interviewer on pursuing the desired answer. What questions you ask, what resources you consult, experiments you perform, creativity you demonstrate, openness to alternatives, etc. Trivia questions like that are absolutely awful for demonstrating any of what you're talking about. There isn't any creativity involved. And it's not like the guy followed up with something like "where would you go to determine the answer?" There were 6 or 7 other interviews I went through that had interesting, open-ended questions that allowed me to bounce ideas off the interviewer and share my thought process. This particular interview was not one of them.
    • pengaru 5y ago
      You're right, just like you were in the failed interview.
  • Brian_K_White 5y ago
    "not a good sign you're someone pleasant or frictionless to collaborate with" That sreet must run both ways or it's an invalid charge. If you're reasoning is valid and the interviewer doesn't provide better arguments, then it's the interviewer who is not pleasant or frictionless to work with.
• Brian_K_White 5y ago
  So a Google engineer specifically wants code that relies on side effects? This is one of those cases where you can be proud of a criticism rather than embarassed by it.
  • B-Con 5y ago
    This is an interviewer fishing for trivia knowledge. There are better ways to gauge knowledge competence, but this is an easy way, so people do it.
• praptak 5y ago
  I think that about a decade ago they still used horrible "why is manhole round" questions or "guess the trick" ones. The kind which puzzle-obsessed geeks like to ask eachother but which are horrible for evaluating fitness for a job. This changed. I interviewed 7 years ago and they have fixed this, judging by the questions I got and the interviewer training I received. Using trick questions and fixating on "the" solution was explicitly called out as bad. Of the questions I received two were open ended design questions and the rest was about algorithms and implementing them.
• tmp_anon_22 5y ago
  This sub-thread is missing the forest for the trees. This interview was not the highlight of the interviewer's day. They most likely didn't overthink every angle and every word. They probably were on autopilot looking for some pre-defined criteria - and could care less if the candidate was qualified, accepted, or rejected.
  • dolni 5y ago
    That's plausible, but it doesn't change the fact that the interview was bad.
    • tmp_anon_22 5y ago
      Right but Google really needs to be called out on the amateurism in interviewer training, selection, and quality control, as displayed throughout these comments. They clearly use volume and redundancy to make up for the number of failures. I'm sure they'll come out with the argument "we give xx million interviews, we are within an acceptable failure rate with these outliers". No you're not Google. No you're not.