71–80 of 86 posts
That must be the most depressing thing I read in quite a while.
This is the kind of thing I had to deal with at Stanford. Same "rainbows and unicorns" outward appearance, but...
That must be the most depressing thing I read in quite a while.
Agreed... it's supposedly one of the few remaining companies that actually respect engineers, but this post pretty much comes out and says otherwise in bold, flashing letters. "(Exception: War-room firefighting. Google loves those, and loves heroic performances from people in war-rooms)" The whole "war room" concept in IT has always bothered me -- it's what managers do when they have a crisis that they don't know how…
I'd look at it more as a cyclical thing than as a "dying breed". Google itself, after all, is barely more than 10 years old... New ones will come and go.
Earlier quoted context omitted.
Google is still handing out million dollar awards. For many people, the low risk but potentially high reward setup is ideal. For instance, getting the big Android founder's award probably beat being the 10th employee at Aardvark.
Only if you're Andy Rubin. When I look at the dollar amount of some of the largest-ever Founders Awards and then see how many people they're split between, I can't imagine that the payout is anywhere close to even an employee's payout for an acquisition. I dunno how the Founders Awards are divided up, but I'd imagine that it's a skew distribution, with most of it going to the initiators and key early team members of…
Google can and does hand out big bonuses. There's so much cash flowing through the company that a little sprinkle of it (by Google's standards) is still a lot of money. If you're one of the fast-tracked folks at Google, there is no reason to join a startup just for the money.
Earlier quoted context omitted.
Agreed... it's supposedly one of the few remaining companies that actually respect engineers, but this post pretty much comes out and says otherwise in bold, flashing letters. "(Exception: War-room firefighting. Google loves those, and loves heroic performances from people in war-rooms)" The whole "war room" concept in IT has always bothered me -- it's what managers do when they have a crisis that they don't know how…
Given Google's attitude towards perpetual betas, I'm curious if their "war rooms" are more to solve immediate problems (show-stopping bugs, security issues, etc) rather than attempts to "fix" late projects.
The problem is that they usually use the same approach without the phrase "war room" to create the original product, which lead to the problem they're now trying to solve in the first place.
Earlier quoted context omitted.
What's a war room? Google, ironically, was of no help.
Get everyone who's working on a big problem together in one room. It raises the question: if this works, why not do it all the time?
Earlier quoted context omitted.
Get everyone who's working on a big problem together in one room. It raises the question: if this works, why not do it all the time?
...which is basically what Google (and several other software companies) does . That's why I say that some people simply call it "development".
Which to me meant, "You use Agile(tm) methods when your project has already failed."
Earlier quoted context omitted.
It doesn't seem that the post paints Google as being disrespectful to engineers. If it is unfriendly to engineers, then it is unfriendly to everyone. Some points here: The key point that starts off #1 is more or less a side effect of any company where you hire folks who have a need for stability in their life. The unpredictability that he refers to is little different than how startups need to pivot. The only differe…
Good points. I don't think interiews ever became hazing rituals. What happened instead was that a lot of folks got burned out on interviewing, and because interviewing was never taken seriously as a priority, interview training was outsourced to an outsider. That led to a number of travesties.
Like the one I had for my Google phone interview earlier this year... when he asked me to code up a simple sorting implementation (an array with an empty slot, and you can't use extra memory) the FIRST thing I described was a swap method that took the two indexes to swap, as well as the index for the blank. (I also at that point mentioned saving the location of the index in order to avoid having to scan for it for every swap). Two minutes later when I said we would simply swap two items, he asked me how, and I ended up describing the swap function AGAIN. And he also didn't understand the part about remembering the location of the blank, he brought it up in the performance analysis -- even though I'd mentioned saving it in a class variable already, I had to explain it yet again.
I didn't get a call back and I didn't expect one, but I was sorely disappointed with the quality of the interviewer, so I can't say that not getting a call back was much of a disappointment after that.
I love the ending line: > Finally, if you get fed up of working for a big company, consider joining a startup. This one posting probably did more damage to google hiring from the HN ranks than all the others that I've seen to date. With friends like that who needs enemies.
Actually I found myself thinking "that's not so bad..."
Earlier quoted context omitted.
Get everyone who's working on a big problem together in one room. It raises the question: if this works, why not do it all the time?
It usually also means that the people in the war room are only working on that problem, and that they are working extremely long hours.