5 ms·

A perfect job interview could be defined as an interview for which the best study technique is to become a better choice for the role. Studying skills that woul

A perfect job interview could be defined as an interview for which the best study technique is to become a better choice for the role. Studying skills that would not directly contribute to job performance would not change the result of a perfect job interview in any way. In that sense, it's probably a good indicator for Google that the interview advice includes "practice writing code", "make it a habit to validate input", and "learn about data structures", and it's probably a bad indicator for Google that the advice includes "practice writing syntactically correct code on a whiteboard" and "practice solving problems with a 30 minute timer."

shaftway 8y ago
I'm in the interviewer pool @ Google. > practice writing syntactically correct code on a whiteboard This probably differs from interviewer to interviewer as to how strictly it's adhered to, but it's not really a hard and fast rule. I'm sure there are some interviewers that will ding you on a forgotten semicolon, but I suspect that most would not. Personally I look for code that isn't so far from syntactically correct that it's clear you are trying to BS me. I'll even accept pseudocode for the most part. But I've had candidates that try to make up language features, and that doesn't fly with me. > practice solving problems with a 30 minute timer I only give my candidates 30 minutes. The whole interview is 45, I spend 5 minutes introducing myself and setting up expectations, 30 on the question, and 10 on answering their questions (after all, they're also interviewing us). You can tell pretty early whether they're on a solid trajectory, and I'll offer the occasional hint to keep someone on track, or ask tangential questions if they're doing well on time. Not finishing isn't a deal killer, provided you had a solid approach and weren't just running in circles. But a good candidate will finish in about 25 minutes and we can spend some time talking about alternate approaches. Sometimes I'll show them the optional approach and see how that conversation goes. Nine times out of ten a candidate scores low because they overlooked an infinite loop or code would crash on boundary conditions and candidate wasn't able to realize that even with hints.
- CodeMage 8y ago
  > But I've had candidates that try to make up language features, and that doesn't fly with me. This piqued my curiosity. Can you give an example?
  - fjp 8y ago
    I once passed a whiteboard interview just calling random made-up operations on generic java arrays, like Array.flatten(). I was relatively new to programming and had been practicing in Java but didn't know how to execute a lot of map/filter/reduce operations off the top of my head like that. I did, however, know that my interviewer was a Python programmer that probably didn't know much about Java language features.
    - seanmcdirmid 8y ago
      I thought you were allowed to assume functions you needed in the interest of a modular solution. Array.flatten is an obvious “assume I have this, I would write it anyways.” I think most decent interviews will give you a pass on an enhanced standard library.
      - Zelizz 8y ago
        When doing an interview at Google in C, I asked if I could assume I had a hashtable implementation with so-and-so interface, and the interviewer said no ¯\_(ツ)_/¯
        seanmcdirmid 8y ago
        Ouch. Well, most hashtables in C are custom, I guess.
        yoz-y 8y ago
        This depends on the question but I assume that in this case the interviewer wanted a different solution than one using a hash table.
    - sanderjd 8y ago
- ummonk 8y ago
  >Nine times out of ten a candidate scores low because they overlooked an infinite loop or code would crash on boundary conditions and candidate wasn't able to realize that even with hints. I guess this depends on how you run the interview but one of the things that frustrates me about whiteboard interviews that focus on the coding rather than the design is that I have to step through test cases (especially edge cases) like this manually, which is tedious and not at all how you do things in real life, where you just run the test cases and see what happens instead of having to run your own code on a whiteboard.
  - shaftway 8y ago
    My question is about walking around a data structure. Most candidates choose to represent it with arrays. I agree with stepping through code being lame. If a candidate has tried to do some sort of boundary condition check and mentions a test that'd catch it, then I'll give them a pass. If a candidate just blows past the code without any attempt whatsoever to check that they're in bounds on an array, then I'll ding them for that. You have no idea how often I see code like... Node neighbor = data[x+1][y]; ... without any check at all to see if x+1 is in bounds for data. The infinite loop in my question is fairly obvious (because it involves walking around a data structure iteratively). Candidates either see it right away and handle it as they solve, notice it halfway through and crowbar it awkwardly in, or don't notice it until asked to walk through a specific test case, or don't even notice it while walking through the test case. Ultimately, if the code looks correct to me, or even close (I mess up occasionally) then I'll just ask what cases they would test.
    - blumomo 8y ago
      There are however cases where Node neighbor = data[x+1][y]; does not require an index boundary check when you know that 'x + 1 < length(data)' for any 'x'. This could be due to the iteration of 'data' excluding the last element or any other condition that's always hold.
  - seventhtiger 8y ago
    I'm like you in that I used to code "against the IDE and test cases" by basically rapidly iterating and kind of refining as I go along. Always fast to compile and see what happens. Learning to write code on paper for exams and on white boards for interviews actually improved my skills a lot. Maybe not everyone coded like I did, "against constraints", but having to slow down and take into account the constraints mentally led to making better code.
- vips7L 8y ago
  > Nine times out of ten a candidate scores low because they overlooked an infinite loop or code would crash on boundary conditions Why does this even matter? They're writing the code on a whiteboard, without being able to compile or debug, in 20 minutes. Does Google really expect code to be correct and production ready in 20 minutes?
  - robocat 8y ago
    > ... and candidate wasn't able to realize that even with hints. He said why. Why did you misquote?
    - vips7L 8y ago
      That is why they were "dinged". Not why those things matter in whiteboard coding.
      - shaftway 8y ago
        The standard solution to my problem is on the order of 12 lines of code. I don't expect it to be perfect or "production ready", but the infinite loop should stick out like a sore thumb. I do expect candidates to demonstrate that they recognized that problem, and to at least make some attempt to check that they didn't overrun the bounds of an array in the 30 minutes they have.

shaftway 8y ago

I'm in the interviewer pool @ Google. > practice writing syntactically correct code on a whiteboard This probably differs from interviewer to interviewer as to how strictly it's adhered to, but it's not really a hard and fast rule. I'm sure there are some interviewers that will ding you on a forgotten semicolon, but I suspect that most would not. Personally I look for code that isn't so far from syntactically correct that it's clear you are trying to BS me. I'll even accept pseudocode for the most part. But I've had candidates that try to make up language features, and that doesn't fly with me. > practice solving problems with a 30 minute timer I only give my candidates 30 minutes. The whole interview is 45, I spend 5 minutes introducing myself and setting up expectations, 30 on the question, and 10 on answering their questions (after all, they're also interviewing us). You can tell pretty early whether they're on a solid trajectory, and I'll offer the occasional hint to keep someone on track, or ask tangential questions if they're doing well on time. Not finishing isn't a deal killer, provided you had a solid approach and weren't just running in circles. But a good candidate will finish in about 25 minutes and we can spend some time talking about alternate approaches. Sometimes I'll show them the optional approach and see how that conversation goes. Nine times out of ten a candidate scores low because they overlooked an infinite loop or code would crash on boundary conditions and candidate wasn't able to realize that even with hints.

CodeMage 8y ago
> But I've had candidates that try to make up language features, and that doesn't fly with me. This piqued my curiosity. Can you give an example?
- fjp 8y ago
  I once passed a whiteboard interview just calling random made-up operations on generic java arrays, like Array.flatten(). I was relatively new to programming and had been practicing in Java but didn't know how to execute a lot of map/filter/reduce operations off the top of my head like that. I did, however, know that my interviewer was a Python programmer that probably didn't know much about Java language features.
  - seanmcdirmid 8y ago
    I thought you were allowed to assume functions you needed in the interest of a modular solution. Array.flatten is an obvious “assume I have this, I would write it anyways.” I think most decent interviews will give you a pass on an enhanced standard library.
    - Zelizz 8y ago
      When doing an interview at Google in C, I asked if I could assume I had a hashtable implementation with so-and-so interface, and the interviewer said no ¯\_(ツ)_/¯
      - seanmcdirmid 8y ago
        Ouch. Well, most hashtables in C are custom, I guess.
      - yoz-y 8y ago
        This depends on the question but I assume that in this case the interviewer wanted a different solution than one using a hash table.
  - sanderjd 8y ago
ummonk 8y ago
>Nine times out of ten a candidate scores low because they overlooked an infinite loop or code would crash on boundary conditions and candidate wasn't able to realize that even with hints. I guess this depends on how you run the interview but one of the things that frustrates me about whiteboard interviews that focus on the coding rather than the design is that I have to step through test cases (especially edge cases) like this manually, which is tedious and not at all how you do things in real life, where you just run the test cases and see what happens instead of having to run your own code on a whiteboard.
- shaftway 8y ago
  My question is about walking around a data structure. Most candidates choose to represent it with arrays. I agree with stepping through code being lame. If a candidate has tried to do some sort of boundary condition check and mentions a test that'd catch it, then I'll give them a pass. If a candidate just blows past the code without any attempt whatsoever to check that they're in bounds on an array, then I'll ding them for that. You have no idea how often I see code like... Node neighbor = data[x+1][y]; ... without any check at all to see if x+1 is in bounds for data. The infinite loop in my question is fairly obvious (because it involves walking around a data structure iteratively). Candidates either see it right away and handle it as they solve, notice it halfway through and crowbar it awkwardly in, or don't notice it until asked to walk through a specific test case, or don't even notice it while walking through the test case. Ultimately, if the code looks correct to me, or even close (I mess up occasionally) then I'll just ask what cases they would test.
  - blumomo 8y ago
    There are however cases where Node neighbor = data[x+1][y]; does not require an index boundary check when you know that 'x + 1 < length(data)' for any 'x'. This could be due to the iteration of 'data' excluding the last element or any other condition that's always hold.
- seventhtiger 8y ago
  I'm like you in that I used to code "against the IDE and test cases" by basically rapidly iterating and kind of refining as I go along. Always fast to compile and see what happens. Learning to write code on paper for exams and on white boards for interviews actually improved my skills a lot. Maybe not everyone coded like I did, "against constraints", but having to slow down and take into account the constraints mentally led to making better code.
vips7L 8y ago
> Nine times out of ten a candidate scores low because they overlooked an infinite loop or code would crash on boundary conditions Why does this even matter? They're writing the code on a whiteboard, without being able to compile or debug, in 20 minutes. Does Google really expect code to be correct and production ready in 20 minutes?
- robocat 8y ago
  > ... and candidate wasn't able to realize that even with hints. He said why. Why did you misquote?
  - vips7L 8y ago
    That is why they were "dinged". Not why those things matter in whiteboard coding.
    - shaftway 8y ago
      The standard solution to my problem is on the order of 12 lines of code. I don't expect it to be perfect or "production ready", but the infinite loop should stick out like a sore thumb. I do expect candidates to demonstrate that they recognized that problem, and to at least make some attempt to check that they didn't overrun the bounds of an array in the 30 minutes they have.