6 ms·

> Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off. — Max Howell (@mxcl) If i

> Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off. — Max Howell (@mxcl) If inverting a binary tree means swapping the left and right subtrees of every node, I wouldn't want to work with someone who can't do that either and Google is definitely right to reject him.

regularjack 4y ago
Not knowing how to do something from the top of your head is not the same thing as not being able to do it.
- deathanatos 4y ago
  … but that's an interview. If you cannot, within the time, demonstrate any ability, why should you be hired? The question above, as clarified, is not complicated, nor does it rely on memorization or some "trick": anyone purporting to be a SWE should be able to write an essentially de novo solution to it. (And in my own technical interviews, there are multiple questions, to specifically hedge against any one being "that one question a good candidate is going to miss because it's just not their day". It doesn't happen: it's either all or nothing.)
  - jmd42 4y ago
    I'm on the same page. Sure, your day-to-day work may not involve manipulating binary trees. But presumably it does involve working with variables, objects, references, manipulating data of some kind... And if you're comfortable with the fundamentals of those, then this is something you should be able to figure out even if you've never heard of a "binary tree" before, once somebody has sketched it or shown you the definition of their TreeNode class, right? It honestly baffles me how people consider this something which needs to be drilled or memorized. There are absolutely algorithmic questions which would fall into that category. But if somebody considers this to be one of them - or something like "find the smallest number in an array" - then I have to question whether they have an understanding of the most fundamental concepts in programming... Or if they get through each day solely using things they've memorized by rote, or looked up, and they don't really have any idea how any of the foundations they're building on actually operate.
  - bobleeswagger 4y ago
    > If you cannot, within the time, demonstrate any ability, why should you be hired? It is more likely that the interview process is broken and missing the right candidates, than it is that the interviewees are all mediocre. Most interviews are very non-inclusive the same way that the main track of school is becoming less and less inclusive. Different people need different methods to bring out the best in them.
    - hn_throwaway_99 4y ago
      > It is more likely that the interview process is broken and missing the right candidates, than it is that the interviewees are all mediocre. Here's a thought experiment for you: if the interview process is so broken, why hasn't some tech company succeeded and become famous for an improved interview process, e.g. "Moneyball style"? My guess is because the process is not actually that broken, at least from the employer's perspective. I'm sure the interview process could be changed to be less regimented and more "inclusive", but that's also likely to reduce it's predictive power (i.e. you're more likely to make bad hires, and from a company's perspective that's almost always worse than missing out on a great hire).
      - bobleeswagger 4y ago
        > if the interview process is so broken Hiring is guessing. Firing is knowing. If the hiring process worked, we wouldn't have layoffs like we do.
        deathanatos 4y ago
        The layoffs that I have seen reported have been reported as being random. I've been involved now in 3 layoffs directly in my career, and 100% of them, the laid off individuals were laid off without regards to skill. The reporting in the media on layoffs happening elsewhere largely matches my experience. Sure, an argument exists around "you shouldn't've hired that many people", but that is different from an argument of "the hiring process can't discern good hires". The former is a management & long-term planning issue, the latter is how interviews are conducted.
- sophonX 4y ago
  So hire a baby ? That'll eventually do in 20 years ..... works, right ?
- deleted 4y ago
  [deleted]
sophonX 4y ago
Yeah it's such a basic structure we use in-directly - in classes & sub-classes, intellij dependency list on left side, using google maps, etc. How complex is homebrew ? Can no one else replicate it ? Why should a company hire for something you did that's simple ? What are the skills he posses that no one else has ? Learn your basica dsa stuff for gods sake people.
- onion2k 4y ago
  Judging by Google's track record, hiring some people who have demonstrated an ability to launch and maintain a piece of software would bring a skillset they desparately need. Google engineers are incapable of keeping much going for the long term.
  - sophonX 4y ago
    That's a problem in every company ? How do you know they don't need smart people ? Do you've any public stats or reasonable justification ?
  - Jensson 4y ago
    It is managers who decides what project dies or lives, not engineers.
dekhn 4y ago
Wouldn't that be a "mirror" operation, while inversion would be (I dunno) swapping the direction of the edges? I went out of my way to avoid homebrew (still do) when I worked at google because it would reliably fail to complete some key operations in a dag, hence the interest in ensuring developers know how to do CS things.
- sophonX 4y ago
  There you go ! This comment should be highlighted.
  - devnullbrain 4y ago
    It doesn't matter, the candidate should ask for clarification if the question is ambiguous.
    - sophonX 4y ago
      I was referring to second para or statement. (-_-)
- howling 4y ago
  Yeah it's not clear what he was asked. Swapping the direction of every edge of a binary tree would result in a DAG that is likely no longer a binary tree though.
  - gifnamething 4y ago
    Are you confusing a binary tree with something else? Here's an example: https://leetcode.com/problems/invert-binary-tree/ https://leetcode.com/problems/invert-binary-tree/ It's an 'easy' question. The solution is <10 lines.
    - zeroonetwothree 4y ago
      Yeah it's really easy. I wrote a correct solution in about 30 seconds on my first try. And I haven't actually practiced these problems for 10+ years.
ronia 4y ago
The actual work for which you are hiring an engineer is building a software product/service, and the Homebrew developer has a track record of delivering great results. Rejecting the guy because he cannot do a whiteboard brain teaser is like rejecting LeBron James because he did not make a shot at the arcade basketball game. I'm not saying the guy would be perfect. Comparing him to LeBron James might not be a great example. Google might have other reasons to reject him. What I'm trying to say is the current coding interview is a really poor mechanism to gauge a software engineer, especially when it comes to hiring one with real-world engineering experience.
- hn_throwaway_99 4y ago
  > What I'm trying to say is the current coding interview is a really poor mechanism to gauge a software engineer. People like to say this, but in my experience this is not true. It's just that people misunderstand the goal of technical interviews and they often are poor at evaluating their own skills. First off, these giant tech companies have enormous economic incentives to improve their interview processes as much as possible. They also do a pretty rigorous assessment of the effectiveness of their interview process (Google, for example, has publicized some of their data). I'm not saying these tech companies interview processes are perfect, but I also have a problem believing they're so fundamentally flawed that these companies can't figure out how to fix them given the giant economic returns they get for optimizing their hiring processes. Moreover, as some other comments mentioned, many companies (and individuals, myself included) believe it is much worse to hire someone who ends up not cutting it, than missing out on a potentially good hire. I can list out all the reasons why, but Joel Spoelsky has a pretty famous essay from a couple decades ago on the topic that explains it well [1]. Thus, it's not surprising hearing a lot people complain that they can do the job, but they aren't good at interviews. Because, from Google's/Microsoft's/etc. perspective, they're fine with a bit higher false negative rate if they can greatly reduce their false positive rate. And my experience matches that: I have never seen a candidate who did awesome in "whiteboard-style programming questions" who couldn't cut it programming-wise (they may have had other issues, but "coding productivity" wasn't one of them). Now, I certainly believe and have seen that there are some people who aren't good at these questions who can do a job well, but there are also a ton more people who can't do the job if they can't pass a technical screen, so hiring any of these folks means much more risk. I also think that whiteboard-style coding questions help show a quality that is very important to businesses, even if those questions don't represent "real world" work. There are basically 2 types of people that do well at these questions: people who are just naturally smart and have a ton of experience to the point that they wouldn't even need to study to do well, and people who are of more "normal" intelligence/ability, but who can do well if they study a ton. Either of those two groups would likely do well in a programming role. So often I hear the complaint "I'm a busy person, I've got outside responsibilities, you can't expect me to spend all this time studying". And that may be true, but you'll be competing against people who are willing to study, so I don't think you can fault Google et al for favoring people who show a willingness to do more preparation. 1. https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/ https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid... "And in the middle, you have a large number of “maybes” who seem like they might just be able to contribute something. The trick is telling the difference between the superstars and the maybes, because the secret is that you don’t want to hire any of the maybes. Ever."
GeneralMayhem 4y ago
Also, I don't believe that 90% of Google engineers use Homebrew. I'm not sure I'd believe 9%. Google is a Linux shop with its own internal package repo. Even if you're using a Macbook to work remotely, you're using it as a fancy terminal wrapper to connect to a Debian-based system to do your real work.
photonbeam 4y ago
Most of us havent touched a tree structure since college, because there are other, real, problems out there. Trying to remember, or rederive it from scratch is slower and error-prone and bad for interviews
- devnullbrain 4y ago
  Then most of us aren't suitable for jobs where this stuff is important. Google does have 'real' problems involving trees.
- sophonX 4y ago
  You are just ignorant and naive. Tree structure ? json, xml, protobuf, classes, functional programming, databases with foreign key, database internals, etc ? Oh I forgot you also serialize and deserialize data - did you forget how that works ? Tree traversal again. Do you know how organizationl hierarchy is structure ? It's a tree. Do you know various maps and their usages ? We use them daily - it's very very important to know their internals. Hashing vs Trees vs Linked hash vs etc. Google maps ? n-d trees ? Comparing data - merkel trees ? etc. Every dev out there has common work with mine. But you won't be able to solve the problems that I face on a daily basis without thinking hard & without this dsa + concurrency knowledge. Now, is it reasonable to ask these questions ? Heck yes.
- yks 4y ago
  JSON is also a tree structure. Granted one rarely inverts it, but “no trees in the real world” is not true.
lubujackson 4y ago
That is a fine and common opinion, but just one question: how often have you inverted a binary tree at your job? Because after nearly 20 years it hasn't come up once for me. I am sure for some roles it is a necessary skill but my issue is that most of these questions are more or less toy problems that come from academia and not business. They are a great test of your retention of a data structure class but not super relevant beyond that. I would rather hire an engineer with a strong business or user sense - reading between the lines of requests and anticipating future issues or uses adds so much more value in a real sense. To me, these are great entry level questions because it is a good baseline for new grads when you have little work experience to judge. Past that, it is like making a lawyer take a mini bar exam for every new job - a waste of effort if you want to hire for specific skills and experience.
- sophonX 4y ago
  Just because you haven't worked in a team that requires those skills doesn't mean they aren't valuable. In my old team, I had to come up with a coupon distribution logic based on count, percentage, time, then generating reproducable random values that required to deep dive (algorithm) into library code & explicitly storing state in redis, then an application of dynamic programming in building as custom platform, atomic token validation, custom rate limiter algo, state machine, scheduler, distributed circuit breaker, etc. In my current team, I had to read raft paper, zab paper, look into their implementation, make a poc with raft protocol, then autoscaling algorithms, scheduler algo's, different data structures, heck even the oss engine itself is DAG, heavy threads + concurrency stuff. Even now I come across new data structures and algorithms. Clearly you don't know the entire industry, just because you haven't worked in such teams, doesn't mean these aren't important. You are experienced in a bubble. The hiring bar for our team is higher than other teams and heck even for SDE3 - the requirement is higher. You would be very much surprised to know that even the senior members have research publications and deal with complex stuff. Core teams like in AWS or GCP or Azure solve these sort of problems. Who do you think will solve autoscaling (that's what I'm doing now) or managed scaling or network or security or any infra problems in these cloud platforms ? As experience increases, we expect more knowledge & insights - doesn't mean to ignore basic coding stuff like arrays or linked lists or trees or graphs or simple message queues or etc. If companies are paying competitive TC and there are multiple candidates, why not hire a smart person ? What's so special about doing regular normal stuff ? That's just a normal dev right ?

regularjack 4y ago

Not knowing how to do something from the top of your head is not the same thing as not being able to do it.

deathanatos 4y ago
… but that's an interview. If you cannot, within the time, demonstrate any ability, why should you be hired? The question above, as clarified, is not complicated, nor does it rely on memorization or some "trick": anyone purporting to be a SWE should be able to write an essentially de novo solution to it. (And in my own technical interviews, there are multiple questions, to specifically hedge against any one being "that one question a good candidate is going to miss because it's just not their day". It doesn't happen: it's either all or nothing.)
- jmd42 4y ago
  I'm on the same page. Sure, your day-to-day work may not involve manipulating binary trees. But presumably it does involve working with variables, objects, references, manipulating data of some kind... And if you're comfortable with the fundamentals of those, then this is something you should be able to figure out even if you've never heard of a "binary tree" before, once somebody has sketched it or shown you the definition of their TreeNode class, right? It honestly baffles me how people consider this something which needs to be drilled or memorized. There are absolutely algorithmic questions which would fall into that category. But if somebody considers this to be one of them - or something like "find the smallest number in an array" - then I have to question whether they have an understanding of the most fundamental concepts in programming... Or if they get through each day solely using things they've memorized by rote, or looked up, and they don't really have any idea how any of the foundations they're building on actually operate.
- bobleeswagger 4y ago
  > If you cannot, within the time, demonstrate any ability, why should you be hired? It is more likely that the interview process is broken and missing the right candidates, than it is that the interviewees are all mediocre. Most interviews are very non-inclusive the same way that the main track of school is becoming less and less inclusive. Different people need different methods to bring out the best in them.
  - hn_throwaway_99 4y ago
    > It is more likely that the interview process is broken and missing the right candidates, than it is that the interviewees are all mediocre. Here's a thought experiment for you: if the interview process is so broken, why hasn't some tech company succeeded and become famous for an improved interview process, e.g. "Moneyball style"? My guess is because the process is not actually that broken, at least from the employer's perspective. I'm sure the interview process could be changed to be less regimented and more "inclusive", but that's also likely to reduce it's predictive power (i.e. you're more likely to make bad hires, and from a company's perspective that's almost always worse than missing out on a great hire).
    - bobleeswagger 4y ago
      > if the interview process is so broken Hiring is guessing. Firing is knowing. If the hiring process worked, we wouldn't have layoffs like we do.
      - deathanatos 4y ago
        The layoffs that I have seen reported have been reported as being random. I've been involved now in 3 layoffs directly in my career, and 100% of them, the laid off individuals were laid off without regards to skill. The reporting in the media on layoffs happening elsewhere largely matches my experience. Sure, an argument exists around "you shouldn't've hired that many people", but that is different from an argument of "the hiring process can't discern good hires". The former is a management & long-term planning issue, the latter is how interviews are conducted.
sophonX 4y ago
So hire a baby ? That'll eventually do in 20 years ..... works, right ?
deleted 4y ago
[deleted]

sophonX 4y ago

Yeah it's such a basic structure we use in-directly - in classes & sub-classes, intellij dependency list on left side, using google maps, etc. How complex is homebrew ? Can no one else replicate it ? Why should a company hire for something you did that's simple ? What are the skills he posses that no one else has ? Learn your basica dsa stuff for gods sake people.

onion2k 4y ago
Judging by Google's track record, hiring some people who have demonstrated an ability to launch and maintain a piece of software would bring a skillset they desparately need. Google engineers are incapable of keeping much going for the long term.
- sophonX 4y ago
  That's a problem in every company ? How do you know they don't need smart people ? Do you've any public stats or reasonable justification ?
- Jensson 4y ago
  It is managers who decides what project dies or lives, not engineers.

dekhn 4y ago

Wouldn't that be a "mirror" operation, while inversion would be (I dunno) swapping the direction of the edges? I went out of my way to avoid homebrew (still do) when I worked at google because it would reliably fail to complete some key operations in a dag, hence the interest in ensuring developers know how to do CS things.

sophonX 4y ago
There you go ! This comment should be highlighted.
- devnullbrain 4y ago
  It doesn't matter, the candidate should ask for clarification if the question is ambiguous.
  - sophonX 4y ago
    I was referring to second para or statement. (-_-)
howling 4y ago
Yeah it's not clear what he was asked. Swapping the direction of every edge of a binary tree would result in a DAG that is likely no longer a binary tree though.
- gifnamething 4y ago
  Are you confusing a binary tree with something else? Here's an example: https://leetcode.com/problems/invert-binary-tree/ https://leetcode.com/problems/invert-binary-tree/ It's an 'easy' question. The solution is <10 lines.
  - zeroonetwothree 4y ago
    Yeah it's really easy. I wrote a correct solution in about 30 seconds on my first try. And I haven't actually practiced these problems for 10+ years.

ronia 4y ago

The actual work for which you are hiring an engineer is building a software product/service, and the Homebrew developer has a track record of delivering great results. Rejecting the guy because he cannot do a whiteboard brain teaser is like rejecting LeBron James because he did not make a shot at the arcade basketball game. I'm not saying the guy would be perfect. Comparing him to LeBron James might not be a great example. Google might have other reasons to reject him. What I'm trying to say is the current coding interview is a really poor mechanism to gauge a software engineer, especially when it comes to hiring one with real-world engineering experience.

hn_throwaway_99 4y ago
> What I'm trying to say is the current coding interview is a really poor mechanism to gauge a software engineer. People like to say this, but in my experience this is not true. It's just that people misunderstand the goal of technical interviews and they often are poor at evaluating their own skills. First off, these giant tech companies have enormous economic incentives to improve their interview processes as much as possible. They also do a pretty rigorous assessment of the effectiveness of their interview process (Google, for example, has publicized some of their data). I'm not saying these tech companies interview processes are perfect, but I also have a problem believing they're so fundamentally flawed that these companies can't figure out how to fix them given the giant economic returns they get for optimizing their hiring processes. Moreover, as some other comments mentioned, many companies (and individuals, myself included) believe it is much worse to hire someone who ends up not cutting it, than missing out on a potentially good hire. I can list out all the reasons why, but Joel Spoelsky has a pretty famous essay from a couple decades ago on the topic that explains it well [1]. Thus, it's not surprising hearing a lot people complain that they can do the job, but they aren't good at interviews. Because, from Google's/Microsoft's/etc. perspective, they're fine with a bit higher false negative rate if they can greatly reduce their false positive rate. And my experience matches that: I have never seen a candidate who did awesome in "whiteboard-style programming questions" who couldn't cut it programming-wise (they may have had other issues, but "coding productivity" wasn't one of them). Now, I certainly believe and have seen that there are some people who aren't good at these questions who can do a job well, but there are also a ton more people who can't do the job if they can't pass a technical screen, so hiring any of these folks means much more risk. I also think that whiteboard-style coding questions help show a quality that is very important to businesses, even if those questions don't represent "real world" work. There are basically 2 types of people that do well at these questions: people who are just naturally smart and have a ton of experience to the point that they wouldn't even need to study to do well, and people who are of more "normal" intelligence/ability, but who can do well if they study a ton. Either of those two groups would likely do well in a programming role. So often I hear the complaint "I'm a busy person, I've got outside responsibilities, you can't expect me to spend all this time studying". And that may be true, but you'll be competing against people who are willing to study, so I don't think you can fault Google et al for favoring people who show a willingness to do more preparation. 1. https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/ https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid... "And in the middle, you have a large number of “maybes” who seem like they might just be able to contribute something. The trick is telling the difference between the superstars and the maybes, because the secret is that you don’t want to hire any of the maybes. Ever."

GeneralMayhem 4y ago

Also, I don't believe that 90% of Google engineers use Homebrew. I'm not sure I'd believe 9%. Google is a Linux shop with its own internal package repo. Even if you're using a Macbook to work remotely, you're using it as a fancy terminal wrapper to connect to a Debian-based system to do your real work.

photonbeam 4y ago

Most of us havent touched a tree structure since college, because there are other, real, problems out there. Trying to remember, or rederive it from scratch is slower and error-prone and bad for interviews

devnullbrain 4y ago
Then most of us aren't suitable for jobs where this stuff is important. Google does have 'real' problems involving trees.
sophonX 4y ago
You are just ignorant and naive. Tree structure ? json, xml, protobuf, classes, functional programming, databases with foreign key, database internals, etc ? Oh I forgot you also serialize and deserialize data - did you forget how that works ? Tree traversal again. Do you know how organizationl hierarchy is structure ? It's a tree. Do you know various maps and their usages ? We use them daily - it's very very important to know their internals. Hashing vs Trees vs Linked hash vs etc. Google maps ? n-d trees ? Comparing data - merkel trees ? etc. Every dev out there has common work with mine. But you won't be able to solve the problems that I face on a daily basis without thinking hard & without this dsa + concurrency knowledge. Now, is it reasonable to ask these questions ? Heck yes.
yks 4y ago
JSON is also a tree structure. Granted one rarely inverts it, but “no trees in the real world” is not true.

lubujackson 4y ago

That is a fine and common opinion, but just one question: how often have you inverted a binary tree at your job? Because after nearly 20 years it hasn't come up once for me. I am sure for some roles it is a necessary skill but my issue is that most of these questions are more or less toy problems that come from academia and not business. They are a great test of your retention of a data structure class but not super relevant beyond that. I would rather hire an engineer with a strong business or user sense - reading between the lines of requests and anticipating future issues or uses adds so much more value in a real sense. To me, these are great entry level questions because it is a good baseline for new grads when you have little work experience to judge. Past that, it is like making a lawyer take a mini bar exam for every new job - a waste of effort if you want to hire for specific skills and experience.

sophonX 4y ago
Just because you haven't worked in a team that requires those skills doesn't mean they aren't valuable. In my old team, I had to come up with a coupon distribution logic based on count, percentage, time, then generating reproducable random values that required to deep dive (algorithm) into library code & explicitly storing state in redis, then an application of dynamic programming in building as custom platform, atomic token validation, custom rate limiter algo, state machine, scheduler, distributed circuit breaker, etc. In my current team, I had to read raft paper, zab paper, look into their implementation, make a poc with raft protocol, then autoscaling algorithms, scheduler algo's, different data structures, heck even the oss engine itself is DAG, heavy threads + concurrency stuff. Even now I come across new data structures and algorithms. Clearly you don't know the entire industry, just because you haven't worked in such teams, doesn't mean these aren't important. You are experienced in a bubble. The hiring bar for our team is higher than other teams and heck even for SDE3 - the requirement is higher. You would be very much surprised to know that even the senior members have research publications and deal with complex stuff. Core teams like in AWS or GCP or Azure solve these sort of problems. Who do you think will solve autoscaling (that's what I'm doing now) or managed scaling or network or security or any infra problems in these cloud platforms ? As experience increases, we expect more knowledge & insights - doesn't mean to ignore basic coding stuff like arrays or linked lists or trees or graphs or simple message queues or etc. If companies are paying competitive TC and there are multiple candidates, why not hire a smart person ? What's so special about doing regular normal stuff ? That's just a normal dev right ?