Hacker News new | past | comments | ask | show | jobs | submit login

In addition to people who made it through a phone screen and got an in-person interview, there are those of us who simply never applied after hearing so many stories about Google's style of interviewing and their reputation of favoring young CS grads.

I worked as a contractor for Google from 2008 through 2013 (along with other clients), building election results and voter information maps for their Maps and News teams. My maps ran on google.com and were syndicated out to a number of news sites.

How I got in was an odd fluke: I'd been active on the Maps API mailing list answering people's questions, and a couple of weeks before the 2008 Iowa caucus and New Hampshire primary, Google realized that the company they'd hired to build those maps wasn't going to deliver, so they asked if I could jump in and build something in a hurry that worked.

The first year I did the whole thing myself: GIS processing to turn geographic boundary files into usable form, back-end processing to gather vote data from AP and other sources, and the front-end UI design and map development. Among other things, I developed a way to display polygons on a map many times faster than the Maps API itself.

A couple of the maps blew up in a spectacular way (I managed to DDOS Google Code on Super Tuesday 2008!), but mostly they were pretty successful with millions of viewers.

After that a couple of Google developers handled the back-end vote processing and I took care of the GIS and front-end work, both for the US and a number of international election maps. For some of the international maps, local teams worked with my front-end code to enhance it for their needs.

It was a pretty good run and Google seemed very pleased with my work. Eventually a great team in their DC office took over the map development, and I started to think about what to do next.

One obvious idea, of course, was to apply for a job at Google! After all, I'd already worked for them rather successfully for five years.

But I didn't even apply. Perhaps this was a mistake on my part. I just had a feeling that my history of developing successful products for Google wouldn't count for much - that instead I'd get logic puzzles, quizzes about algorithmic minutiae and have to code a red-black tree on the spot on a whiteboard - all things that favor recent CS grads. Plus, I'd just turned 61!

I wonder how many other people there are like me, experienced developers with demonstrated ability, who never applied because of Google's interview practices (or the rumors about them)?

FWIW, I'm still actively programming, getting into something new every year or two - right now it's an odd mix of VR and Microsoft Office development - and definitely looking for the next great opportunity. Anyone who wants a multitalented developer and doesn't care how old I am, email is in my profile. :-)




Hey Mike!

As the guy in charge of the DC office (and the google side of this at the time) - I happily would have hired you if I had headcount :-)

You did an amazing job.

(in fact, i specifically asked for HC intending to try to hire you a number of times, but at that point, the politics of getting resources in remote offices sucked)


Hi Dan! Wow, so nice to hear from you, and thank you for the kind words. It was really great to work with you and Chetan and the rest of the gang!


> But I didn't even apply. Perhaps this was a mistake on my part. I just had a feeling that my history of developing successful products for Google wouldn't count for much - that instead I'd get logic puzzles, quizzes about algorithmic minutiae and have to code a red-black tree on the spot on a whiteboard - all things that favor recent CS grads.

Yes that seems to be how it works. https://twitter.com/mxcl/status/608682016205344768

"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."

My interview process with Google only made it to the technical phone screening because I didn't know the Big O complexity of read/write/sort for Trie structures. (https://en.wikipedia.org/wiki/Trie) The interviewer was pretty cool and we had an interesting technical discussion, so I wouldn't consider it a complete waste of time.


i wouldn't expect someone to know how to derive big-o bounds, I'm 45, an engineer at google and I couldn't do it if asked on the spot. I would however expect you to know of the basic asymptotic performance of typical data structures and algorithms. As a practical matter I've seen a number of critical bugs in software because of mistakes in choosing data structures.

As a side note, I joined Google at age 39.


[flagged]


> Inflated opinion of own importance

Given that he develops software that Google engineers use frequently, I wouldn't exactly say he is inflating his sense of importance.

It sounds like he is a good software developer who has developed something widely used and appreciated, but the Google hiring script doesn't deal well with those kind of people.

It takes a lot of time and effort to go through interviews, I don't blame the guy for being pissed off that Google wasted his time.


Just because a piece of software is frequently used doesn't mean the engineer that wrote it is top of the field.

Calculator is a pretty widely used app, too, even by Google engineers. But that hardly qualifies the author to work at Google.

Similarly while Homebrew is widely used and fits a need, it doesn't mean that the author is equipped with the skills that Google wants. A package manager and something like Google Brain don't exactly share much in common. It doesn't mean Google's script failed nor does it mean he shouldn't be pissed off, it's just how things are sometimes.


It was an excellent argument against "inflated opinion of self importance" though. If you write something that's as widely used by developers as homebrew, you've earned that right.

So what if random Googlers could also have written it? They didn't.


I guess I dont think anyone has EVER earned the right to have an "inflated self opinion". Acting like a jerk, being entitled and demanding things are never something earns. That's just not ok behavior.

I talk to people about interview stuff, I notice that most people who say "I shouldn't have to know X" seem to be the least intellectually curious, least great problem solvers and just generally combative folks. If you are going into an interview with a serious chip on your shoulder, demanding a job, asking to exempt yourself from having to show problem solving skills, then just how is that going to work out?

Regarding reversing a binary tree, yeah, the interviewer didn't expect you to know it. That's the point. It's something that's a little tricky, not impossible, requires you to be precise about memory ownership and pointers, and algorithmic. It takes no time at all to describe, and isn't impossible to solve. Yeah it's problem solving, but it's not random trivia. It's a functional test of your intelligence and yeah it filters out some who should be at Google, and they know it. However relaxing the bar is fraught with peril. You're quite literally banking the future of the company on it.


You shouldn't have an inflated self opinion. (Duh!) But those were the words used to describe mxcl just because he opinionated that Google ought to have given him a more serious consideration given the software he had already produced.

It's my opinion that wasn't an unreasonable assessment (from mxcl). Although if indeed nearly nobody at Google uses Homebrew, as now multiple people are claiming, it was, no matter how reasonable, wrong.


So here's the thing.. he was given the STANDARD interview that every engineer has to pass. How was that not a serious consideration? How is it fair to his future potential colleagues that he got in "easy"? They need to depend on him and his problem solving abilities.

I think he saw the question, and basically just refused to grapple with it, thinking it was below him, and then the rest pretty much was inevitable.


It would be unfair if there was no reason to believe Google's interview process is flawless. But it isn't.

The rest of your post is speculation.


"It was an excellent argument against "inflated opinion of self importance" though. If you write something that's as widely used by developers as homebrew, you've earned that right."

No, you actually never earn that right. Seriously.

In fact, it's a sign of good engineers that they just view their stuff as stuff, and not "well, i am doing the super important stuff, everyone else is not".

Note that this is different than prioritizing, etc. If you have a bunch of high level engineers in a room, and they don't value each other's work (IE recognize that a lot of stuff is "important", and there stuff is just part of that) because they think the stuff they do is super-important, that's going to go very badly.

At lower levels, pretty much none of it is so important that there is any value to having an inflated opinion of self importance.

The fact that you've achieved adoption does not necessarily make you a good engineer.


"well, i am doing the super important stuff, everyone else is not".

Straw man argument. Nobody stated this.

There's also a difference between thinking that your stuff is super important in isolation versus simply pointing out it's in wide use at a company and hence your previous efforts have in fact been productive and useful for them.


"Straw man argument. Nobody stated this."

This is pretty much exactly his attitude, even if he did not explicitly add the other 3 words.

"in wide use at a company and hence your previous efforts have in fact been productive and useful for them."

Except that assumes it's literally true. It's not, as a downvoted person said :)

It also assumes that him working on it would be useful or productive relative to doing something else. That is also probably a negative.


Just curious - have you ever worked at Google?


"Given that he develops software that Google engineers use frequently, I wouldn't exactly say he is inflating his sense of importance."

Why?

To quote one of the demotivational posters, "just because you are necessary doesn't mean you are important".


So is that, eh, the official Google stance on how they view their (prospective) employees?

https://news.ycombinator.com/item?id=12662182

Cogs in a machine?

https://cdn.shopify.com/s/files/1/0535/6917/products/worthde...


Yeah, that' totally the take-away message from that. Not "it's how i personally view the attitude that because what i did is used by a lot of people, i'm super-important".


> Given that he develops software that Google engineers use frequently, I wouldn't exactly say he is inflating his sense of importance.

He may be important as a person who has developed software used by a variety of people (including many at Google), but that doesn't mean he is someone who ought to be important for Google to employ.


The number of googlers who meaningfully "use" homebrew in the course of their work is probably 4 or another figure similarly close to zero, which should therefore be treated as zero. If it didn't exist and someone needed it, they would write it in a week.

The number of googlers with Macs is not even 90% so this line of argument is just silly.


As an engineer at Google, this comment is correct. Some teams use it, but since most the development happens on Linux desktops, and not Macs, therefore Homebrew is not as commonly used as normal dev shops.

Basically the internal dev environment is already fully complete and works great. It's ultra custom and there are strict rules about bringing in open source code. The AGPL and GPL3 are good, but also one has to be wary about them in a commercial environment.


"@PhilPlckthun it wasn't a joke, I was rejected this morning. But it was a flippant tweet."

But, hey feel free to judge someone for gasp having a sense of humor more complex than a fart joke.


I personally have only had a single phone screen with Google, and for only a data analyst position. It was one of the worst phone screens I've ever endured: antagonistic, unfriendly, and all around miserable. In contrast, phone screens with Amazon and Walmart for analyst and data scientist roles have been stellar, even enjoyable. After the miserable experience with the phone screen I have little interest in applying with them in the future. I've even been an Android and Chrome user for years--a Google diehard fan--but the experience made me consider my allegiance. I was expecting better from Google. They don't have to hire me, but I don't think it's too much to ask to expect to be treated with respect and courtesy.


FWIW - I went through the google process. Even though most of the people were very nice, I agree their interview process is not suited for diversity. I applied for a PM position at the time. I specifically said to the screeners (btw, they reached out me) that I was an enterprise software PM and all the questions related to the consumer side of the house. I told them flat out that i was interested in the GCP team. They said they hire "generalists". It wasn't a good use of time although at least I have first hand exp now. I suspect that's why they are having a tough time getting enterprise customers to use their cloud relative to AWS. I heard a rumor recently that Diane Greene is trying to change the hiring process for GCP in particular. Anyone know anything about that?


that instead I'd get logic puzzles, quizzes about algorithmic minutiae and have to code a red-black tree on the spot on a whiteboard - all things that favor recent CS grads.

This is actually a good point that there might be a strong bias in this towards fresh graduates who in most cases are younger folk.


I've been programming 40 years, turned 66 this year and I'm just as enthralled by computers as I was when I started, still working full-time, and still learning as often as my girl-friend will allow time for.

I was contacted by Google several times but chose not to submit myself to an interview process which I feel is biased in favor of CS graduates and consists of exercises which provide little insight into the most important characteristic of a good software engineer; the ability to understand the nature of a given new domain, the problems to be solved in that domain, and good ways to solve those problems.

I cut my teeth on MIT's Computations Finite and Infinite by Minsky (now out of print), Donald Knuth's three volume classic, and later The Structure and Interpretation of Computer Programs, which, at least, I suppose recent CS graduates are familiar with. And many many books after those.

Over the subsequent decades I have developed many unique algorithms to solve specific problems. Most recently, the past month, I increased performance of a graph database issue by an order of magnitude by creating an abstract representation of the graph connections in RAM. That is not a terribly unique approach but somehow it never occurred to the CS types here that the cause of their performance problems was a failure to understand the fundamental nature of the problem being solved.

If Google's filtering consisted of solving a real-world problem, one requiring some days of research and development, then I'd be happy to go toe-to-toe with recent CS graduates. I know how to use The Google to find related domains, problems, and solutions. After understanding the nature of a problem research is step #1, regardless of whether I think I already know a good solution, it is almost always the case that someone has already solved a similar problem (if not the exact same problem), there is value in understanding the differences.

But I suppose that's not a practical filtering process for a company hiring many engineers and not having the resources to evaluate real solutions to real problems.

Also, side note, approximately 5% of the population do not imagine the same way the other 95% do. Like me they cannot, to varying degrees, actually visualize anything with their eyes closed. I never see anything but black with my eyes closed, when not dreaming. I suspect that this is related to my inability to do whiteboard exercises. I don't visualize, I think.

'nuff said


The best real world problems I encounter at Google take months of learning to fully comprehend. They are not trivial, and have a huge base.

Even a simpler real world problem whereby it takes days of research is not respectful of your time. I've seen people note they can't take a 6 hour time-out of their busy work/home lives to do coding challenges that are popular among startups.

So the balance is in-person interviews. Ones where you have to give difficult problems, ones you haven't seen before and ones that don't take days to explain. This usually means algorithmic, data structures, or mathematical in nature. They have subtleness, depth and complexity. As for 'reverse a string', you'd be surprised how many people who have "programming jobs" who apparently can't do basic programming.

And do I use these skill sat my job here? Yes. All the time. I'll spare you the spiel about "everything's different at scale". Google is a different kind of company that attempts to solve as many problems as possible with CS.

For reference, I work at Google, given interviews here, and passed the interview bar twice. Once at 29 and once at 39. Some of my coworkers are older than me. Many of them have children. Some are younger than me. I see plenty of people in the office with grey hair (I work in the SF office).

I refuse to defend past practices, but I believe the company currently sincerely overall seeks to be the best employer for any age. Small pockets of suck happen, but the internal transfer rules let you switch without your manager's permission. The interview process is known to not be perfect, but that is inevitable for any process - nothing is ever perfect!

However, the interviews do involve whiteboard problem solving. I understand some can't do it, and this is one of the blind spots. I personally love diagrams, and think visually, so it works for me. I also prefer when my colleagues use diagrams as well.


Good points. I do understand that Google has no reason to modify its interview process to accommodate my personal style, but then I'm not really complaining, I just never wasted my time applying.

About diagrams.

I had the whiteboard experience once and will avoid repeating it.

When I get a problem I want to sit back and think about it. The interviewers kept insisting that I draw diagrams, and that interrupted my thought process, they were not impressed.

However that does not mean I am incapable of making diagrams once I've sorted the problem out in my mind. After I've arrived at a proposed problem solution I like to produce a written document with just enough information to convey the problem and the solution approach, together with whatever diagrams, data structures, and pseudocode are required to communicate.

That's how I roll. ymmv :)


Here's the thing... without explaining your thought process, how do you even demonstrate you have one? How do you get depth of understanding? It's via a conversation, over a hard problem. With lots of stops in between.

As a side note, I think there are fundamental limitations to "solve entire problem in mind" - tooling, including written word, pens, pencils, crayons, paper, documents, diagrams, whiteboards, provide methods for expanding your working memory.

One other thing "just enough information" is a phrase that worries me. I've seen a lot of academically written papers that basically "by implications you should know that the resulting answer is X". I'm not sure this is your style or not, but it is one style that personally I believe has no place in the workplace. Convey your ideas clearly, and help your coworkers.


I would be entirely comfortable in an interview explaining my thought processes and if I stumble into a whiteboard interview again I will try to do that. The result couldn't be worse than my previous result.

With regard to your other two points I either wasn't clear or you took my comments too literally. Be that as it may, let me clarify.

I do form my entire impression of the problem and various solutions entirely in my mind, without the aid of external memory. However, and this is important, that evolves out of research. During research I build something like an intuitive understanding of the problem. Along the way I consider possible solutions to the evolving problem, solutions by others or that happen to occur to me. Eventually, usually at night when it's quiet, I have an insight, which often turns out to not be quite right. Rinse and repeat until I have something that seems good. At which point I will sketch out some data structures (as struct or object like things, or simple diagrams) and some pseudo code to operate over the data. If that finds a flaw in my idea I go back for more rinse and repeat cycles.

When I say "just enough information" I mean just enough for any engineer with sufficient experience and background to fully understand the problem and solution. I don't leave anything out, I want feedback and I don't want the feedback to be "huh?". By "sufficient experience and background" I am leaving open the possibility that there might be someone in the group who doesn't quite get it, but to tell the truth most good solutions to most problems turn out to be reasonably simple, simplicity is one of my target criteria. Simple solutions are easier to implement, less likely to have bugs, and if the solution is both simple and good the performance is likely to be at least acceptable as well.

Better? :)


I have what's been coined "aphantasia" too--no mind's eye--and I do fine on whiteboard interviews as a general rule. That suggests to me that it's either not your root cause, or it's one you can work around. Personally speaking, I can still conceptualize code (typically as a semi-physical machine, actually), I just can't "see" it. If you're a successful programmer, I'm sure you have some way you conceptualize algorithms too, even if it's not visual.

The one thing I'll say is that with your background, it's a shame you filtered yourself out. You might not have gotten through the interview process, but if you retained anything significant from what you cut your teeth on you also might have been more successful than you think.


Also, about algorithms, I walk through them a step at a time, keeping track of where things are in my memory. :) Once upon a time I could play an amateur level game of blindfold chess the same way. It never occurred to me that when Walter Browne was playing blindfold chess for money on the beach at Santa Monica before the 1976 US Open, with money and time odds 5:1, that he could actually see the board. I'm less impressed now, but was nowhere near his level anyway even if I could see the board.


Your memory is better than mine. I work from an abstract level downwards in a "how would a machine that does this thing work" sort of way, decomposing the machine into parts as I go. Interesting how different people have different approaches.


What you say about white board exercises is interesting. Maybe I just don't like them. :)


on a related note

http://nautil.us/blog/why-blind-people-are-better-at-math

It seems that I'm better at doing math in my head than most people. I've wondered whether that might be related to aphantasia.


That is interesting. I'm pretty excellent at math concepts in general (750 SATs in math once upon a time) but can't do arithmetic in my head to save my life. It wouldn't surprise me at all if there's a relationship there, especially for processes like multiplication or long division where you have to hold an intermediate result.




Applications are open for YC Summer 2021

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: