6 ms·

> “In some circles, this will get you immediately hired.” Is this true though? I mean Google famously didn’t give a shit about hiring Max Howell (creator of ho

by mlthoughts2018 8y ago

> “In some circles, this will get you immediately hired.” Is this true though? I mean Google famously didn’t give a shit about hiring Max Howell (creator of homebrew) because of hazing-style pointless whiteboard trivia [0]. I’d guess the number of circles where a thoughtful side project that digs into deep computer science fundamentals as well as difficult implementation specifics would even get you the slightest attention for an interview is close enough to zero as to render it meaningless. If you think about a lot of possible different self-study options, ranging from cramming and shallow memorization of leetcode garbage or Cracking the Coding Interview, all the way to patiently applying craftsmanship and self-learning to a side project that exercises and demonstrates core fundamentals in a pragmatic way, the shallow memorization garbage will earn you money, while the side project will earn you an email with a hyperlink to HackerRank. It is one of the worst aspects of our industry, and a major reason why I would advise younger people to treat the idea that there are direct, stable, good-paying jobs with job security in the tech industry with a lot of skepticism. It’s an industry constantly trying to invent new ways to shift the demographics more and more into the least experienced and least expensive quantiles of candidates, and to arrange businesses where actual software labor productivity doesn’t have a strong tie to the company’s bottom line, except maybe for a tiny population of experts. [0]: < https://www.quora.com/Whats-the-logic-behind-Google-rejecting-Max-Howell-the-author-of-Homebrew-for-not-being-able-to-invert-a-binary-tree https://www.quora.com/Whats-the-logic-behind-Google-rejectin... >

pjmlp 8y ago
In my experience, you are quite right. Most HR departments will only care about latest set of projects and education, barely giving any value to side projects. Yes, there are those that care about side projects, passion and such, but most of them tend to be startups and sometimes not with the desired set of benefits or requiring relocation.
- wglb 8y ago
  To whatever extent you can get hiring decisions moved out of HR, I would recommend doing it.
  - dionian 8y ago
    true. though the problem extends to developers and developer managers as well. I've seen so many colleagues say stuff when discussing a candidate like "Well they just could write <x> algorithm on the board correctly. I found an edge case" or whatever. I've actually not been offered interviews in part because of failed whiteboard coding questions where the developers just weren't impressed. Yet once I land a job I usually tend to be in the top 25%, because most of the requisite skills are not algorithms, which I'm not particularly practiced at ...
- WalterBright 8y ago
  HR people often know little about programming, and will just compare bullet lists of requirements with the resume bullet points. People with unusual skills don't get hired through the HR front door, they come in the side door.
  - giancarlostoro 8y ago
    This is so true. I got my first (and current) programming job cause someone I knew at college recommended me. I didn't talk to HR till after they decided to hire me. So networking is important. Keep in touch with developers you meet at different jobs. You never know when they might land you your next job. It can be easier to skip HR and go straight to the person who will actually be your boss (directly or indirectly) for the hiring process imho. Edit: wrote "talk to me" instead of "hire me"
fjsolwmv 8y ago
Max Howell created a distro, not a compiler, so that's not relevant to parent's comment. Howell said that he couldn't do core computer science things (like compilers, and NOT whiteboard trivia), that he was better at cobbling together scripts that solve user problems well. Maybe Google was wrong to pass him over, but if they were it wasn't because "they didn't care that he could write a compiler". As Howell wrote: "I am often a dick, I am often difficult, I often don’t know computer science, but. BUT. I make really good things, maybe they aren't perfect, but people really like them".
- mlthoughts2018 8y ago
  My feeling is that your reply is excessively focused on the specific example of a compiler from the parent comment. Replies don't need to be specifically focused on compiler projects to be relevant to the general comment about how a side project like a compiler project could get someone hired. My belief, which it seems you do not share, is that a project like homebrew is perfectly analogous to a project like a self-made compiler. They illustrate broader scale systems thinking, although the specific computer science fundamentals will be different for each of those two problems, the a system like homebrew likely also has to have more focus on deployment, user interface, and project management tasks (which, I would argue, makes it more relevant for most hiring situations). I can't comment on whether Howell's self-deprecation was meant to be tongue-in-cheek criticism of Google or if he sincerely meant it, and of course those interpersonal reasons could have been at fault for a failed interview (although it doesn't seem that anyone disputes that it was actually just a straightforward result of some binary tree trivia).
  - chaosite 8y ago
    No, the point is that compilers are a different sort of beast. Writing a C compiler is not like other side-projects. It explicitly exercises a whole bunch of basic Computer Science skills, so if you can write a compiler, you obviously got a good grasp on those. So, no, a project like homebrew is not perfectly analogous to a compiler. The hardest CS problem in there in my opinion is the dependency resolution, which can be a bitch, but it just doesn't have the breadth of problems that a compiler has.
wglb 8y ago
To your first point, the answer is yes, because I hired the kid. And it wasn't for a compiler job. And I would do it again in a heartbeat.
dozzie 8y ago
> I mean Google famously didn’t give a shit about hiring Max Howell (creator of homebrew) because of hazing-style pointless whiteboard trivia [0]. People usually omit the part that Homebrew was at that point a quite shitty reiteration of ideas well-implemented in many other places (RPM/Yum, DEB/APT, and half a dozen other package managers). It was a common complaint that installing one package could break several others, because Homebrew updated some common dependency and the new one was missing symbols or had otherwise incompatible ABI. There also was this hilarious bug report that Homebrew served everything over plain HTTP (and Homebrew had no digital signatures whatsoever), and the ticket got closed by a Homebrew team member saying it's not a problem, which spoke tons about their competency in package management. I don't know how the situation looks now, but when Howell was interviewed by Google, Homebrew was not something you could be proud of writing.
- mlthoughts2018 8y ago
  > "People usually omit the part that Homebrew was at that point a quite shitty reiteration of ideas" I realize we might just disagree in our assessments, but I think this is an unfair characterization. At that point in time, homebrew was basically the only way I could get cross-platform support to work for several image processing projects that my lab was working on. To us, despite its obvious rough-around-the-edges needs for incremental improvement over time, it was a complete lifesaver. I think this speaks to a larger point too about the way that engineers cut down and compete with other engineers in petty ways, instead of acknowledging that getting a complex working system up and running that adds value for people is a huge accomplishment that utterly dwarfs any sort of algorithm trivia in terms of whether a candidate is worth hiring, especially in a company like Google. The perspective that, > "when Howell was interviewed by Google, Homebrew was not something you could be proud of writing." is just so incompatible with my world view about what counts in software engineering that it likely means we are coming from perspectives so far apart that there's little hope we could agree.
  - dozzie 8y ago
    Success of Homebrew was based on marketing, not on the tool being well designed on technical level (because it was not designed well) or its authors' technical competence (because they haven't displayed it much). Google was hiring for a technical position based on technical prowess, not on marketing one (maybe the skills tested were unrelated to the job, but they were still technical), but people pulling out the Google vs. Homebrew case mistake one for the other, which certainly needs correction. > [...] likely [...] we are coming from perspectives so far apart that there's little hope we could agree. You see, I come from Linux administration field. We have package managers deployed in the field for two decades now. These package managers usually don't silently break your library dependencies on update (though Fedora and desktop Ubuntu break them with a lot of noise) and have integrity ensured cryptographically. I take these features almost for granted, as I work with them every day for a long time. Any package manager that provides anything less than that is, in my view, badly designed, especially because there are many examples of how it should be done, it just takes some effort to learn them. On the other hand, you, coming from macOS angle, didn't have a prior experience of working with many package managers -- or at least that's my guess. If I am right, it's quite clear why a poorly designed but popular package manager (i.e. one that has many packages available already) was a huge improvement for you. It was the same for Debian's APT twenty years ago, but APT had pretty much no prior art and the internet was not a viruses/worms/spyware-driven machine it is nowadays.
jacquesm 8y ago
Google apparently is not an element in the set 'some circles'.
- justaaron 8y ago
  saved the best reply for last. full circle. zing!
acqq 8y ago
Google byrocracy required from Ken Thompson to pass a C language exam. https://www.theregister.co.uk/2010/04/21/ken_thompson_take_our_test/ https://www.theregister.co.uk/2010/04/21/ken_thompson_take_o...
- zerr 8y ago
  C exam aside, I don't think he would pass a regular Big G interview, unless he'd allocate some 6 months for preps which I doubt he did.
  - johannes1234321 8y ago
    Considering that he is not one of the young hackers starting with JavaScript, but in a time were looking at raw memory dumps was normal operation and memory was sparsely available and CPUs were slow I assume he well knows about algorithms and data structures by heart. Most likely he implemented more binary trees in his live than I thought about and I assume he would consider a question about inverting a binary tree more of a joke than a serious question.
    - acqq 8y ago
      > I assume he would consider a question about inverting a binary tree more of a joke If you refer to this: https://www.quora.com/When-do-you-need-to-invert-a-binary-tree https://www.quora.com/When-do-you-need-to-invert-a-binary-tr... I also don't know why would anybody ever need to implement "inverting" a binary tree except for the Google exam. > Most likely he implemented more binary trees in his live "Most likely"? Actually he "just" invented (not a complete list): - Unix (with Ritchie) (in assembly first) - the language B, based on which Ritchie developed C. - the notation for the regular expressions everybody uses today - the algorithm for fast regular expression handling - the chess computer that won the 3rd World Computer Chess Championship 1980
      - johannes1234321 8y ago
        > > Most likely he implemented more binary trees in his live > "Most likely"? Actually he "just" invented (not a complete list): Please mind the full quote of me "... than I thought of" -- I thought (and implemented) about trees quite a bit myself and grant him a few factors on top of that.
samatman 8y ago
Attitude is important. If you have a solid codebase that you created, insist on being interviewed about that codebase. That screens out a few employers, but not nearly as many as you think. Most are desperately looking for a way to determine that a candidate is good. Sitting back while they explain in increasing detail how their pet project works is close to ideal here.
userbinator 8y ago
Is this true though? I mean Google famously didn’t give a shit about hiring Max Howell (creator of homebrew) because of hazing-style pointless whiteboard trivia [0]. Creating a package manager, which is mostly "gluing things together without understanding how they work", is a very different skillset than being able to work from first principles. I suspect Google was looking more for the latter. Speaking as someone who has written pieces of compilers, emulators, assemblers, and related software in my spare time, I can say that even mentioning those things casually is enough to get some "you did what?" looks.
- stirner 8y ago
  The one topic from “hard” computer science that applies to package management is graph theory. Inverting a binary tree is one of the simplest operations you can do on a graph. Google may have been interested in Howell because of Homebrew, but not understanding this simple algorithm probably showed them that he didn’t have the skills they originally thought his project exemplified.

pjmlp 8y ago

In my experience, you are quite right. Most HR departments will only care about latest set of projects and education, barely giving any value to side projects. Yes, there are those that care about side projects, passion and such, but most of them tend to be startups and sometimes not with the desired set of benefits or requiring relocation.

wglb 8y ago
To whatever extent you can get hiring decisions moved out of HR, I would recommend doing it.
- dionian 8y ago
  true. though the problem extends to developers and developer managers as well. I've seen so many colleagues say stuff when discussing a candidate like "Well they just could write <x> algorithm on the board correctly. I found an edge case" or whatever. I've actually not been offered interviews in part because of failed whiteboard coding questions where the developers just weren't impressed. Yet once I land a job I usually tend to be in the top 25%, because most of the requisite skills are not algorithms, which I'm not particularly practiced at ...
WalterBright 8y ago
HR people often know little about programming, and will just compare bullet lists of requirements with the resume bullet points. People with unusual skills don't get hired through the HR front door, they come in the side door.
- giancarlostoro 8y ago
  This is so true. I got my first (and current) programming job cause someone I knew at college recommended me. I didn't talk to HR till after they decided to hire me. So networking is important. Keep in touch with developers you meet at different jobs. You never know when they might land you your next job. It can be easier to skip HR and go straight to the person who will actually be your boss (directly or indirectly) for the hiring process imho. Edit: wrote "talk to me" instead of "hire me"

fjsolwmv 8y ago

Max Howell created a distro, not a compiler, so that's not relevant to parent's comment. Howell said that he couldn't do core computer science things (like compilers, and NOT whiteboard trivia), that he was better at cobbling together scripts that solve user problems well. Maybe Google was wrong to pass him over, but if they were it wasn't because "they didn't care that he could write a compiler". As Howell wrote: "I am often a dick, I am often difficult, I often don’t know computer science, but. BUT. I make really good things, maybe they aren't perfect, but people really like them".

mlthoughts2018 8y ago
My feeling is that your reply is excessively focused on the specific example of a compiler from the parent comment. Replies don't need to be specifically focused on compiler projects to be relevant to the general comment about how a side project like a compiler project could get someone hired. My belief, which it seems you do not share, is that a project like homebrew is perfectly analogous to a project like a self-made compiler. They illustrate broader scale systems thinking, although the specific computer science fundamentals will be different for each of those two problems, the a system like homebrew likely also has to have more focus on deployment, user interface, and project management tasks (which, I would argue, makes it more relevant for most hiring situations). I can't comment on whether Howell's self-deprecation was meant to be tongue-in-cheek criticism of Google or if he sincerely meant it, and of course those interpersonal reasons could have been at fault for a failed interview (although it doesn't seem that anyone disputes that it was actually just a straightforward result of some binary tree trivia).
- chaosite 8y ago
  No, the point is that compilers are a different sort of beast. Writing a C compiler is not like other side-projects. It explicitly exercises a whole bunch of basic Computer Science skills, so if you can write a compiler, you obviously got a good grasp on those. So, no, a project like homebrew is not perfectly analogous to a compiler. The hardest CS problem in there in my opinion is the dependency resolution, which can be a bitch, but it just doesn't have the breadth of problems that a compiler has.

wglb 8y ago

To your first point, the answer is yes, because I hired the kid. And it wasn't for a compiler job. And I would do it again in a heartbeat.

dozzie 8y ago

> I mean Google famously didn’t give a shit about hiring Max Howell (creator of homebrew) because of hazing-style pointless whiteboard trivia [0]. People usually omit the part that Homebrew was at that point a quite shitty reiteration of ideas well-implemented in many other places (RPM/Yum, DEB/APT, and half a dozen other package managers). It was a common complaint that installing one package could break several others, because Homebrew updated some common dependency and the new one was missing symbols or had otherwise incompatible ABI. There also was this hilarious bug report that Homebrew served everything over plain HTTP (and Homebrew had no digital signatures whatsoever), and the ticket got closed by a Homebrew team member saying it's not a problem, which spoke tons about their competency in package management. I don't know how the situation looks now, but when Howell was interviewed by Google, Homebrew was not something you could be proud of writing.

mlthoughts2018 8y ago
> "People usually omit the part that Homebrew was at that point a quite shitty reiteration of ideas" I realize we might just disagree in our assessments, but I think this is an unfair characterization. At that point in time, homebrew was basically the only way I could get cross-platform support to work for several image processing projects that my lab was working on. To us, despite its obvious rough-around-the-edges needs for incremental improvement over time, it was a complete lifesaver. I think this speaks to a larger point too about the way that engineers cut down and compete with other engineers in petty ways, instead of acknowledging that getting a complex working system up and running that adds value for people is a huge accomplishment that utterly dwarfs any sort of algorithm trivia in terms of whether a candidate is worth hiring, especially in a company like Google. The perspective that, > "when Howell was interviewed by Google, Homebrew was not something you could be proud of writing." is just so incompatible with my world view about what counts in software engineering that it likely means we are coming from perspectives so far apart that there's little hope we could agree.
- dozzie 8y ago
  Success of Homebrew was based on marketing, not on the tool being well designed on technical level (because it was not designed well) or its authors' technical competence (because they haven't displayed it much). Google was hiring for a technical position based on technical prowess, not on marketing one (maybe the skills tested were unrelated to the job, but they were still technical), but people pulling out the Google vs. Homebrew case mistake one for the other, which certainly needs correction. > [...] likely [...] we are coming from perspectives so far apart that there's little hope we could agree. You see, I come from Linux administration field. We have package managers deployed in the field for two decades now. These package managers usually don't silently break your library dependencies on update (though Fedora and desktop Ubuntu break them with a lot of noise) and have integrity ensured cryptographically. I take these features almost for granted, as I work with them every day for a long time. Any package manager that provides anything less than that is, in my view, badly designed, especially because there are many examples of how it should be done, it just takes some effort to learn them. On the other hand, you, coming from macOS angle, didn't have a prior experience of working with many package managers -- or at least that's my guess. If I am right, it's quite clear why a poorly designed but popular package manager (i.e. one that has many packages available already) was a huge improvement for you. It was the same for Debian's APT twenty years ago, but APT had pretty much no prior art and the internet was not a viruses/worms/spyware-driven machine it is nowadays.

jacquesm 8y ago

Google apparently is not an element in the set 'some circles'.

justaaron 8y ago
saved the best reply for last. full circle. zing!

acqq 8y ago

Google byrocracy required from Ken Thompson to pass a C language exam. https://www.theregister.co.uk/2010/04/21/ken_thompson_take_our_test/ https://www.theregister.co.uk/2010/04/21/ken_thompson_take_o...

zerr 8y ago
C exam aside, I don't think he would pass a regular Big G interview, unless he'd allocate some 6 months for preps which I doubt he did.
- johannes1234321 8y ago
  Considering that he is not one of the young hackers starting with JavaScript, but in a time were looking at raw memory dumps was normal operation and memory was sparsely available and CPUs were slow I assume he well knows about algorithms and data structures by heart. Most likely he implemented more binary trees in his live than I thought about and I assume he would consider a question about inverting a binary tree more of a joke than a serious question.
  - acqq 8y ago
    > I assume he would consider a question about inverting a binary tree more of a joke If you refer to this: https://www.quora.com/When-do-you-need-to-invert-a-binary-tree https://www.quora.com/When-do-you-need-to-invert-a-binary-tr... I also don't know why would anybody ever need to implement "inverting" a binary tree except for the Google exam. > Most likely he implemented more binary trees in his live "Most likely"? Actually he "just" invented (not a complete list): - Unix (with Ritchie) (in assembly first) - the language B, based on which Ritchie developed C. - the notation for the regular expressions everybody uses today - the algorithm for fast regular expression handling - the chess computer that won the 3rd World Computer Chess Championship 1980
    - johannes1234321 8y ago
      > > Most likely he implemented more binary trees in his live > "Most likely"? Actually he "just" invented (not a complete list): Please mind the full quote of me "... than I thought of" -- I thought (and implemented) about trees quite a bit myself and grant him a few factors on top of that.

samatman 8y ago

Attitude is important. If you have a solid codebase that you created, insist on being interviewed about that codebase. That screens out a few employers, but not nearly as many as you think. Most are desperately looking for a way to determine that a candidate is good. Sitting back while they explain in increasing detail how their pet project works is close to ideal here.

userbinator 8y ago

Is this true though? I mean Google famously didn’t give a shit about hiring Max Howell (creator of homebrew) because of hazing-style pointless whiteboard trivia [0]. Creating a package manager, which is mostly "gluing things together without understanding how they work", is a very different skillset than being able to work from first principles. I suspect Google was looking more for the latter. Speaking as someone who has written pieces of compilers, emulators, assemblers, and related software in my spare time, I can say that even mentioning those things casually is enough to get some "you did what?" looks.

stirner 8y ago
The one topic from “hard” computer science that applies to package management is graph theory. Inverting a binary tree is one of the simplest operations you can do on a graph. Google may have been interested in Howell because of Homebrew, but not understanding this simple algorithm probably showed them that he didn’t have the skills they originally thought his project exemplified.