Tech Companies, New and Old, Clamor to Entice Cloud Computing Experts(nytimes.com)
nytimes.com
Tech Companies, New and Old, Clamor to Entice Cloud Computing Experts
http://www.nytimes.com/2016/03/07/technology/tech-companies-new-and-old-clamor-to-entice-cloud-computing-experts.html
7 comments
I’ve lost track of this metaphor.
I am skeptical about these 1 million dollar paychecks. Take LinkedIn for example. With the recent reduction in their share price, is a mid-level engineer really making 300K to a million? I doubt this.
I know a $300k paycheck at Netflix wouldn't be very unusual for highly skilled cloud engineers.
Is that some aggregate estimated "total compensation" figure or are they making $300K in real money? That sounds very, very high for what I have seen.
Netflix is known to be at the high end of salary as base pay. You can see the numbers yourself by looking at H1B petitions. I see many software engineers above $300k [1]. I don't think it's the norm in the valley, but for someone highly skilled it's attainable.
[1] http://h1bdata.info/index.php?em=Netflix&job=SENIOR+SOFTWARE...
[1] http://h1bdata.info/index.php?em=Netflix&job=SENIOR+SOFTWARE...
Agreed. Netflix is known to be an outlier. My understanding is that it is also a relatively high stress place to work.
Having met a number of Netflix employees (and knowing one extremely well), I don't think this is actually true. YMMV.
The high stress part or that their employees are generally near the top of the game?
Interesting. Thanks for the data. I wouldn't want to work there myself, but it's good to keep an eye on what the market's doing.
Well, I missed the cloud boat, so it's no wonder I can't be employed in this market.
Throw away this type of thinking and start renewing your mind. Understand that the cloud is as much about thinking different as is it is about items on a resume or hosts in a datacenter.
Take a project you've done and start figuring out what it would take to do it at 100x the traffic. Now figure out what it would take to make each of the instances stateless. Lastly, how can you make it work through network partitions, latency, and eventual consistency?
These are real problems people in the "cloud" are working with. Just being able to talk about these types of problems excitedly says a lot about where an engineer fits.
Take a project you've done and start figuring out what it would take to do it at 100x the traffic. Now figure out what it would take to make each of the instances stateless. Lastly, how can you make it work through network partitions, latency, and eventual consistency?
These are real problems people in the "cloud" are working with. Just being able to talk about these types of problems excitedly says a lot about where an engineer fits.
People say things like that right up until it comes time to pull the trigger on a hiring decision. Then it is "you don't have the kind of background we're looking for. Best of luck in your job search."
More important than knowing how to do the above is knowing when, and not doing so needlessly.
This is more about people who have the skills to build the cloud. Just being a user of those systems is much different, and should actually be fairly accessible to most developers. Just go start up a free personal account on AWS and set up a simple website. Voila you're using the cloud!
> Many of them are the kind of jobs that now pay $300,000 to $1 million a year
yeah, but you have to work for Oracle.
yeah, but you have to work for Oracle.
Where's South Park?
edit: oh, next to South Beach, never mind.
edit: oh, next to South Beach, never mind.
What skills exactly needed here?
Cloud Computing experts could apply to a lot. But if any anecdotal evidence from friends is accurate, you basically need to understand how to build massively distributed highly reliable systems and that's a rather unique skill set. It's because not a lot of places actually require those skills.
Most companies mess around with tools or distributed storage systems because it's fun, not because they actually need to do it. Debugging live systems at scale is another bit of black magic. If you basically know what Brendan Gregg does then you could probably qualify for these types of jobs.
http://www.brendangregg.com/
Most companies mess around with tools or distributed storage systems because it's fun, not because they actually need to do it. Debugging live systems at scale is another bit of black magic. If you basically know what Brendan Gregg does then you could probably qualify for these types of jobs.
http://www.brendangregg.com/
I think the biggest thing is that you can't get "real" cloud/systems/devops/whatever experience on your own, unless you manage to build something that attracts the kind of traffic that you'd see once you're managing instances for a mature product.
Exactly right. I love doing that kind of thing but it's hard to find an environment in which I can practice those skills. Loads of reading and simulation, very little time at-bat. That's too bad, because that's the kind of work that makes me truly happy.
there is so much here it's hard to know where to get started.
probably:
1. strong fundamentals of L2/L3 networking 2. software defined networking state of the art 3. linux and windows virtualization state of the art 4. distributed storage state of the art 5. familiarity with commodity 64 bit hardware of all varieties (supermicro, dell, hp, etc.) 6. kernel debugging skills (maybe not development) 7. networking debugging skills @ the packet level 8. strong understanding of http and proxying 9. strong understanding of load balancing 10. strong understanding of wide area networks 11. physical datacenter knowledge i.e. how to actually install shit and get it to work together. 12. power fundamentals
for example, solve this problem:
we have a datacenter in oregon and a datacenter in virginia. connect them physically and logically. know what the goals are, know who to call, what to ask for/buy, and how to debug it.
1. strong fundamentals of L2/L3 networking 2. software defined networking state of the art 3. linux and windows virtualization state of the art 4. distributed storage state of the art 5. familiarity with commodity 64 bit hardware of all varieties (supermicro, dell, hp, etc.) 6. kernel debugging skills (maybe not development) 7. networking debugging skills @ the packet level 8. strong understanding of http and proxying 9. strong understanding of load balancing 10. strong understanding of wide area networks 11. physical datacenter knowledge i.e. how to actually install shit and get it to work together. 12. power fundamentals
for example, solve this problem:
we have a datacenter in oregon and a datacenter in virginia. connect them physically and logically. know what the goals are, know who to call, what to ask for/buy, and how to debug it.
I'd also add:
1. Formal specifications. Complex distributed algorithms are too difficult to understand without exhaustively checking a design for all possible executions that end in dead-locks or violation of some invariant. Clouds require sometimes complex orchestration between various services. Unit tests aren't going to cover you if your design isn't correct (they'll ensure that some small portion of your system is correct and scale has a funny way of revealing everything you didn't test for).
1. Formal specifications. Complex distributed algorithms are too difficult to understand without exhaustively checking a design for all possible executions that end in dead-locks or violation of some invariant. Clouds require sometimes complex orchestration between various services. Unit tests aren't going to cover you if your design isn't correct (they'll ensure that some small portion of your system is correct and scale has a funny way of revealing everything you didn't test for).
It's implied, but worth stating explicitly: automation of mass server deployments and operations should be on the list.
it was implied in point 3, but yes, and (implied in point 5)... know how to do this for physical servers too. i.e. the machines that are actually doing the computing that everyone thinks is happening 'in the cloud'.
i.e., how do you assembly-line build an entire rack or cage without manually installing any software? it's not easy. in fact it's very hard, probably even the most advanced groups require some manual intervention or at least some manual troubleshooting every once in a while.
i.e., how do you assembly-line build an entire rack or cage without manually installing any software? it's not easy. in fact it's very hard, probably even the most advanced groups require some manual intervention or at least some manual troubleshooting every once in a while.
looks like a hard package to fill.
uh yeah, they don't give away 300k-1M/yr paychecks for nothing.
Cut off everyone else's oxygen? There are maybe 10 companies that hire in volume and are willing to match top tier offers. The companies that aren't willing to match top tier offers could do so by hiring fewer people and paying them better, but they choose not to. Those companies are cutting off their own oxygen.
Some companies are willing to pay more than others, often by 2x or more, and those companies have a lot more options when it comes to hiring. That's how the market works now that the wage suppressing no-poach agreement has been canceled. And frankly, that's how it should work. Companies should be able to go out and pay market rate to get the people they want. And people should be able to take advantage of that.