3 ms·

The problem with the article is that it misses the big point.. Google is attempting to save some costs in hiring at the high levels of coding engineers..with a

by shareme 16y ago

The problem with the article is that it misses the big point.. Google is attempting to save some costs in hiring at the high levels of coding engineers..with a comparison of that costs per employee against the cost to offer a 20% raise is somewhat a miss-leading and pointless article..or what we call link-bait. And some of the Hr hiring costs per employee can be determine from the Google SEC filings..by making some assumptions and completing some calculations.. And on top of that most high end Google engineer hires and this has been in fact talked about only become fully productive at 12 to 18 months after joining Google.. So lets do the calculations that MA of Tc should have been somewhat curious to do.. $120,000 salary per year times 80% non-productive first 12 months..learning the Google engineering system etc.. $96,000 in loss productivity costs now ad Hr department costs of interviewing and etc.. $20,000..my guess..only guess. so now we are up to a subtotal of $116,000.. and $120,000 times 20% is..$24,000 Change the salary to say $400,000 still similar differences in costs of the two decisions..with Google wining out on their own cost decision..

jasonkester 16y ago
Where do you get your 80% non-productive number? Every job I've had in the last 10 years, I've delivered production code on day one. I expect that anybody good enough to get hired at Google would be capable of the same. I mean sure, we've all hired our share of useless junior devs, but then we've all done that at places that were a notch or two below Google on the minimum-standards front. For talented developers with experience, I could see losing a few percentage points of your max speed during the first week while you get used to process, but do you really think you can stumble along at 20% of your capability for an entire year and not be noticed? At a top-tier software company???
- ovi256 16y ago
  >Every job I've had in the last 10 years, I've delivered production code on day one. We all did, but it's not enough. You probably took time away from other engineers to coach you and explain the system. If you took more time than it would have took them to accomplish what you did, you're not productive. And his point is that's what you did.
  - jasonkester 16y ago
    Perhaps I wasn't clear, so I'll restate what I was saying. One day one, of the last half dozen jobs I've taken, I've been handed a project and told to run with it. And I ran. Without any assistance from anybody except a couple quick chats with whoever's in charge over the course of the project, and QA when it was ready to push. No hand holding, no coaching, no taking up anybody's time asking silly questions. You just figure things out for yourself and get up to speed. Inside of a few hours. That's how you work if you're good, and I can't imagine anybody getting in the door at a shop like Google that couldn't. The type of drain you describe is what happens when you bring a junior dev onto a team. It's a lot less when you bring in more senior people, and by the time you get to the big leages it's pretty much just background noise. That's why I questioned the great-grandparent's "20% throughput for an entire year" number. My guess, based on experience, would be closer to 100% throughput, given an entire year to absorb the first few days.
- semuelf 16y ago
  yes

by shareme 16y ago

jasonkester 16y ago

Where do you get your 80% non-productive number? Every job I've had in the last 10 years, I've delivered production code on day one. I expect that anybody good enough to get hired at Google would be capable of the same. I mean sure, we've all hired our share of useless junior devs, but then we've all done that at places that were a notch or two below Google on the minimum-standards front. For talented developers with experience, I could see losing a few percentage points of your max speed during the first week while you get used to process, but do you really think you can stumble along at 20% of your capability for an entire year and not be noticed? At a top-tier software company???

ovi256 16y ago
>Every job I've had in the last 10 years, I've delivered production code on day one. We all did, but it's not enough. You probably took time away from other engineers to coach you and explain the system. If you took more time than it would have took them to accomplish what you did, you're not productive. And his point is that's what you did.
- jasonkester 16y ago
  Perhaps I wasn't clear, so I'll restate what I was saying. One day one, of the last half dozen jobs I've taken, I've been handed a project and told to run with it. And I ran. Without any assistance from anybody except a couple quick chats with whoever's in charge over the course of the project, and QA when it was ready to push. No hand holding, no coaching, no taking up anybody's time asking silly questions. You just figure things out for yourself and get up to speed. Inside of a few hours. That's how you work if you're good, and I can't imagine anybody getting in the door at a shop like Google that couldn't. The type of drain you describe is what happens when you bring a junior dev onto a team. It's a lot less when you bring in more senior people, and by the time you get to the big leages it's pretty much just background noise. That's why I questioned the great-grandparent's "20% throughput for an entire year" number. My guess, based on experience, would be closer to 100% throughput, given an entire year to absorb the first few days.
semuelf 16y ago
yes