Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google: 90% of our engineers use the software you wrote (Homebrew), but...

twitter.com

Post reply on HN
Print view View original

601–610 of 683 posts

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#601

Post by markbnj »

Grue3 wrote: post #588
markbnj wrote: post #418

Number of times I have had to invert a binary tree in my 25+ year career: 0. Number of times I have been asked to invert a binary tree in an interview: 0. What I would do if I had to invert a binary tree: look it up.

So, you can only solve problems that somebody else has solved already?

It may surprise you, but in the real world very few people get paid to find new primitive methods of manipulating fundamental data structures. Google may do a lot of that, but they are an unusual company. The problems a working developer is asked to solve are far more likely to involve higher levels of abstraction. The one I worked on most recently was coarse geocoding (find city/state) of free text. But a couple of decades ago I did sort of invent a use of BSP trees for searching RGB palette space (http://www.drdobbs.com/cpp/vga-palette-mapping-using-bsp-tre...). Well, probably not, but I still think I should get a cookie.

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#602

Post by codeshaman »

Alupis wrote: post #70

Has no one stopped to question what Google may have been looking for in a candidate? The OP has written some great apps, sure, but there is a huge difference between writing a package manager for Mac (among other Mac/iOS apps and utilities) and writing incredibly complex, highly performant algorithms for say search indexing, machine learning, ai, etc... In that context, knowing CompSci basics like Binary Trees (usual…

All that you say is true, but there's another side of the coin.

Nobody wants rockstars in teams, because rockstars are bad team players. That's the reason why they're rockstars. Nonconformity (sometimes) leads to innovation. Like it or not, a lot of the tools and libraries which we use every day and on which the internet runs, was written by lone-wolf 'rockstars' too weird and too eccentric to work in large corps.

You don't want your whole army to go over those mountains, you send scouts. Scouts are terrible soldiers, but they are quick to find a path between the trees and rocks and they come back with new information, new ideas and concepts of how to optimally win the battle. Then and only then you bring the whole army and win.

A company, imho, should always have a small number of rockstars - impossible characters, crazies and lunatics with universe-sized egos, who have a track record of successful projects in the wild, working on insane things, alone or in very small groups, carefully managed by someone who can earn their respect - usually a lone wolf turned general.

They might be terrible programmers, they may have no education, but they have this unusual ability to see into the future and come back with interesting ideas and prototypes, which the 'soldiers' - people with solid fundamentals - can polish and transform into profitable products.

If a company innovates 'from the top', then it's trend is going to slowly be downwards towards irrelevance, because true innovation comes from the trenches and is done by the rockstars nobody wants to work with.

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#603

Post by 72deluxe »

nextw33k wrote: post #583
72deluxe wrote: post #567

Earlier quoted context omitted.

I don't have it installed on my Macs - what am I missing? I write C++ daily on them. EDIT: Seriously, what am I missing that I'd need as a developer? My dayjob is on a Mac Pro writing desktop software and my hobby at night is on a MacBook Pro doing the same; it's on neither machine.

brew is a package manager, I can install a set of applications and libraries that will be kept up to date with a simple command line. If your coding doesn't take you outside of what Apple provide then you are probably not missing anything. Personally I have the Android SDK and NDK, QtCreator, Qt5, cppcheck, cloc, mongodb, node, wine and others. If you are not using a variety of 3rd party tools to produce/automate you…

I use xcode and use wxWidgets, but I grab these manually and compile them myself. I also use the Android SDK and NDK, cppcheck cloc etc like you

I didn't realise that they could be kept up to date with homebrew?? Is that the case?

Last time I looked at MacPorts (and perhaps homebrew) I saw it as a porting of BDS/GNU tools to OSX and therefore making the OS more Linuxy to my mind. I wanted a clean break from Linuxland when I moved to OSX, hence I removed MacPorts etc. (Additionally the ported software all ran under X and not Quartz so it didn't really fit in; also, the fetched packages and compiled systems were massive in size which I didn't appreciate on a laptop that shared space with recorded audio and video etc. so space was at a premium).

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#604

Post by kazinator »

tzs wrote: post #599
kazinator wrote: post #108

WTF is "inverting a binary tree?". The smattering of search engine results points to some seemingly operation that basically generates garbage by destructively manipulating the tree into a DAG in which the leaves of the original tree are roots, which point downward the parents. The original root node is returned, and still points to its children. Unless you return some aggregate (e.g. list) of all the roots which are…

My guess is that the potential leaking of some nodes is one of the points of the question. A lot of people would not notice it. Note that in the original tree each node needs storage for two pointers. After inversion only one is needed. You can use that now unused storage to link together the multiple roots to solve the leak problem. But note that only consumes the second pointer storage in the roots. Interior nodes…

If you invert the tree such that each node points to its parent, and there are no child pointers, you lose information. Namely, the order among children is lost. A given interior node still has two children as before, but it is not known which is the left child and which is the right child; there is just a set of up to two nodes which point to the same parent.

The binary tree inverse specifications/implementations I have looked at preserve the information by selectively using the left or right links. For instance, given:

     P
    / \ 
   L   R
The inverse would be:

   L   R
    \ /
     P
Both children point to the parent. But the left child uses its right pointer, and the right child uses the left pointer. That's what preserves the information about which child is which.

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#605

Post by zaphar »

dennisgorelik wrote: post #538
HeyLaughingBoy wrote: post #417

Earlier quoted context omitted.

Easier said than done. We had a really bad hire about 2 years ago. So bad it caused us to review our entire hiring process to understand how he got in. It took almost a year before he was fired (and he was a contractor so it should have been easier). In that time, he used up untold resources while we tried to find work he could actually do, people helping him "just in case he just needed a helping hand" and so on. Fi…

"Finally after wasting other people's time for 9 months, a manager made the decision to get him out." Why did the manager wait so long?

Because it's hard to fire someone. Lets discount the emotional cost completely and simply look at this in terms of financial risk to the company.

Employee X is hired. After a month it becomes clear to the whole team that X is a bad hire. But how do you turn a subjectively obvious feeling into an objectively obvious reason to fire. Because if that person decides to sue the company after getting fired that's what you will have to demonstrate.

Just imagine how hard it is to quantify what makes someone good at our job? Code Quality? Team dynamic? These are really fuzzy metrics.

You could document how many times the engineer affected production badly and how much that cost the company. But to be realistic even great engineers do that. Heck I touched production at Google and decreased revenue by millions of dollars and it was expected that this happens. So you'd have to let him affect the company enough times to be obvious He's worse than your other engineers.

You are going to have to have documented enough clear failures to do the job to justify starting the process of firing. If you don't have a performance improvement plan then you might be able to speed up the process a little. However not having a performance improvement plan is both a bad idea and, I would imagine (IANAL etc.), could cause problems later on down the road in a potential suit.

Taken in that light 9 months doesn't seem that long at all.

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#606

Post by BinaryIdiot »

wyldfire wrote: post #592
BinaryIdiot wrote: post #363

Earlier quoted context omitted.

> You'd be shocked to hear the number of impressive résumés I have seen who turned out to be absolute no-hires after 20mn on a white board. Hmm, at least in my experience it's really quick and easy to tell if someone is bullshitting about their resume or not by simply talking about the different projects they worked on. I know a few developers who didn't go to a 4 year school so they don't know all of the correct ter…

Google doesn't have any SCIFs...do they?

So I just meant in general for any tech interview...but I would say there is a good chance they do.

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#607

Post by moultano »

eropple wrote: post #423
nostrademons wrote: post #194

Earlier quoted context omitted.

All of infrastructure. You end up using LSM trees, Paxos, variations on binary search trees, checksums, Reed-Solomon, bloom filters, external sorts, and all sorts of other academic algorithms when you deal with distributed systems. Docs/Drive does a lot with operational transforms and CRDTs, ever since Wave was merged into it (c. 2011). Remember that all Google Docs are collaborative. All logs analysis & experimentat…

There's totally a lot of crunchy CS in many things Google is into (and I do distributed systems stuff, so I can empathize heavily with your first paragraph). If you're doing it right, though, writing the crunchy CS bits of these should be exceedingly rare. Understanding is important, but I'm not sure you get a measure of working applied capability from writing this stuff in an interview. Discussing it, surely, but th…

Not everyone is constructing them, but everyone needs to be able to reason about they behave, determine what they need, and yes write it if a good option isn't available.

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#608

Post by BinaryIdiot »

reagency wrote: post #518
BinaryIdiot wrote: post #337

Earlier quoted context omitted.

My experience wasn't a real life type one more academic instead. My interviewer was really late and refused to let me finish my data structure implementation to optimize a single method instead. When we finished it was time for him to go. He wouldn't let me go back to finish my data structure as he didn't have the time. I was later declined. Had a couple of friends at google ask the interviewer. He said I was decline…

Your story can't be true because interviewers do not make hiring decisions at Google.

I can assure you my story is accurate. The interviewers do not make decisions regarding the entire hiring event but they do give feedback regarding how you did in each interview. I was given poor feedback due to, according to him, a zero tolerance like policy where the data model for that particular question had to be complete and I was unable to complete it.

That was my first technical interview over the phone so it was pretty obvious it was related to that single interview. One of the Googlers I knew that checked the system said the same.

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#609

Post by scottlamb »

jowiar wrote: post #239
sshumaker wrote: post #199

Earlier quoted context omitted.

I think you may have left with the wrong impression. If you ask Googlers or Xooglers alike, most agree that the people here are actually the best thing about Google. Like anywhere else, there are some bad apples, but compared to most other places the people here are on average more talented, nicer human beings and more helpful. Certainly compared to your typical startup or other BigCo. In my nearly 3 years here, that…

As far as my specific interviewers are concerned, I liked 7 of the 8 as individuals, which is great. What I didn't like was the company felt like a monoculture. Same schools, same majors, same pre-education background. Everybody looks the same, dresses the same, etc. The process, on the other hand. Ugh. I have zero respect for Google as a company after that. It starts with the standard phone screen/day-long onsite/ha…

> What I didn't like was the company felt like a monoculture. Same schools, same majors, same pre-education background. Everybody looks the same, dresses the same, etc.

One reason you might have gotten this impression is that Google picks interviewers who have a lot of overlap in expertise with your resume so they can ask questions tailored to you. For example, if you have a PhD in computer science, many of your interviewers will, too.

I'm a Googler, and I don't think Google is a monoculture. Okay, maybe everyone does dress the same. But I've had teammates from wildly different cultural backgrounds—including Irish, Romanian, German, Hungarian, Israeli, Iranian, Pakistani, and Indian, and Chinese. Even among teammates from the US, it's not all the same schools. I went to the University of Iowa, which probably isn't one you had in mind. I've had teammates without a college degree (and I don't just mean interns).

I do think the interview process sucks. IMHO, it's the most bureaucratic part of Google. Sorry for your bad experience...

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#610

Post by ksk »

markbnj wrote: post #488
ksk wrote: post #446

Earlier quoted context omitted.

>Number of times I have had to invert a binary tree in my 25+ year career: 0. Number of times I have been asked to invert a binary tree in an interview: 0 Well, if you wanted to pull that card, it would have been nice to mention the sorts of problems you've worked on in those 25 years. >What I would do if I had to invert a binary tree: look it up. Unless you're already good at algorithms, it would net you a mediocre…

>> Well, if you wanted to pull that card, it would have been nice to mention the sorts of problems you've worked on in those 25 years. Quite a range of stuff, unsurprisingly. I started on an HP3000 mainframe in 1976, if you want to go back to the very beginning, writing BASIC programs on a teletype or one of the two early CRTs, and storing my programs on paper tape. Since then I've worked in DOS, 16-bit Windows, 32-b…

Thanks for replying. I simply wanted to know what kinds of problems you worked on. A binary tree can be inverted presumably on any OS and using most languages. If you're going to claim that a basic binary tree operation has not be necessary for you in your 25+ year career, you should have mentioned your problem (!industry) domains. It was nothing personal.

>and if you think that having studied up on it so that you could pass a Google interview means that, a few years down the road when you actually need it you'll just whip it off the top of your head, then I think life may hold some surprises for you.

That is a misrepresentation of what I said. I said that _RETAINING_ basic and higher order CS fundamental knowledge is much more useful, in a way that simply looking up an algorithm on wikipedia would not be.

Post reply on HN