Live data from Hacker News

Why I Don’t Work At Google

sarahmei.com

41–50 of 76 posts

Re: Why I Don’t Work At Google

#42
post #7

Can't you ask questions about the team during the interview, to gauge whether they get things done or not?

Google hiring is done at a company level, so for most hires, you don't actually know what team you'll be working on during the interview. You are typically given some idea at offer time (I was told my manager's name, my manager's manager's name, and the department), and you can talk to people you might know at the company, but if you're remote or don't know many Googlers it can be tough to get more information. It's…

Strangely enough, I just turned down a job offer from Google today, for a complex variety of reasons. Mainly, though, I had a choice between a promotion at my current company, where I know exactly what I'm getting into, and a job at Google, which is a giant black box from the outside with a promise that they'll find you something you will want to work on. (I had two other job offers as well in fact, so it wasn't just those two choices)

Probably the hardest decision I've ever made. I'm sure I would have been happy with any of the offers, but I feel like I might as well take up my employer's offer and see how things go for the next year or two (also they offered more salary than Google did but the bonuses aren't multiplied like they are at Google).

Re: Why I Don’t Work At Google

#43
I'd say the ultimate proof of being both talented and effective is being part of a talent acquisition where the acquired team's product can be fully evaluated.

The fact that Google does many such acquisitions is, to me, conclusive evidence that they do value both of these traits.

But no, maybe not so much in the hiring process, because it's difficult and error-prone enough just to determine potential effectiveness.

Re: Why I Don’t Work At Google

#44

Earlier quoted context omitted.

Google hiring is done at a company level, so for most hires, you don't actually know what team you'll be working on during the interview. You are typically given some idea at offer time (I was told my manager's name, my manager's manager's name, and the department), and you can talk to people you might know at the company, but if you're remote or don't know many Googlers it can be tough to get more information. It's…

I've heard that a new employee can expect his or her first project to last about 12-18 months - can you confirm or deny this?

It depends a lot on what your particular project is, but 3-6 months seems much more typical to me. Mine lasted exactly 4 months from the day I joined to the day we launched...I was joining an already-existing project that was fairly far along, though.

It often takes 12-18 months before you have a good enough understanding of the company and your own desires to figure out where you want to be. (And often more - I know people who joined in 2007 who are just now working through this.) But that time isn't all spent on one project: typically you'll work through a bunch of them, all in the same focus area. I think this is more akin to the normal process of discovery that most young people go through, though, and not something specific to Google.

Re: Why I Don’t Work At Google

#45
post #36
post #21

Earlier quoted context omitted.

I would say that interviewing for engineering knowledge (coding, algorithms, software engineering) is pretty straight forward, but interviewing to figure out if a candiate can get 'real' work done is very difficult. I don't know of any magic way of testing for that. There are some good signals, of course, such as: 1) pre-interview open source reputation and release. 2) References from people you trust and respect. 3)…

There is a way to test to see if someone can get stuff done, but that usually entails hiring someone for a predetermined time (6 mos, a year, 2 years) and then evaluating whether they meet your standards at the end of that time period. If they do, they stay on. If someone really wants to work for your organization, I can guarantee that they'll do everything in their power to get stuff done during this time period.

Oh, sure, but some of the best people won't work on a contract basis.

Re: Why I Don’t Work At Google

#46

This seems to paint the world in overly broad brush strokes. There are good teams, and there are bad teams, and there's bound to be a bunch of both in any organization. You have the same problem with startups: there are good ones and bad ones, and it's usually not possible to tell one from the other until you join them. Why not just try, see what you get, and then you can transfer or quit if you end up on a bad team?…

I agree. It seems as if she's taking whatever she's experienced in Microsoft (which is one company) and applying that to any other company with multidisciplinary teams and a large bureaucratic layer. She should, at least, give working in Google a chance (maybe a couple years or so?) before writing something like this.

Not to mention she's focusing on one experience within Microsoft. Its a big company and not every team is like that but the blog post would lead you to believe that every team is.

Re: Why I Don’t Work At Google

#47
She does have a good point; I've always found that people that like those mindgames are never really very good at programming. Something about wanting to find the right answer to a specific question seems to conflict to finding an answer to a vague set of requirements, programming.

A better interview question might be "draw a picture of anything that comes to mind".

Re: Why I Don’t Work At Google

#48
post #20

I think the correct title would have been - "Why I won't work at Microsoft, again.". I don't think it's a valid argument against Google without having any data-points. I've seen many Startups also don't finish their features/products and throw away when they realize this is not the right thing to do. Overall, don't generalize too much. Experiences are different for different people at different places.

Google and Microsoft both do a great job shipping certain kinds of products. The teams that work on these products have influence, autonomy and ability (without middle management or PM interference) to ship products. For Microsoft it's Office tools, development tools and operating systems. We may not like those products, nor wish to work on those teams irrespective (I'm a UNIX hacker, there's no way I'd be happy at M…

I can't give details, but in my experience your view of Microsoft is incorrect.

If anything, the converse is true: core business teams offer less opportunity to do something great, because they're bigger and less flexible.

I didn't choose Microsoft, but I had an overly simplistic view of things.

Re: Why I Don’t Work At Google

#49
post #10

Have you considered Fogcreek? "Smart and gets things done" seems to be a strong theme throughout the company.

As long as you don't mind working on boring software. (I mean, I know Joel is everyone's nerd idol and everything, but really: bug tracking software? Version control? That's all you got?)

Disclaimer: My FC internship starts on Tuesday, so I can't promise complete impartiality.

I had the chance to contribute to Chromium as part of a class project. It was super bitching. I got to communicate and ever have discussions (virtually) with some brilliant google guys and put some code in. Even got my name on the AUTHORS list.

My biggest contribution was changing the way they did metahandles in sync. You see, when a 'synced' bookmark item is updated in a transaction, it must be marked 'dirty' so that it can be pushed to the server when the cycle comes around again. This was an O(n) operation, as they scanned the whole set of metahandles to do this. I just added some things to the WriteTransaction class to add it to a much shorter list and spare the effort of the whole scan at the end.

Now, I haven't worked at Fog Creek yet, but I have (coincidentally) built a bug tracker before (high school internship; I have no idea why I was given that task, in retrospect). Granted, I was a high school student so I did an awful job with it, but I did learn a lot about how to make software (I'd hope) and it was pretty cool. One thing in particular comes to mind which is that I had to add multiple-parameter sorting, and so I figured out how to do that (I had no idea libraries and even successive merge sorts would accomplish the same thing) and they were happy with what I made.

I guess my point is that a feature is a feature is a feature. Most of the REALLY boring stuff is present in ANY software project, and a lot of the REALLY interesting stuff is present in almost anything (COBOL and banking applications aside).

(Chubby, BigTable, etc are super sweet though)

Re: Why I Don’t Work At Google

#50
post #11
post #4

I'm waiting for the part where she explains why she doesn't work at Google.

I believe because the publicly available reports of their interview process don't seem to emphasize "getting stuff done" as much as she prefers, but instead emphasize other attributes. She believes that if it's not emphasized in the interview process, it's likely to be underemphasized in the organization as a whole. Since she believes that attribute to be more important than its proportion of apparent emphasis, the p…

There's a joke on the old saying: if it walks like a duck, and talks like a duck, don't be deceived, it is a duck. Smart people have a tendency to overcomplicate things and be so suspicious of "superficial" indicators. The assumption is that it really can't be so simple, you can't make snap judgments based on how they run interviews, you need to do some sophisticated analysis or something to really know. They end up being deceived by not wanting to be tripped up by naive conclusions and trying to look deeply, so they miss what's staring them in the face.
Post reply on HN