Homebrew 1.4.0
brew.sh
brew.sh
I read somewhere ( and I bet ) it's used by Google / Facebook / Apple employees.
:-P
...and you'd be wrong. It is very common for Apple to test its new browser versions on the public internet and for those version numbers to show up in the logs of popular Apple web sites. It's one of the ways that Think Secret could confirm that a new version was on the way.
Anyways there is surely something strange brewing for the next macOS, as Apple has repeatedly noted that "macOS High Sierra will be the last macOS release to support 32-bit apps without compromise", without specifying what kind of "compromise" might come up (see https://developer.apple.com/news/?id=06282017a )
Homebrew security is good enough for you and me but not good enough if you're working on Apple software.
Why not?
I'm sure Homebrew has a significantly higher value, but you've got to weigh the tradeoffs. If Homebrew cost $9.99 a year for access to updates I would pay it, but I know a lot of people would complain.
I'm really surprised that instead of "lots" I have to write "some".
I also think that it's a much bigger win, financially and for P.R., to donate some of the profits, instead of paying the taxes in selected tax-paradise countries.
FOSS is seen by upper management as a way to avoid paying for software, instead of pirating it, and contributing code back is frowned upon.
One place I worked, it was easier to order a new work van for the department than a $30 program because the program could only be downloaded, and not bought in a box.
So they try to keep people from buying from non-approved (i.e. no kickback agreement) vendors as much as possible, no matter if the company loses on the long term (worker happiness, productivity). Also, keeping records, both financial and stuff like license expiration is easier with one to a dozen suppliers than hundreds. The major enterprise vendors (eg MS, Adobe and Acronis) actually have dedicated enterprise license management solutions, which a tiny shop usually does not.
While we implicitly give away the software for no cost, we don't really try to brand it as such (though for some, lack of cost is certainly a big plus).
It's a shame "open source" got co-opted by the OSI and the Free Software purists are left to continue to use "free". I doubt something like "libre" would catch on; some people use it, but it doesn't seem to be used widely enough.
Anyway, that number would probably be higher if it were advertised more.
but this made me wonder: would there be fake Patreons accounts? How much verification is done?
I face this with my government clients. They spend very little time thinking of the actual amount (even if it's $30k), and more time about "how are we going to purchase this??"
Tip Jars aren't an effective way to get money for this stuff, at least if you want money from companies. It's good for "aw this library helped me, let me throw in $5" from individuals.
Give a company a proper bill with VAT, and they'll stuff you with money.
It's $312 a month now, but that's still super now. We should at least get them to where they can afford a few beers with the monthly groceries.
In fairness, it's used by virtually everyone who has to do anything of significance in software development on a Mac.
Why? What are these workarounds? The linked PR didn't explain, and as someone who's still got one machine on 10.12 I'd really rather not have to keep CLT installed as well.
Edit: Wow, the maintainer on that PR is a real jerk. He refused to answer a legitimate question (and locked the PR at the same time) because he thought the original (since edited) complaint of "The error message for this patch is terrible" was "rude".
MikeMcQuaid, if you ever read this, this sort of behavior on your part is a great argument for ditching HomeBrew.
Things are easier these days with great CI tools, cloud stuff like CDNs, cheap storage and bandwidth, and FOSS sponsors.
Scratching your own itch is something that can be worth being done at times. After all that's how Homebrew started, when people grew discontent of the complexity of MacPorts and Fink. There were dismissing words towards Homebrew back then too (like "wait till they have to do X").
That's not an argument, that's basic herd mentality and can literally apply to any kind of critic legitimate or otherwise. Even Linus does not get a pass nowadays and there is really no reason on HN where we can be so critical of even the most minor design mistake.
Look, open source maintainers don't owe anyone anything. It behooves them to behave in a positive manner in order to encourage people to contribute, and, well, just because being nice tends to give you a good reputation. But that doesn't mean they're not still people. Sometimes they'll be curt or terse after someone asks a question about a decision that has already been beaten to death because they're just tired of talking about it. Maybe they just had an argument with a friend or family member and aren't in the best frame of mind. Maybe they're just having a bad day.
And that's ok. That's just human nature. As long as the majority of interactions with users is positive, everything's going to be fine. A few people might get their feelings stepped on here and there, and that's truly unfortunate, but I'd also hope that those people give the maintainers the benefit of the doubt and recognize that one bad interaction should hopefully not sour all the positive value they've gotten out of the maintainer's work.
Sure, if there's a huge pattern of abuse, that's a problem. But I submit that a one-off issue submitter is not qualified to assess if there's a pattern or not, especially right after they've just been rebuffed and still feel bad about it.
To enlighten the polite people who have not insulted Homebrew maintainers: the issue with requiring the CLT on everything but the latest version of macOS is because of the horrible workarounds. Grep the Homebrew taps for "Xcode-only", "CLT.installed?", or "clock_gettime" for an idea of the amount of hacks required. I don't know precisely why this occurs but it's related to Apple only shipping the latest SDK in Xcode rather than one that matches the version of macOS that Xcode is running on.
Nor do I buy the "public forum" argument. You direct your writing to the audience you have (i.e., the person that asked you a question rudely), not an imagined audience that might be reading. "Lock the PR so nobody else can ask the question either, and screw anybody who actually wants to know the answer" is projecting; there's nothing about locking an issue that shuts down all conversations, just the one in the issue that is being discussed (that again, to emphasize, is a rude conversation anyway).
So the maintainer took an extremely minor just-barely-qualifies-as-a slight and decided to react about as bad as you possibly can. It's awful.
And I'm not projecting either. zenspider had a legitimate complaint and a real question, both of which I care about. The complaint still hasn't been addressed, and the only way I was able to get an answer to the question was to ask here on HN. But that answer isn't visible to anyone else who looks at that PR (i.e. anyone who sees the changelog entry and wants to know why the CLT are now required), which I guarantee you is a nonzero number of people.
Even the thimble of energy required to ignore a comment is yet another thimble of energy taken from the pool when all you're doing is helping somebody.
The hard line approach might seem silly in isolation, but I don't think it's unreasonable. The slow creep of community negativity has burned me out on one of my own projects, a forum I run.
One perk of zero tolerance is that it spares you energy for more important decisions. People are quick to point out that it comes at the expense of alienating some folks, but nobody ever seems to care about discouraging the people actually doing the work.
EDIT: reworded
macOS is a constantly moving target, and it's hard enough to get consistent behavior across multiple versions with the CLT installed. It's a losing battle that I've been fighting for the last 3 years, and it's one with diminishing returns (only a minority of Homebrew users don't want/need the CLT for other purposes anyways).
Edit: As for PR, we get a lot of issues and PRs that amount to handling a 1% case at the cost of the 99% case. When we get those, we have to consider both to time cost to ourselves and the future maintenance cost. We could probably be a little less brusque about it, but the reality is that we don't have the kind of labor or resources necessary to support maintenance-heavy features like CLT-free installs on older macOS versions.
Remember that maintainers of projects like Homebrew have to deal with an endless stream of complaints and feature requests, and don’t get paid to do so. If this commit is a big deal for you, just make the effort to bring it up in a nice, thoughtful way. Or, don’t use the software if you don’t like it/the maintainers.
And no, that's not a good description, because it gives me literally zero information to go on in order to find out what the workarounds were, how many formula actually needed them, and what the problems were that necessitated this.
> Remember that maintainers of projects like Homebrew have to deal with an endless stream of complaints and feature requests
Yeah, that's what happens with popular open source projects. Good projects are able to handle this in a way that doesn't alienate the community or future contributors. The fact that MikeMcQuaid is doing this for free does not remove the obligations he has to the community.
There isn't an obligation though. You could fork or pick an alternative as much as a maintainer/owner can abandon a project. They aren't obligated to do anything for you and you aren't obligated to do anything for them.
If you don't like a project because of personalities involved, avoid them. I have personally done this without problem. It can be a pain but I have no actual pull in the matter.
Why do you feel that you're entitled to this information? And/or that providing this information is a good use of the maintainer's unpaid volunteer time (and that it's immediately obvious to the maintainer that it would be)?
> Good projects are able to handle this in a way that doesn't alienate the community or future contributors.
Homebrew is one such project. Empirically, they have an active community and sufficient contributions to keep the project robust and growing. That doesn't mean that they're going to be perfectly nice and polite to everyone, bending over backward to every user's whim. Sometimes someone is going to feel off-put as you have. But, clearly, most of the time people have positive experiences, so I'm sure they're satisfied with their performance.
> ... doing this for free does not remove the obligations he has to the community.
The only obligations I expect from an OSS maintainer is that they won't be negligent or malicious -- that is, they will work hard to avoid catastrophic bugs that destroy data or open security holes. Even given that, I accept that those sorts of things may happen due to innocent mistakes. Beyond that, I pay nothing, so I expect nothing.
This sort of thing reminds me of really the only negative I've experienced as an open source maintainer: users with feelings of entitlement.
You should also give them the benefit of the doubt and cut them a bit of slack when they don't behave exactly as you'd think that you would. (I say "think" because it's all well and good to take the moral high ground in theory, but unless you're actually in that person's shoes, it's hard to speak in absolutes.) I've said this elsewhere, but: perhaps you hit the edges of a long drawn-out discussion that took place out of your sight, a discussion that was tiring and draining, and he just didn't feel like rehashing for you. Or maybe he simply just got out of an argument with a friend or family member, or just had a bad day.
That may not excuse his behavior in polite society, but it makes it understandable. You had a one-off bad interaction with someone. Boo hoo. It happens. Give people the benefit of the doubt, and, unless you have very strong evidence to the contrary, assume your experience was an unfortunate outlier. Homebrew is obviously a successful, robust project, with lots of contributors, so maybe, just maybe, your negative experience isn't typical, and perhaps most people who he interacts with actually come away with a positive impression. We can't all always have our best faces on, 100% of the time. Generalizing your single interaction as the norm is arrogant, ignorant, and selfish. Apply the principle of charity, and move on. If a person/community is truly toxic, then that needs to be addressed, but you seem to be assuming that your single bad experience is the norm, without taking the time to actually do any research... and feel the need to repeatedly trash-talk here for some reason.
If you met this guy in person and said "hey, I had a bad experience interacting with you online", and he didn't talk it out and apologize, then that would speak poorly for his character. But you have one tiny insignificant data point to go on, and I think it's incredibly disheartening that you've chosen to take that as representative to such a vehement degree.
I'll say again that it's worth remembering that the maintainers are putting in a tonne of work, dealing with huge volumes of issues and PRs, and doing it all for free, while also working full time jobs and having lives outside of programming. It's necessary for them to write short/quick replies, and if people are being rude (as the one guy was in the PR comments), it's pretty reasonable for the maintainers to be dismissive. Also, I disagree strongly with this sentence:
"The fact that MikeMcQuaid is doing this for free does not remove the obligations he has to the community."
None of the maintainers have obligations to the community.
The commenting user in this case immediately opened another issue where they were rude to another maintainer too, had to be warned about their behaviour and (unlike most people who are warned) did not apologise. This issue was not locked.
My work on Homebrew over the last 9 years has been almost entirely in my free time. That's time I'm not spending with my wife, friends, dog or (now) new baby. As my Twitter and GitHub bios point out: "I block rude people". I'm not interested in giving my free time to people who cannot be polite.
The GitHub UI indicates whether someone is a first-time contributor, contributor or maintainer. You get cut proportionally more slack for having a bad day and being rude if you've contributed to Homebrew already. I try to be over-the-top positive for new contributors and I will immediately and genuinely gratefully accept apologies that are given.
> MikeMcQuaid, if you ever read this, this sort of behavior on your part is a great argument for ditching HomeBrew.
If you'd like to ditch Homebrew: please go ahead. There's things that MacPorts do better than we do and the MacPorts maintainers I know are good people. If you use Homebrew: you are the one who benefits, we do not. I want to build something that's useful but primarily maintaining Homebrew needs to be an enjoyable experience for me and others for it to be a sustainable project.
If I was on the fence before, I'm not now. Time to ditch Homebrew and stop recommending it to friends. You are poor stewards of the project and of your community.
Mike, I don't know what you think you're doing, but you threatened to ban zenspider simply because they asked to have their issue reopened, and you actually banned me because I pointed out that your behavior was unacceptable. I'd go so far as to say you're actually violating your own Code of Conduct, and if you had any sense whatsoever, you'd immediately stop interacting with the community and appoint someone else to handle all tickets from here on out.
Anyone else getting a warning about command line tools?
$ brew doctor
Warning: A newer Command Line Tools release is available.
Update them from Software Update in the App Store.
/Library/Devloper/CommandLineTools/usr/bin
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Homebrew checks the command line tools version by running "clang --version". It uses this one:
/Library/Devloper/CommandLineTools/usr/bin/clang
The version I have there is 900.0.38. The version under Xcode.app is 900.0.39.2 (which is the version Homebrew wants).
Looking back at my Time Machine backups, I see that /Library/Developer/CommandLineTools/usr did not even have a bin directory until 2017-11-23 (it just had usr/share/man). The bin directory there, and its contents, were apparently created when I installed "Command Line Tools (macOS High Sierra Version 10.13) for Xcode" version 9.1 from the App Store on 2017-11-22. That had clang version 900.0.38. That is also the version that was under Xcode.app at the time.
It looks like on 2017-12-06 there was an Xcode update (version 9.2) that updated the command line tools under Xcode.app bringing the clang version to 900.0.39.2 (which is the one Homebrew wants).
I haven't seen any updates for the "Command Line Tools" package, so what is the correct way to get the 900.0.39.2 tools into /Library/Developer/CommandLineTools/usr/bin, where Homebrew expect to find them? Is Apple just being slow to get the update out?
Side note: I find it a pity brew upgrade webcalls google analytics.
analytics (on|off)
Turn on/off Homebrew's analytics.PS: Despite my feelings of disagreement on how brew handled this, I still appreciate your work.
No, it's not at all like the software forgetting the options you've set. It's the software, in the interest of providing a user with the greatest possible control over their software, while having the average user's propensity to forget minor details in mind, offering the explicit option to re-evaluate a prior choice in the future without having to remember to do so, or manually recall the way to do it.
Moreover, when I threw out the off-the-cuff idea to occasionally re-prompt, I set that occasion as an annual one. You're making it sound in this overreaction as if I suggested it to occur every few days or weeks. Instead of instantly going to such unwarranted extremes as full-on-intense-rage-mode-11, thinking to yourself, "Oh my fucking god, what the fuck is wrong with this developer that s/he'd dare to ask me this question I answered 2 years ago again?!", you might pause just a moment to consider it to be a little like recalibrating a tool that's been in use for some time. Few people keep static positions on things. Such recalibration doesn't need to occur at every minor upgrade, but perhaps major upgrades might want to ask the user to review their settings/choices.
I've changed my position on things I've opted in/out of at various times. When it's privacy-related, I've increasingly developed a harder default stance over the last 15 years. I wouldn't mind if my tools asked me to annually review old choices I've long forgotten--much like I've heard Facebook offers people their little privacy checkups (ignoring for the moment the efficacy of such a checkup when everything you do is tracked). Many people other than me reacted to the way in which the analytics "feature" was included in homebrew with surprise, because many of us never noticed the notification, and a great many of us believe tracking is something that should always be opt-in, not opt-out. However, as of this writing, I can't recall exactly what my current homebrew setting for analytics is, and I can't recall how long it's been since I last checked it to ensure it is what I think it is.
But hey, that's just me, friend. I can't remember every choice I made last month, much less last year, two years ago, or any time before that. If you do, that's cool. If you were using a tool I created/maintained, and I wanted to cover all my bases, I'd simply give you a way to say, "Don't ever fucking ask me this question again or I'll rage tweet what a forgetful little shit you are." :)
I guess I should have gone into specifics about why I don't like that idea... I can think of lots of things that let you set a setting and say "never ask me again", but those aren't quite the same. They're usually for things that get asked _every_ time you run those programs, so until you select "never ask me again" you're not actually setting the setting, you're just giving a temporary answer for that one use. Notice how this differs from what you've suggested (asking you based on an arbitrary time period). Your suggestion is a different paradigm than the already existing ones. I can see a case for having it ask you if you want to be tracked each time you run homebrew, or each time you upgrade homebrew, but doing so based on an arbitrary time-based interval (be it days, months, or years) seems odd and needlessly different than the existing accepted UI paradigms.
Oh, and I'm not sure Facebook's privacy check-ups is the best analogy. I always thought they did the check-ups when they've specifically changed something and need to give you the option to opt-out of the change, not as a friendly "do you still want your settings this way". Maybe I'm wrong about that, but that's what it always felt like to me when I was using facebook more, since I'd see a lot of articles/blog posts about new changes, and then the next time I logged in I'd get the privacy check-up.
The current behaviour isn't sufficient for the new GDPR requirements coming in May. Contributors and any relevant companies (or their subsidiaries) in the EU could be liable.
Under the current data protection laws, as long as it isn't personally identifying, it would fall out of scope. Under GDPR, it is in-scope, and explicit opt-in consent is required for both collection and for the things you want to use the data for.
Requiring opt-in to use the software is also not permissible.
GDPR is a bit of a beast.
[0] https://github.com/Homebrew/brew/blob/master/docs/Analytics.... [1] https://news.ycombinator.com/item?id=11566720
Though i had the option to block it, using little snitch (great app, not affiliated). For web browsing i have it on never allow already, but not for all applications i use from terminal, so the little snitch, snitched about it.
This is just pleasant to see. Some people like/are stuck using older OSes.
Which Apple itself conveniently ignores (inconveniently for its developers), e.g., Xcode hacks and looking for 3rd party copies of old SDKs to be able to keep compiling for older OSes. :(
What ties people to PowerPC these days? Surely the speed and power consumption of the latest Intel machines is 100x better?
Would it make sense to create a legal entity whose only goal would be to "sell" enterprise subscriptions to open source products and then channel all the funds to those projects, after taking a reasonable cut for administrative expenses - such as invoicing, collection, production of physical media when required and etc?
That would make support of open source projects fit much easier into standard enterprise procurement process.
Each project would define different levels of subscription with different price tags. Token licenses would be generated and physical media created and mailed out.
Pretty sure something like this was already discussed on HN?
I never know what to make of "people still use ______?!" comments
Usually people are assuming a network-effect that would make using not-Foo when Foo has "won" problematic. Like, imagine using MySpace as your social network today. It'd be a ghost town and nobody you knew would be on it.
In this case, I imagine people would expect that MacPorts either wouldn't have as wide a selection of packages, or wouldn't keep 100% of its packages constantly up-to-date, or some combination of the two.
I preferred the MacPorts model, but when I used them both, there seemed to be a lot less support compared to Homebrew. When builds stop working, they seemed to be fixed in Homebrew before they were fixed in MacPorts, and Homebrew also seemed to have more current versions of most packages available.
Every time "boost" updates, you're stuck recompiling half your ports for the next 20 minutes to use the new library. With Brew, you wait a minute for the new packages to download, and you're done.
MacPorts does not work the same way.
Edit: grammar.
- MacPorts does not track you by default with Google analytics.
- MacPorts lives by default in a self-contained directory tree.
- MacPorts tends to be more stable than Homebrew, but that’s just my personal experience.
- I didn’t like the slogans Homebrew used for years, implying MacPorts wasn’t good quality.
The ability to very easily install full GUI apps, or closed-source ones, is absolutely indispensable for automatically configuring Macs in many large environments, especially those (like a former one of mine) that heavily used Puppet for provisioning.
If MacPorts is lacking in that "umbrella package manager" functionality, I'd be stuck using both it and cask if I switched (and, given my positive experiences with Homebrew core and cask, I have no plans to).
Honestly I don't know if that's popular, when using Homebrew and MacPorts I was always installing open source stuff...
Not that we have any problems with MacPorts really.
I too am curious about qualitative differences between the two.
This is contrasted with something like dnf/yum, which has registries of assets that are supposed to be installed. I'm not positive, but I suspect something like that would be a way higher maintenance burden for OSX (for maintainers of the package management system and packagers themselves, many of whom have shown little to no interest in packaging for OSX, hence Homebrew's patch system).
It also lives primarily in its own directory, unless you're installing casks (which usually "do exactly what the installer would do if I downloaded and installed it myself") or packages with special cases that manage external-to-homebrew things. For packagers, the API for "use Homebrew-managed/blessed directories for e.g. --prefix configure arguments" is pretty good, but people (and bad, old build scripts) can and do still mess around outside of where they're supposed to. "Hosing your system binaries" is a pretty darn rare occurrence unless you're explicitly configuring brew to put things where it wouldn't normally.
Edit: plurals are hard.
Just curious, that always seemed like a strange scenario.
* or am I wrong that it ever did?
[1] https://github.com/Homebrew/homebrew-core/tree/master/Formul...
You would think `wget` for building your own mirror would work fine but no, http://homebrew.bintray.com/bottles/ returns "Forbidden", probably because the directory listing is too large.
For example, apache has been moved to homebrew-core. You can see that in the archived repository: https://github.com/Homebrew/homebrew-apache
brew update brew update
brew upgradehttps://mobile.twitter.com/mxcl/status/608682016205344768?la...
- He may be qualified to work at Google, but that's not apparent just because he created Homebrew, right?
- Google can afford to be picky enough to miss out on popular open-source project authors who _can't_ code on the whiteboard in favor of those who _can_ -- can we argue that they should reverse this, or just that in certain cases potentially-qualified people fall through the cracks?
A) Writing algos on a whiteboard is not the be-all end-all of actual programming
B) The skill set of "can identify things that people want and need and actually implement them" is a useful one that the person who created one of the most widely used pieces of OSS out there has demonstrated they have.
C) There's no evidence that I know of that indicates that whiteboard algo writing correlates with the skill set identified in B, and a fair amount of anecdotal evidence that suggests they aren't correlated. (And there are a range of other skills that are useful for an engineer or someone leading teams of engineers that are similarly not correlated with whiteboard algo writing.)
D) Firms benefit from diversity. Gender-diverse and ethnically-diverse companies are more likely to out-perform less diverse companies.[1] I don't have specific evidence for it, but I suspect that a firm that has a hiring process that brings in people with multiple diverse skill sets will eventually perform better than a firm that only brings in employees with tightly focused, highly similar skill sets.
And to respond to the "well, FB/Amazon/Google make $INFINITY as-is, so nyah-nyah", I would say that those companies are in market-dominant positions now that may make their math on hiring a diverse array of skill sets different from a theoretical firm, but I also suspect that maintaining those dominant positions will be more difficult with an engineering corps that is solely selected on a narrow band of proficiencies.
So, I'm not necessarily saying that Google should change their policy (although I do feel comfortable saying that any company that isn't in that rarified air that decides to copy that policy is making a serious mistake), but I think there's a pretty solid case for why they should at least acknowledge that there are people for whom they should make exceptions and possibly completely reverse that policy and overhaul their hiring process to achieve a broader range of skills among their engineers.
[1]: https://www.mckinsey.com/business-functions/organization/our...
I do agree that the "make things people want" is a very useful/desirable skillset for a vast array of non-Google-scale companies, and I'd personally prefer to work for a company that values this.
But I'm willing to posit that at a certain software engineering scale, the problems and valued traits are very different, and may align more with "knows data structures" than "can make something people want".
I'm not saying Google should value one to the exclusion of the other. But perhaps if you have Google's talent pool, the base level is "ingrained data structure knowledge" (correlating to engineering skills they need), and they'll also get the "ingrained data structure knowledge AND ability to make something people want" applicants.
I'm not arguing that other companies should do this. Just exploring whether it makes more sense for Google than perhaps we would think.
But also maybe it's better that those people don't end up at Google et al. and that these gigantic companies stagnate and eventually die because their corporate bureaucracy/scar tissue prevents them from hiring the people who can prevent them from stagnating and dying? I dunno, haven't really fleshed this idea out too much.
Yep, agreed! But since there's probably some overlap in that candidate skillset Venn diagram, maybe they're getting the people that can do both, and the data-structure skillset's the one that's possible to consistently interview for.
Working software should be prioritised over rote memorisation of data structure theory.
When I interviewed at Google they asked a lot of (at the time) very specific questions about various languages but only 1 “solve this riddle” type question. It was a pretty good experience.
The best interview I ever did was with an investment bank where I was struggling to whiteboard some problem (after a string of really tough, challenging problems I did well at) and they let me use a terminal to actually code it up (which I managed to do very quickly). I got that offer. ;)
That said, I'm pretty sure that interview questions like these are not about whether or not someone is qualified to do the job they're actually doing, and 100% about companies trying to come up with a standardized, one size fits all tech interview that can be used for every position. Since the intersection of necessary skills for all kinds of developer jobs is something close to {"understands values vs. references", "knows at least 1 programming language"}, though, the result of any such endeavor is going to involve a lot of noise.
It works for Google because they're such an attractive employer that they're dealing with essentially zero risk that they accidentally filter out all their qualified applicants with stuff like this. It probably even helps company morale by fostering a perception among Google employees that they are an elect few.
You know the founder of homebrew was filtered out by exactly this, right?
I said that there's minimal risk that they filter out all qualified applicants, not that they won't filter out any of them.
Pretty much. We had a conversation at work about this recently, where folks were talking about how they were varying up the interview process depending on the applicant.
Some people pushed back saying we needed a one size fit all process to avoid things being unfair/biaised/etc.
When you push that to the extreme, the google process is what you get (and who gets hired is biased as hell anyway).
While it has its flaws, Ill always push hard for personalized interviews whenever possible. Look at someone's resume to see if its someone who would be useful to you, then test them on THAT to make sure they're not bullshitting on their resume.
The only standardization is the thud of hitting the floor due to all participants expending the least possible effort. Like a team building trust fall where everyone is too busy checking Messenger to be bothered to extend their arms.
The shared failure of institutionalized apathy.
but your "zero risk" assessment is a common but unproven justification of such hiring practices. with good management, you can easily bound the cost of a bad hire to a few (tens of) thousands of dollars. it's hard to estimate the benefit of a good hire since that's an alternate reality not taken, but it's probably many, many times higher than the cost of a bad hire:
opportunity cost of losing a good hire >>> realized cost of a bad hire
(the probability of a bad hire is higher than of missing out on a good hire however, so you'd need real numbers to estimate the relative costs)
Just because you don’t use binary trees doesn’t mean Google or Amazon don’t, though. Maybe not binary trees themselves, but b-trees and similar data structures are widely used in file systems, databases, and other large scale systems that these companies routinely work on.
Also, everyone knows that companies ask questions about data structures and algorithms. If you’re have the ability and inclination to prepare for these interviews, that says something about you as a candidate. If you don’t prepare at all and then go on the internet to whine about it when you don’t get an offer, that also reflects on you.
Popularity doesn't mean quality and the entitlement of that tweet would be a red flag to me as an interviewer.
Homebrew has improved a ton over just a few short years. The Linux ecosystem did the same, as did many other projects that started out as a popular-but-less-featureful/reliable alternative.
If it's been awhile since you tried it, I'd check it out.
In my view, the correct response to being turned down at a company where I want to work is to simply try again later. No need to stress about it.
I think that is rare.
Also “inverting” a binary tree is a trivial computation exercise. There’s a difference between engineering and scripting. Homebrew is very much a scripting problem.
Nobody is saying anything other than that. They're pointing out how dumb the decision is.
"Also “inverting” a binary tree is a trivial computation exercise."
It really isn't, especially if you're not doing it on a regular basis. Which I'd contend 99% of people, including those at Google, are not doing.
"There’s a difference between engineering and scripting. Homebrew is very much a scripting problem."
Aside from, you know, the entire infrastructure around it. That is very much an engineering problem.
I think filtering people based on ability to solve trivial binary tree manipulation problems is brilliant. Seems to objectively be working out great for google thus far.