8 ms·

When I interviewed at Google in 2006, one of the interviewers asked me to write code for solving a particular problem. I replied along the lines of "ok I need

• cobaltoxide 5y ago
  2006 is ancient history. But also, it's a basic interview technique to explain your thinking out loud.
  • throwaway6532 5y ago
    Yeah, in my experience this is really what it's all about. Thinking out loud helps them assess how you reason through trade-offs, potential ideas you run through, edge cases you catch, at what stage you catch them and how you go about addressing them etc.
    • jkubicek 5y ago
      Thinking out-loud also prevents candidates from going completely off the rails. Maybe they missed an important detail or are solving a different problem than what the interviewer intended. These things happen, better to catch them early in the interview.
  • kragen 5y ago
    Wouldn't that fail unless your thinking is as slow as speech?
    • deleted 5y ago
      [deleted]
    • hedora 5y ago
      Not if you can compress your thinking it into something short. Good code interviews test communication skills too.
      • actually_a_dog 5y ago
        No, they don't, generally. When was the last time you were required to compose code in a real world situation, in front of someone, while talking through your thought process, all under time pressure and in a high-stakes environment?
        • kragen 5y ago
          Every time I pair program. Also sometimes I've given talks that way. I like it, I guess not everybody does.
          • actually_a_dog 5y ago
            You pair program under time pressure similar to interview conditions? Really? I find that hard to believe. As for giving talks that way, I would not say that qualifies as a high stakes environment. Your likely worst case scenario is that either your code or some bit of technology involved doesn't work right, so you laugh it off and explain what was supposed to happen.
            • kragen 5y ago
              When I'm working on a product I'm under time pressure: we need to get this feature done so we can move on to the next, or we need to fix this bug — possibly the site is down, or the customer's system is compromised, until we get it done. In an interview there's a sort of "pressure" but it's like the pressure of playing a video game or taking a math test or lifting weights: I'm working hard to do my best, but nothing really depends on it. It's just a difficult challenge I'm completing, the only purpose being to see (and, well, show) how well I can complete it. The worst case scenario in a talk is that I say something stupid and get really dogmatic and defensive about it, leading the hundreds of people watching the talk to conclude that I'm an ignorant jerk, which, well, I can be, but I'd rather they didn't overestimate the frequency of that! I could lose face. The worst case scenario in an interview is that the person interviewing me says something stupid and gets really dogmatic and defensive about it, and then they and their company lose face. Oh, and they could decide not to offer me the job. But that's never been much of a problem, and it's certainly no big deal — if you're only interviewing for jobs you're almost sure to be offered, you should probably interview for more advanced positions. Not being offered a job is far from "losing out on a big opportunity", as you said in your other comment. A job gives you money enough to live on, but if you're a programmer jobs that pay a living wage are plentiful. (But less plentiful if people go to your talks and decide you're a nincompoop or a scumbag.)
• chrchang523 5y ago
  To be fair, engineers didn't all have smartphones that could take great photos in 2006.
  • Symbiote 5y ago
    I did a Google interview around then, and the interviewer photographed my code with an ordinary digital camera.
  • irrational 5y ago
    Did anyone have a smartphone that could take great photos in 2006?
    • masklinn 5y ago
      Depends what you mean by great, but there were a number of phones with 2-3mp cameras, more than sufficient for a whiteboard. And regardless it was an interview structured with a whiteboard, cameras (digital or not) had been things for a while, the company could gave provided one.
      • deleted 5y ago
        [deleted]
    • Ekaros 5y ago
      Nokia 7650 was released in 2002 it had camera, though picture quality is not great.
    • porbelm 5y ago
      My Sony Ericsson K750 took pretty nice 1.3 MP photos for the time (launched 2005), it was better than my 1.3 MP Olympus Camedia C-860L from ca five years prior and was my main camera until DSLRs got cheap enough.
  • CountHackulus 5y ago
    Cameras existed before 2006.
• bumper_crop 5y ago
  > Why interviewers were all transcribing the whiteboard rather than taking photos I have no clue. It makes it easier to reason about the code. It's the difference between typing out the answer from Stack Overflow, v.s. copy pasting it. At least for me, writing the code down at the speed the candidate does triggers the error checking part of my brain.
  • readams 5y ago
    It's just because the interviewing tool you have to put your notes into at Google takes text and not pictures :-). The hiring committee will actually look at this, and this is a different person from the interviewer.
    • cperciva 5y ago
      Ok, but they were transcribing from the whiteboard onto paper. So everything I wrote must have been transcribed twice before it reached the hiring committee.
      • joatmon-snoo 5y ago
        2006 was... early. I don't remember when HCs were formed, but there's no way the internal ATS had any level of sophistication, if it even existed then. (Admittedly this is all years before my time.)
        • cperciva 5y ago
          From what the recruiter told me, there was a hiring committee but their recommendations had to be approved by the founders before an offer could go out.
      • teirce 5y ago
        Isn't this a bit of revisionist thinking? I don't know that cameras of that quality were commonplace in 2006. It's not like you could just pull out your iPhone. And most digital cameras weren't much better (i.e. I wouldn't trust being able to read handwriting from their pictures). So then what, you supply each interviewer with a roll of film and a company darkroom? It's also easier to write your own notes down this way too.
• tomatowurst 5y ago
  The two aren't mutually exclusive, you could've easily started out with salary + stock options that would've put you in a better position to start a side gig. Then you might actually be driving a lambo now too ;)
  • Flankk 5y ago
    Speaking from experience or from the ass? In my experience a startup is all consuming.
    • tomatowurst 5y ago
      tarsnap is a one man show and he's not building a startup. he could've easily worked at Google, take advantage of the rising stock prices AND continue work on his SaaS. Lot of us do exactly that because it doesn't make sense to leave a good paying job at a large company to take on tremendous risk at as you said, consuming endeavour with small probability of success (+90% failure rate). I don't get why people are so upset at my comment or why that should warrant ad hominem attacks. I merely mentioned that parent could've had a job at Google and benefited from it. He made it sound like it was a power move, it really wasn't. My argument is only that he took on even more risk by not taking advantage of Google's offer and growing stock prices to fund his passion. He doesn't seem like the type to get distracted by a day job either.
      • dsr_ 5y ago
        Your comment was critical without being in any way helpful, and you tried to defuse it with a smiley. It doesn't warrant ad hominem attacks, but hardly anything does.
      • deleted 5y ago
        [deleted]
      • HWR_14 5y ago
        > he could've easily worked at Google, take advantage of the rising stock prices AND continue work on his SaaS. Wouldn't Google then own all the code he wrote, even on his own SaaS sideproject?
• f0e4c2f7 5y ago
  This story strikes me as pretty funny. As if he might say "damn, I was hoping you knew. We've been working on this one for weeks!"
  • krono 5y ago
    Near the beginning of a class, Professor Neyman wrote two problems on the blackboard. Dantzig arrived late and assumed that they were a homework assignment. According to Dantzig, they "seemed to be a little harder than usual", but a few days later he handed in completed solutions for both problems, still believing that they were an assignment that was overdue. Six weeks later, an excited Neyman eagerly told him that the "homework" problems he had solved were two of the most famous unsolved problems in statistics. https://en.wikipedia.org/wiki/George_Dantzig https://en.wikipedia.org/wiki/George_Dantzig Reminds me of that :) edit: Here's a slightly more colourful telling of the story: https://www.snopes.com/fact-check/the-unsolvable-math-problem/ https://www.snopes.com/fact-check/the-unsolvable-math-proble... Does anyone happen to know which two problems Dantzig solved? Don't seem to be having much luck on my searches
    • caf 5y ago
      There's a lesson there too about how solving problems is often easier once you know it can be solved.
      • JadeNB 5y ago
        > There's a lesson there too about how solving problems is often easier once you know it can be solved. Or perhaps when you don't know it can't (yet) be solved.
    • betamike 5y ago
      Hah! This reminded me of a similar story: "In 1951, David A. Huffman and his MIT information theory classmates were given the choice of a term paper or a final exam. The professor, Robert M. Fano, assigned a term paper on the problem of finding the most efficient binary code. Huffman, unable to prove any codes were the most efficient, was about to give up and start studying for the final when he hit upon the idea of using a frequency-sorted binary tree and quickly proved this method the most efficient.[5] In doing so, Huffman outdid Fano, who had worked with Claude Shannon to develop a similar code. Building the tree from the bottom up guaranteed optimality, unlike the top-down approach of Shannon–Fano coding." https://en.wikipedia.org/wiki/Huffman_coding#History https://en.wikipedia.org/wiki/Huffman_coding#History
• lkschubert8 5y ago
  Maybe it's just me, but the interviewer not knowing the solution is extremely off putting.
  • moffkalast 5y ago
    > and if there wasn't anything for him to copy down into his interview notes I wasn't going to pass the interview Also like outright lying, given what happened next. Not exactly the best company culture.
• vkou 5y ago
  > (Why interviewers were all transcribing the whiteboard rather than taking photos I have no clue.) Because they have to transcribe it anyways, and because it's hard to read blue on white, or green on white in a photo. Also, if some part of your handwriting is illegible, or you've made some ambiguous errors, or whatever, the interviewer can ask you what you meant, instead of having to make an after-the-fact assumption, long after you've left.
• bityard 5y ago
  I interviewed with Google once around the same time frame. The position I interviewed for was something along the lines of datacenter operations. I did my interview from a local Google sales office and interviewed with three other employees via video call. This was around the time that Skype was fairly new, but whatever software they were using was clearly internal to Google. Anyway, I ended up talking with 3 engineers. The first one asked me about stuff on my resume, my Linux experience, some hardware, software, and network questions, etc. He seemed pretty nice and I thought that session went well. The second guy was a different story. It started off well enough but then he asked me how I would go about repairing a server that wouldn't boot. I asked him a few preliminary questions (does it have power, did anyone touch it recently, does it POST, etc) and then talked about which components I would swap out and in what order and why. After every piece of hardware, he would say, "it still doesn't boot, what do you do next?" I ran out of hardware to think of swapping and he eventually got visibly annoyed and began to lecture me on the troubleshooting process. Now, I was young but I wasn't green and probably got flustered and defensive in response. I'm certain that cost me the job or at least my chances of advancing to the next round of interviews. The next guy I talked to noticed my military record and only wanted to talk about airplanes and helicopters. I humored him while attempting to steer the conversation back to the position but he wasn't having it. I'm sure he knew the previous guy gave me a strike against and was just killing time. A few days later I got an email from Google saying that they had passed on me. Which as it turns out was probably a good thing because A) Google turned into a much different company in the years following that, and B) they never actually built the datacenter that I would have worked in anyway.
  • genewitch 5y ago
    so, what was the answer, from the lecture? what had you missed? Realistically if i was in datacenter ops and a server wouldn't boot i'd unrack it and rack a new one and let the dev/ops whatever team reprovision. Heck, i did this when i was just a cloud engineer, unracked from a local (non-cloud) facility and brought back machines to the office, to be RMA'd, just to help out. I get the idea that the interviewer had a very specific problem in memory and wanted that answer. After all, if there's some issue with the motherboard, it doesn't matter how many parts you swap out, and an issue with the motherboard could be in the infinite range from "tin whiskers" to "bad capacitor" to "cold solder joint".
• dudeinjapan 5y ago
  I had something like this too for a quant trading interview. It was one of those problems about flipping a coin, heads doubles your money and tails you lose everything, "how much would you pay to play the game?" If forget the nuance of the question but when I did the math on the whiteboard, the expected value was 1 i.e. the same amount one wagers. At that point I said, "Well, I guess I could pay for the entertainment value... how much do I owe you for this interview?"
  • dfabulich 5y ago
    That sounds almost like the St. Petersburg Paradox. (But in the paradoxical version, you keep whatever's in the pot; you don't lose everything at the end.) The St. Petersburg game has an infinite expected payout! But most people would only be willing to wager $20 or so, and it's hard to articulate exactly why. https://plato.stanford.edu/entries/paradox-stpetersburg/ https://plato.stanford.edu/entries/paradox-stpetersburg/
    • l33t2328 5y ago
      I don’t think it’s hard to articulate why. The reason why is that expected value places too much emphasis on low probability edge cases. With 75% probability, you make at most 4 dollars. There’s almost a 94% chance you make less than 40 dollars. As humans, we evaluate improvable events as not mattering so much.
    • ars 5y ago
      The math and discussion of infinity in the problem unnecessarily complicate it. You could ask: You have a 10^-30 chance of winning $10^40, otherwise you'll win $1. Based on expected utility you should pay a huge sum to play, based on the real world you should pay $1. (Adjust the large numbers as needed if you have an issue that that much money doesn't exist.)
    • seebs 5y ago
      It's not hard to articulate why: Nearly all the large numbers are beyond what anyone can actually pay. If you assume that the bet pays out at most 4 billion dollars, and simply can't pay more than that, suddenly the expected value is $32, instead of "infinite".
• Melatonic 5y ago
  Did you talk to the interviewer at all during this? I could see them wanting to know your thought process to solving an unsolveable problem but otherwise this seems a little far fetched. Probably they just really liked you?
• dekhn 5y ago
  That's really unprofessional. I've never talked to anybody at Google who administered a "I don't know the algorithm" interview like that. They would have been spanked badly by the interview committee, if repeating this behavior. If I may ask, why in that interview did you just sit there and not ask any questions? I've passed code interviews where I learned an entire new algorithm on the fly (funny how knowing there is an nlogn solution to an n**2 problem can produce workable solutions).
  • cperciva 5y ago
    I should have been clearer. After thinking for a bit I did start asking questions, but the interviewer didn't give me any useful information. IIRC I asked if I could assume the problem was small enough that I could just do a brute force search of possible solutions and the answer came back that no, they needed a solution which would work for any size; I know I asked other questions but I can't remember what they were. I wasn't silent for half an hour, just for the first couple minutes; but I didn't write any code (which is what the interviewer was pressing me to do). (Speaking of entirely new algorithms though, there was an interview question which was a thinly disguised 3SUM, and they expected the very obvious N^2 solution; my interviewers were shocked when I pointed out that the way they had structured the problem, the density was high enough to use a convolution and solve it in N log N time.)
    • qumpis 5y ago
      What structure should there be for nlogn solution to be applicable?
      • cperciva 5y ago
        The issue isn't structure but rather density. If you have N values ranging from -M to M, the "obvious" solution is O(N^2) and the convolution us O(M log M). So if you have lots of values within a narrow range the convolution wins.
• bcrosby95 5y ago
  Something similar happened in my first job out of college. During an interview, the person goes over a problem related to graphs. Then asks me if I could come up with a solution. I told him I had trouble following the details and the interview wasn't long enough for me to both figure that out and solve the problem. I still got the job. I still don't know why he asked it of me. Eventually I found out that it was an actual problem he was trying to solve for work, and it relied upon a lot of domain specific knowledge that I didn't have at the time.
• morpheuskafka 5y ago
  > At the time, I thought he just meant that he had no idea what the solution was; but in hindsight I wonder if the real test was to see if I would crumble under pressure and write code I knew didn't work. This doesn't totally make sense, most people would have interpreted that to mean they should quit talking and make their best effort to actually write something. It's not at all the same as pretending something works when you know it doesn't in an actual job, it's more like writing what you can on a test and hoping to get some partial credit.
• anitil 5y ago
  I don't think I would have the self confidence to sit there quietly thinking.
• palisade 5y ago
  The interview with Google is a pretty harrowing test.
• mnw21cam 5y ago
  My first job interview out of university, I was asked how to have separate independent database servers, each able to read/write to the same status field, synchronised between them over an unreliable network, with consistent and atomic updates being written by any of the servers. Having covered this only a year previously, my answer was that CAP theory stated that this was theoretically impossible. However, their particular actual problem was slightly more relaxed than requiring full consistency, atomicity, and partition-tolerance. The different servers could only perform limited kinds of status transition - there was no transition that could be performed on more than one server, and status transitions were mostly one-way - most of them couldn't be undone. Also, the field only had to be eventually-consistent, and updates didn't need to be ordered. So, I offered them a way to cheat by splitting the status field up into essentially a log of operations, which naturally resolved the conflicts. I got the job.
• munificent 5y ago
  I think you're operating under a misunderstanding of how these interviews work. The goal is not to see how many algorithms you know. Algorithms are easy to learn on the job. The goal is to see how you think in a social setting. How you approach a vague, imperfectly stated problem. Do you ask questions to gather more requirements? State assumptions? Then, based on that, how you try to break it down into smaller pieces. Are there different ways to model the problem or lenses you can apply? Can you think of this as a graph? A tree? A database? Can you incorporate ideas from the interviewer on the fly? The software engineering job is about taking vague problems and turning them into working code with a help of a team, and the interview process is trying emulate that as best as possible under the weird limitations of an interview. You can pass an interview without getting any of the "answers" "right" and you can fail them even while blasting out perfect algorithms on the whiteboard.
• areyousure 4y ago
  What was the problem?