4 ms·

"Estimating it from the taxes paid to the state, I would say 0€." (Yes, that’s not the kind of expected answer)

by titanix2 8y ago

expertentipp 8y ago
Satisfacton from saying this during an interview at Google would be worth not getting the job:)
- deleted 8y ago
  [deleted]
- jkingsbery 8y ago
  TRUE STORY: I interviewed at Google earlier in my career. In one of the interviews, the interviewer asked me to recite/reconstruct off the top of my head the convex hull algorithm. I remembered the lectures in undergrad algo class where the professor talked about it. I remembered where in CLRS it was covered. I remembered the general outline (efficient algorithms are O(n log n), because you have to sort the points as one of the steps). But I was struggling to remember the details, because, you know, I hadn't worked on that sort of thing in several _years_. So, the interviewer started pacing around the room, impatient that I couldn't remember the details (or recite in 10 minutes what it took a professor with notes 2 lectures to go through). He told me finally "We expect Google engineers to be able to solve problems. What if you were a Google engineer, and you had to solve this problem, what would you do?" There is, of course, only one right answer to that question, which I provided: "I would look it up in a book. I know exactly where to find it." I wouldn't spend time trying to reinvent an algorithm that someone else had already thought of. The interviewer did not like that answer. I did not get a job offer. Now that I interview candidates at a different large tech company, I make a point to not get hung up on things that are easily researchable.
  - ergothus 8y ago
    As an interviewer I always advocate for coding problems to be done at the computer and to allow internet searches. On the rare occasions someone does a cut-and-paste solution, I then modify the problem to see if they understand the solution enough to make the necessary change. It's not perfect, but it seems as close to the actual work experience they are interviewing for. I interviewed at Facebook recently and was shocked when they used Coderpad but did not allow code execution. Threw me for a loop, because I like to decompose problems and test that everything is still working as I add to it, something this did not allow me to do. I consider that a GOOD quality, why prevent me from demonstrating it?
    - xsmasher 8y ago
      I do that; I ask candidates to code in notepad instead of an environment where you an compile, and it's intentional. Failure come in three types - bad understanding (failure to understand the problem), bad planning (plan doesn't actually solve the problem), and bad implementation (failure to implement the plan correctly). The third type includes typos and off-by-one errors that I don't want the candidate to get hung up on. I might ask about an issue if I spot it, but if not I'd rather keep going on the more relevant parts of the solution. Also, you can leave part of the solution in pseudocode without getting distracted by a bunch of squiggly underlines, and handwave away parts of the problem that we don't care about.
  - jacquesm 8y ago
    > We expect Google engineers to be able to solve problems. Sounds more like he expects Google engineers to have perfect recall, rather than to be able to solve problems. That's just a trivia question, nothing to do with problem solving.
    - stevenwoo 8y ago
      If I wanted to have a job that required perfect recall, I would have become a doctor. Maybe I should have if that is what this industry is going to require.
  - mgkimsal 8y ago
    > "What if you were a Google engineer, and you had to solve this problem, what would you do?" Well... I might ask one of the other people on the team (or in the company) for some help. Because I'm probably going to ask one of them for a review (or someone else will review it anyway). No man is an island, etc. What did Sergey and Larry do to solve these problems? They hired more people!
    - raverbashing 8y ago
      They consulted existing literature, they asked in internet forums, etc Expecting people to know and remember beyond the basics is simply ridiculous especially at the age of Google
  - titanix2 8y ago
    > "What if you were a Google engineer, and you had to solve this problem, what would you do?" "I would Google it", and this time the answer is very corporate! Still not what's expected by the interview, but it would be funny to watch him argue that the main product of its employer is not qualified for the task. Besides, I find it silly too to ask for details that are easily found in printed material, with less probability of mistake than remembering it.
  - kanelbullar 8y ago
    He told me finally "We expect Google engineers to be able to solve problems. What if you were a Google engineer, and you had to solve this problem, what would you do?" At that point - he's talking to you as if he thinks you have the understanding of a child, basically. There really is no positive recourse available other than to politely end the interview, and chalk up another day of your life (plus N days spent preparing) that you'll never get back.

"Estimating it from the taxes paid to the state, I would say 0€." (Yes, that’s not the kind of expected answer)

expertentipp 8y ago

Satisfacton from saying this during an interview at Google would be worth not getting the job:)

deleted 8y ago
[deleted]
jkingsbery 8y ago
TRUE STORY: I interviewed at Google earlier in my career. In one of the interviews, the interviewer asked me to recite/reconstruct off the top of my head the convex hull algorithm. I remembered the lectures in undergrad algo class where the professor talked about it. I remembered where in CLRS it was covered. I remembered the general outline (efficient algorithms are O(n log n), because you have to sort the points as one of the steps). But I was struggling to remember the details, because, you know, I hadn't worked on that sort of thing in several _years_. So, the interviewer started pacing around the room, impatient that I couldn't remember the details (or recite in 10 minutes what it took a professor with notes 2 lectures to go through). He told me finally "We expect Google engineers to be able to solve problems. What if you were a Google engineer, and you had to solve this problem, what would you do?" There is, of course, only one right answer to that question, which I provided: "I would look it up in a book. I know exactly where to find it." I wouldn't spend time trying to reinvent an algorithm that someone else had already thought of. The interviewer did not like that answer. I did not get a job offer. Now that I interview candidates at a different large tech company, I make a point to not get hung up on things that are easily researchable.
- ergothus 8y ago
  As an interviewer I always advocate for coding problems to be done at the computer and to allow internet searches. On the rare occasions someone does a cut-and-paste solution, I then modify the problem to see if they understand the solution enough to make the necessary change. It's not perfect, but it seems as close to the actual work experience they are interviewing for. I interviewed at Facebook recently and was shocked when they used Coderpad but did not allow code execution. Threw me for a loop, because I like to decompose problems and test that everything is still working as I add to it, something this did not allow me to do. I consider that a GOOD quality, why prevent me from demonstrating it?
  - xsmasher 8y ago
    I do that; I ask candidates to code in notepad instead of an environment where you an compile, and it's intentional. Failure come in three types - bad understanding (failure to understand the problem), bad planning (plan doesn't actually solve the problem), and bad implementation (failure to implement the plan correctly). The third type includes typos and off-by-one errors that I don't want the candidate to get hung up on. I might ask about an issue if I spot it, but if not I'd rather keep going on the more relevant parts of the solution. Also, you can leave part of the solution in pseudocode without getting distracted by a bunch of squiggly underlines, and handwave away parts of the problem that we don't care about.
- jacquesm 8y ago
  > We expect Google engineers to be able to solve problems. Sounds more like he expects Google engineers to have perfect recall, rather than to be able to solve problems. That's just a trivia question, nothing to do with problem solving.
  - stevenwoo 8y ago
    If I wanted to have a job that required perfect recall, I would have become a doctor. Maybe I should have if that is what this industry is going to require.
- mgkimsal 8y ago
  > "What if you were a Google engineer, and you had to solve this problem, what would you do?" Well... I might ask one of the other people on the team (or in the company) for some help. Because I'm probably going to ask one of them for a review (or someone else will review it anyway). No man is an island, etc. What did Sergey and Larry do to solve these problems? They hired more people!
  - raverbashing 8y ago
    They consulted existing literature, they asked in internet forums, etc Expecting people to know and remember beyond the basics is simply ridiculous especially at the age of Google
- titanix2 8y ago
  > "What if you were a Google engineer, and you had to solve this problem, what would you do?" "I would Google it", and this time the answer is very corporate! Still not what's expected by the interview, but it would be funny to watch him argue that the main product of its employer is not qualified for the task. Besides, I find it silly too to ask for details that are easily found in printed material, with less probability of mistake than remembering it.
- kanelbullar 8y ago
  He told me finally "We expect Google engineers to be able to solve problems. What if you were a Google engineer, and you had to solve this problem, what would you do?" At that point - he's talking to you as if he thinks you have the understanding of a child, basically. There really is no positive recourse available other than to politely end the interview, and chalk up another day of your life (plus N days spent preparing) that you'll never get back.