8 ms·

> There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be interested in learning them. Interview process:

> There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be interested in learning them. Interview process: complete success.

untog 10y ago
Depends what the job description is, surely. And if the developer isn't interested in working on these things, surely it's failure on Google's part to effectively target who they are approaching?
- johannes1234321 10y ago
  The job description is "Software Engineer at Google" They hire some special roles from time to time, but then they approach people differently (i.e. on a personal level) otherwise they hire people they ideally can move easily from project to project.
johannes1234321 10y ago
For a complete success they would have a way to filter out people without algorithm knowledge early on. A day of interviews already costs them some money, especially on the scale they are doing this.
- stuckagain 10y ago
  Yeah maybe you are right on that point. At Google at least the filtering by stage seems to be: Recruiter phone interview: do you speak English? Technical phone interview: have you ever programmed a computer before? Technical on-site interview: do you know a few things about data structures and algorithms?
  - iainmerrick 10y ago
    What's funny is that Google seems to think they're really good at interviewing -- for example, see this Washington Post puff piece: https://www.washingtonpost.com/business/capitalbusiness/an-inside-look-at-googles-data-driven-job-interview-process/2013/09/03/648ea8b2-14bd-11e3-880b-7503237cc69d_story.html https://www.washingtonpost.com/business/capitalbusiness/an-i... Possibly they are, but it's hard to see solid evidence one way or the other. I guess they can't be really bad in the sense of hiring mostly bad candidates, as that would surely cause big problems before long. But they could be about the same as other big bay area companies.
fernandopj 10y ago
> If she would have started her email with "We're looking for an algorithm expert," we would never have gotten any further and would not have wasted our time. Clearly, I'm not an expert in algorithms. This phrase precedes the one you mentioned. He's saying the process he has been through completely ignored his background and field.
- rpdillon 10y ago
  The notion that traversing a binary tree requires expertise in algorithms seems questionable to me. I view basic tree traversal as table stakes for a developer with more than a year or two of experience (IIRC, it's discussed in Intro to Algorithms in most CS curricula). OP says that his field is object-oriented design, which links to a page where he announces that "We've started work on a new programming language". The idea that a computer scientist/software engineer would embark on building a new programming language but also state that they don't know how to solve tree traversal problems and "will never be interested in learning them" seems strangely incongruous, given that building a language almost certainly involves working with ASTs. Specifically, OP pushed a commit in late 2016 that contains code working with stacks, linked lists, and an AST class for the EO language. https://github.com/yegor256/eo/commit/6df2281d8b0163b9f9e1b85b21be6f2cc1c1a128 https://github.com/yegor256/eo/commit/6df2281d8b0163b9f9e1b8... I guess I just don't believe that interview questions about trees are ignoring the author's background and field.
  - deleted 10y ago
    [deleted]
  - lostcolony 10y ago
    But optimizing for them? I've been out of school over 7 years; I'm currently a tech lead. I can guarantee you that, while I can likely solve most binary tree related questions you'd care to throw at me, it will take a lot more work, thought, and likely mistakes on my part now than it would have when I first got out of school. It's not an area I've spent -any- part of my development career on, nor is it an area I find particularly interesting. Whereas when I left school, I had actively been dealing with such problems within the past couple years, -and- had boned up on them specifically to prep for interviews, since I had nothing else in my favor. Hiring a junior with such criteria might make sense; hiring a more seasoned person, probably not so much. Because the seasoned person will just not be as compelling as the more junior person, due to having spent the past few years working on other things.
iainmerrick 10y ago
I'd be interested in hearing from people who work at Google, and get to figure out a cool algorithm for solving an interesting puzzle-problem more an about once a year. I bet there aren't very many. In my experience, the stuff you do in this kind of interview has very little relation with the stuff you do in the actual job. (I wish it did! I love those algorithmic puzzles.)
- tetraodonpuffer 10y ago
  figuring out a cool algorithm is not the same as learning 1000 algorithms by rote to prepare for an interview. Just because doesn't feel like doing test prep for an interview, it doesn't mean they don't have the brain capacity to actually solve the business problem when it comes up. If in my day-to-day I need to use an AVL tree, I will get a library for it, I won't be reimplementing it from scratch every single time.
  - numbsafari 10y ago
    You might not need to implement it, but you needed to know enough to know what an AVL tree is, why you might (or might not) need it, and to be able to do some basic validations on the library you selected to make sure that it does what you are hiring it to do.
    - tetraodonpuffer 10y ago
      agreed, but let's assume you don't know what an AVL tree is or what the trade-offs are between an AVL, red-black or other type of trees: how long does in this age to find that information if you know what you are doing? I mean, you could allow your interviewee access to a computer and based on the type of googling they do it should be fairly obvious if they know what they are talking about. In your day-to-day you have wikipedia, stackoverflow, hn and so on: software development hasn't qualitatively changed in the past decades to require multi-day interviews when 15 years ago a single 30-45 min interview was more than enough. It would actually be interesting to compare the length of, say, a google interview a year after company inception compared to now. I am sure that despite the fact that nowadays the impact of a bad hire would be minuscule compared to back then, the interview process is way, way, way longer and more difficult.
ubernostrum 10y ago
Why do they try to "recruit" him in the first place, then, and "waste" recruiter time and phone-screen time on him and people like him? Remember: this isn't people applying to Google out of the blue: this is people Google has actively courted to apply. I did a couple rounds of their interviews a while back just to see if they really were as bad as people said they were (yup!). And that was in response to a very persistent recruiter emailing me over and over and over again to apply, despite my knowing there was zero chance I'd be a fit for the job they asked me to apply to. And more generally: I don't really care about binary trees. They're simply not relevant to the work I do. I suppose if someday the only way I can get a job is to buy a book with all the stock interview questions in it and memorize the answers, then that's what I'll do. But if somebody's hiring me, I want them to hire me for the things I know that aren't standard interview questions anyone can memorize. The way I try to phrase this to people who don't get it is: my metaphorical working set in memory does not include basic algorithms (that's what libraries are for), and does not include brainteasers or riddles. It does include a lot of arcana about how web application stacks work, the network and gateway protocols they use, the points where security and reliability issues are most likely to happen and how to avoid those issues, the application and database architecture patterns most often needed, available libraries and frameworks which implement them, pros and cons of different approaches, etc., etc. I could, if so inclined, probably take the metaphor all the way and outline which things are in the equivalent of CPU cache vs. the equivalent of main memory. So sure, I could page all that out to disk and forcibly cram a binary-tree answer into my brain's L1 or L2 cache, or load up one of the dynamic-programming questions Google loves (tip if you want to work for Google: memorize the Wikipedia article on longest common subsequence, even if it will never ever be relevant to anything you'll ever do, because they will have you do it in an interview). But that would be actively harming my own usefulness, and I'm not willing to do that for Google or for anyone else. Which I guess raises the question: why do you apparently want me to harm my own usefulness just to try to get a status-symbol passing grade on a Google interview?
- stuckagain 10y ago
  Here's the thing, nothing personal about you but a true fact about Google. Nobody at Google could possibly care less about your opinions on "application and database architecture" because Google does not have application and database architecture that even slightly resembles anything you have ever seen outside of the company. In fact the less you think you know about architecture the better it would be for all involved, if you were to go work at Google. Also all those things you know about makefiles and maven and ant and ansible and chef? Nobody cares. Google doesn't use those tools. Google has lots of famous engineers and while I believe their expertise and knowledge are valued, their outside experiences are generally not.
vinhboy 10y ago
If you read and understood the article, this comment is really disingenuous. It does not in any way reflect the sentiment of the writer.
mbrumlow 10y ago
Maybe, or maybe they are missing out. Binary-tree traversing is a rote memory sort of thing. Somebody who can come in and play 20 questions about an algorithm and answer them perfectly shows me nothing other than they studied that algorithm and have a good memory. It does not show me any insight into how they solve problems which have not already been solved for them. It won't show me how they do under stress with a completely open ended question. I don't work at google so I won't speak to their daily work, but very rarely should you be writing your own binary tree or traversal code. If you should find yourself on that task you hopefully won't be doing it from memory / without reference because unless that is the ONE thing you know like the back of your hand, even then you are likely going to make mistakes. I also feel that anybody who has actually been productive on a large successful project does not have time to commit to learning things that can be looked up when needed. There has only been a few times that I have actually needed to implement any of these algorithms in the last 10 years. Of those they were very low level and implemented in a kernel driver where libraries are not so abundant. Can I remember all the fine details today? No. Did I make a system that runs on hundreds of thousands of linux systems across the world? Yes. If I were interviewed on the fine details of implementing some of these algorithms and data structures would I pass? Not likely. Does this make me a bad programmer? Depends who you ask. If you ask the guy interviewing me Yes. If you ask my boss and the many customers who use my product No. Memorizing algorithms does not make you a good programmer. Knowing how to apply and when to apply them does. The hard part was done when the algorithm was created, not regurgitating an implementation. Now you might say hey, they should at least know binary tree! Sure maybe they should have some knowledge of it, but there will always be some algorithm you don't know. I would feel completely different if Google said "Come ready to talk about these 5 algorithms and maybe implement one or two". That falls inline fairly well with the author of the article. At least then somebody can say, "Hey, I don't have time", or "Sorry, not interested". And both sides can have their expectations insync. Now don't get me wrong. We are talking about Google and Amazon. So yeah, somebody there might need to know something about these algorithms. But I doubt they all do. The Few interviews I have been on at these organizations I was not even convinced that all the people interviewing me would be able to pass the round of 5 had they interviewed each other. I should note not all the people who interviewed me gave me that impression. I did meet some really nice people that I thought I would enjoy working with. I also don't think that these companies don't take into account that some people just interview badly. There is a lot of stress involved. While I think people should be able to work unders stress, I think the type of stress these interviews cause is something entirely different. I live a fairly stress free and carefree life. But when I went to interview at Google my stress levels were so high that I felt sick and worn out for days after. What I am getting at is I am presented with hard problems and short deadlines daily at work. Not once did any of those challenges cause me any level of stress. On the other hand trying to figure out what the interviewer really was asking and cramming to memorize algorithms caused so much stress I did not sleep for days days before the interview. It's not that I was up studying, its that my mind was racing and I could not sleep if I wanted. I just lied there in bed staring at the ceiling. I think they call that anxiety. > Interview process: complete success. It was a failure because they wasted everybody's time. Had they been more upfront on what they were looking for then he could have declined without costing both the company money, and him time and stress.
minipci1321 10y ago
Also, seems to be some personality problems (although I of course don't know the guy). No need to go as far as binary trees.

> There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be interested in learning them. Interview process: complete success.

untog 10y ago

Depends what the job description is, surely. And if the developer isn't interested in working on these things, surely it's failure on Google's part to effectively target who they are approaching?

johannes1234321 10y ago
The job description is "Software Engineer at Google" They hire some special roles from time to time, but then they approach people differently (i.e. on a personal level) otherwise they hire people they ideally can move easily from project to project.

johannes1234321 10y ago

For a complete success they would have a way to filter out people without algorithm knowledge early on. A day of interviews already costs them some money, especially on the scale they are doing this.

stuckagain 10y ago
Yeah maybe you are right on that point. At Google at least the filtering by stage seems to be: Recruiter phone interview: do you speak English? Technical phone interview: have you ever programmed a computer before? Technical on-site interview: do you know a few things about data structures and algorithms?
- iainmerrick 10y ago
  What's funny is that Google seems to think they're really good at interviewing -- for example, see this Washington Post puff piece: https://www.washingtonpost.com/business/capitalbusiness/an-inside-look-at-googles-data-driven-job-interview-process/2013/09/03/648ea8b2-14bd-11e3-880b-7503237cc69d_story.html https://www.washingtonpost.com/business/capitalbusiness/an-i... Possibly they are, but it's hard to see solid evidence one way or the other. I guess they can't be really bad in the sense of hiring mostly bad candidates, as that would surely cause big problems before long. But they could be about the same as other big bay area companies.

fernandopj 10y ago

> If she would have started her email with "We're looking for an algorithm expert," we would never have gotten any further and would not have wasted our time. Clearly, I'm not an expert in algorithms. This phrase precedes the one you mentioned. He's saying the process he has been through completely ignored his background and field.

rpdillon 10y ago
The notion that traversing a binary tree requires expertise in algorithms seems questionable to me. I view basic tree traversal as table stakes for a developer with more than a year or two of experience (IIRC, it's discussed in Intro to Algorithms in most CS curricula). OP says that his field is object-oriented design, which links to a page where he announces that "We've started work on a new programming language". The idea that a computer scientist/software engineer would embark on building a new programming language but also state that they don't know how to solve tree traversal problems and "will never be interested in learning them" seems strangely incongruous, given that building a language almost certainly involves working with ASTs. Specifically, OP pushed a commit in late 2016 that contains code working with stacks, linked lists, and an AST class for the EO language. https://github.com/yegor256/eo/commit/6df2281d8b0163b9f9e1b85b21be6f2cc1c1a128 https://github.com/yegor256/eo/commit/6df2281d8b0163b9f9e1b8... I guess I just don't believe that interview questions about trees are ignoring the author's background and field.
- deleted 10y ago
  [deleted]
- lostcolony 10y ago
  But optimizing for them? I've been out of school over 7 years; I'm currently a tech lead. I can guarantee you that, while I can likely solve most binary tree related questions you'd care to throw at me, it will take a lot more work, thought, and likely mistakes on my part now than it would have when I first got out of school. It's not an area I've spent -any- part of my development career on, nor is it an area I find particularly interesting. Whereas when I left school, I had actively been dealing with such problems within the past couple years, -and- had boned up on them specifically to prep for interviews, since I had nothing else in my favor. Hiring a junior with such criteria might make sense; hiring a more seasoned person, probably not so much. Because the seasoned person will just not be as compelling as the more junior person, due to having spent the past few years working on other things.

iainmerrick 10y ago

I'd be interested in hearing from people who work at Google, and get to figure out a cool algorithm for solving an interesting puzzle-problem more an about once a year. I bet there aren't very many. In my experience, the stuff you do in this kind of interview has very little relation with the stuff you do in the actual job. (I wish it did! I love those algorithmic puzzles.)

tetraodonpuffer 10y ago
figuring out a cool algorithm is not the same as learning 1000 algorithms by rote to prepare for an interview. Just because doesn't feel like doing test prep for an interview, it doesn't mean they don't have the brain capacity to actually solve the business problem when it comes up. If in my day-to-day I need to use an AVL tree, I will get a library for it, I won't be reimplementing it from scratch every single time.
- numbsafari 10y ago
  You might not need to implement it, but you needed to know enough to know what an AVL tree is, why you might (or might not) need it, and to be able to do some basic validations on the library you selected to make sure that it does what you are hiring it to do.
  - tetraodonpuffer 10y ago
    agreed, but let's assume you don't know what an AVL tree is or what the trade-offs are between an AVL, red-black or other type of trees: how long does in this age to find that information if you know what you are doing? I mean, you could allow your interviewee access to a computer and based on the type of googling they do it should be fairly obvious if they know what they are talking about. In your day-to-day you have wikipedia, stackoverflow, hn and so on: software development hasn't qualitatively changed in the past decades to require multi-day interviews when 15 years ago a single 30-45 min interview was more than enough. It would actually be interesting to compare the length of, say, a google interview a year after company inception compared to now. I am sure that despite the fact that nowadays the impact of a bad hire would be minuscule compared to back then, the interview process is way, way, way longer and more difficult.

ubernostrum 10y ago

Why do they try to "recruit" him in the first place, then, and "waste" recruiter time and phone-screen time on him and people like him? Remember: this isn't people applying to Google out of the blue: this is people Google has actively courted to apply. I did a couple rounds of their interviews a while back just to see if they really were as bad as people said they were (yup!). And that was in response to a very persistent recruiter emailing me over and over and over again to apply, despite my knowing there was zero chance I'd be a fit for the job they asked me to apply to. And more generally: I don't really care about binary trees. They're simply not relevant to the work I do. I suppose if someday the only way I can get a job is to buy a book with all the stock interview questions in it and memorize the answers, then that's what I'll do. But if somebody's hiring me, I want them to hire me for the things I know that aren't standard interview questions anyone can memorize. The way I try to phrase this to people who don't get it is: my metaphorical working set in memory does not include basic algorithms (that's what libraries are for), and does not include brainteasers or riddles. It does include a lot of arcana about how web application stacks work, the network and gateway protocols they use, the points where security and reliability issues are most likely to happen and how to avoid those issues, the application and database architecture patterns most often needed, available libraries and frameworks which implement them, pros and cons of different approaches, etc., etc. I could, if so inclined, probably take the metaphor all the way and outline which things are in the equivalent of CPU cache vs. the equivalent of main memory. So sure, I could page all that out to disk and forcibly cram a binary-tree answer into my brain's L1 or L2 cache, or load up one of the dynamic-programming questions Google loves (tip if you want to work for Google: memorize the Wikipedia article on longest common subsequence, even if it will never ever be relevant to anything you'll ever do, because they will have you do it in an interview). But that would be actively harming my own usefulness, and I'm not willing to do that for Google or for anyone else. Which I guess raises the question: why do you apparently want me to harm my own usefulness just to try to get a status-symbol passing grade on a Google interview?

stuckagain 10y ago
Here's the thing, nothing personal about you but a true fact about Google. Nobody at Google could possibly care less about your opinions on "application and database architecture" because Google does not have application and database architecture that even slightly resembles anything you have ever seen outside of the company. In fact the less you think you know about architecture the better it would be for all involved, if you were to go work at Google. Also all those things you know about makefiles and maven and ant and ansible and chef? Nobody cares. Google doesn't use those tools. Google has lots of famous engineers and while I believe their expertise and knowledge are valued, their outside experiences are generally not.

vinhboy 10y ago

If you read and understood the article, this comment is really disingenuous. It does not in any way reflect the sentiment of the writer.

mbrumlow 10y ago

Maybe, or maybe they are missing out. Binary-tree traversing is a rote memory sort of thing. Somebody who can come in and play 20 questions about an algorithm and answer them perfectly shows me nothing other than they studied that algorithm and have a good memory. It does not show me any insight into how they solve problems which have not already been solved for them. It won't show me how they do under stress with a completely open ended question. I don't work at google so I won't speak to their daily work, but very rarely should you be writing your own binary tree or traversal code. If you should find yourself on that task you hopefully won't be doing it from memory / without reference because unless that is the ONE thing you know like the back of your hand, even then you are likely going to make mistakes. I also feel that anybody who has actually been productive on a large successful project does not have time to commit to learning things that can be looked up when needed. There has only been a few times that I have actually needed to implement any of these algorithms in the last 10 years. Of those they were very low level and implemented in a kernel driver where libraries are not so abundant. Can I remember all the fine details today? No. Did I make a system that runs on hundreds of thousands of linux systems across the world? Yes. If I were interviewed on the fine details of implementing some of these algorithms and data structures would I pass? Not likely. Does this make me a bad programmer? Depends who you ask. If you ask the guy interviewing me Yes. If you ask my boss and the many customers who use my product No. Memorizing algorithms does not make you a good programmer. Knowing how to apply and when to apply them does. The hard part was done when the algorithm was created, not regurgitating an implementation. Now you might say hey, they should at least know binary tree! Sure maybe they should have some knowledge of it, but there will always be some algorithm you don't know. I would feel completely different if Google said "Come ready to talk about these 5 algorithms and maybe implement one or two". That falls inline fairly well with the author of the article. At least then somebody can say, "Hey, I don't have time", or "Sorry, not interested". And both sides can have their expectations insync. Now don't get me wrong. We are talking about Google and Amazon. So yeah, somebody there might need to know something about these algorithms. But I doubt they all do. The Few interviews I have been on at these organizations I was not even convinced that all the people interviewing me would be able to pass the round of 5 had they interviewed each other. I should note not all the people who interviewed me gave me that impression. I did meet some really nice people that I thought I would enjoy working with. I also don't think that these companies don't take into account that some people just interview badly. There is a lot of stress involved. While I think people should be able to work unders stress, I think the type of stress these interviews cause is something entirely different. I live a fairly stress free and carefree life. But when I went to interview at Google my stress levels were so high that I felt sick and worn out for days after. What I am getting at is I am presented with hard problems and short deadlines daily at work. Not once did any of those challenges cause me any level of stress. On the other hand trying to figure out what the interviewer really was asking and cramming to memorize algorithms caused so much stress I did not sleep for days days before the interview. It's not that I was up studying, its that my mind was racing and I could not sleep if I wanted. I just lied there in bed staring at the ceiling. I think they call that anxiety. > Interview process: complete success. It was a failure because they wasted everybody's time. Had they been more upfront on what they were looking for then he could have declined without costing both the company money, and him time and stress.

minipci1321 10y ago

Also, seems to be some personality problems (although I of course don't know the guy). No need to go as far as binary trees.