Inside the War For Top Developer Talent 238
snydeq writes "With eight qualified candidates for every 10 openings, today's talented developers have their pick of perks, career paths, and more, InfoWorld reports in its inside look at some of the startups and development firms fueling the hottest market for coding talent the tech industry has ever seen. 'Every candidate we look at these days has an offer from at least one of the following companies: Google, Facebook, Twitter, Square, Pinterest, or Palantir,' says Box's Sam Schillace. 'If you want to play at a high level and recruit the best engineers, every single piece matters. You need to have a good story, compensate fairly, engage directly, and have a good culture they want to come work with. You need to make some kind of human connection. You have to do all of it, and you have to do all of it pretty well. Because everyone else is doing it pretty well.'"
Re: Top talent is always hard to find (Score:5, Informative)
The way Google evaluates talent is pretty bad, and it's not an interesting company to work at unless all you're interested in is a stable income with lots of perks.
Stable income, lots of perks... yep that's terrible :-)
Actually, you forgot my favorite feature of working for Google: A complete lack of idiots. Everyone I work with -- right down to the facilities staff, amazingly enough -- is bright, focused, engaged and rational. In three years, working with hundreds of others (Google is highly collaborative), I found a single counterexample, and he's now gone.
They heavily suffer from NIH syndrome and are convinced that the technology they created (and they created software for pretty much anything) is the best in the world, even when it's painfully outdated.
NIH syndrome... maybe a little, but less than it might appear. It's absolutely true that pretty much all of the Google infrastructure is home-grown. Partly that's NIH, but I think mostly it's because there's fairly little software out there that can function at Google's scale. And even where there are now publicly-available tools that can do the job, they didn't exist when Google created its stuff, and it doesn't make sense to switch.
Frankly, Google does have some pretty amazing tools, and I'm no wet-behind-the-ears pup who never saw what was in the world before joining Google, either; I had over 20 years as a professional software engineer when I started working for them. I went in expecting to roll my eyes regularly at all of the homegrown code that they could have just bought -- but frankly I don't see it much.
I do see a fair number of places that an industrial RDBMS like Oracle or DB/2, could be used and that would be faster for transactional applications than bigtable et al, and more reliable and easier to manage than massively-sharded MySQL (Google uses a lot of massively-sharded MySQL). But I can also see that using a COTS RDBMS would reduce agility and might be hard to integrate into the rest of the infrastructure -- and might run into scalability problems. Google's own stuff runs into scalability limitations, but at least we can fix it.
Outside of that... for dev tools Google uses pretty much the standard open source suite. For massive-scale process management, there just isn't anything out there to compete with borg, or the rest of Google's cluster management suite. I interviewed with a company that builds somewhat similar software, and so did some research on that space... and there's just nothing remotely like borg. Dremel, Borgmon/Monarch, Critique... same story.
For version control, Google uses Perforce, a commercial product, and about the only thing out there that could handle a multi-terabyte codebase which receives thousands of commits per day -- how many code repositories measure their performance in commits per second? However, I understand that Google has had to customize it extensively.
So, on NIH... not so much. Google engineers rarely look outside the company for stuff, but it's because they rarely need to, and if they do need something that none of the available tools can handle, there is rarely anything outside that could work.
To get hired, you have to use the Google way of doing things to solve problems.
Not sure what you're talking about there. To get hired you have to solve some pretty standard types of CS problems.
Re:Time for devs to get to work then! (Score:3, Informative)
Wow, so much vitrol, so much lack of understanding.
It's okay to be ignorant. Lots of devs are, even ones that have been in the industry for a good long while.
Letsee ....
1) Contracting companies make money off you
Yes, but that's just sour grapes - if you accepted the contract at the rates and benefits given, then, you accepted it.
2) They're charging x% more than you're making! You should be making that much ...
You sound like someone who's never done independent contracting before. First, how are you going to get in the door to bid yourself out for these contracts? Are you going to go through their agency vetting? Provide your own worker's insurance (ensures your contract will be completed if you're unable to)? Provide a history that shows more than a single competent individual with a single set of skills? Don't forget providing your own medical insurance. I've had to do this before for myself; for a job that I'd normally peg in the 80$/hr range, in order for me to be profitable, it'd need to be in the 200-300$/hr range. and see item 3 below
3) You weren't going to get that job by yourself anyway.
When it comes to devs, it's rarely a choice between contract or perm for the same position. It's one or the other.
First, perm employees are - to the company - almost always more expensive than contractors, even given an invisible markup that goes to the contracting company. The cost of onboarding is high, benefits are high, it's all very expensive, more so than the contract cost.
Next, contractors are easier to get rid of, just cancel the contract - so if you don't work out, it's painless to excise you. It's much harder to get rid of employees. There's unemployment, there's a higher potential for lawsuits, there's morale problems, etc.
Additionally, many big companies use contractors as budget stuffing. You might not know this if you're outside of management, but in many places, coming in under budget is bad - it means your next year's budget will be reduced. One way to avoid this is to use your discretionary budget to hire contractors. They're effectively uncashed checks - you can cash them any time you need to, or just wait out the year and let them soak the remaining budget.
A counterpoint to the above issue, many small companies use contractors because they cannot afford to compete in the HR/recruitment space on their own. Many shops specialize in software design, and they don't have a separate department to vet and sort thousands of applications, much less maintain social presence on career sites and such required to snag good employees. They rely on contract agencies and rarely even post their positions publicly. Most contract companies even give discounts when you mark them as a sole provider, so it's the best way to get good candidates without spending your lead engineer's time.
Last, since these budgets are almost always separate from a fixed budget to be used purely for headcount, it can be used to hire additional personnel when you're not allowed to otherwise.
All in all though, it means most of the jobs going to contractors are not ~ever~ going to perm employees, and vice versa.
4) Recruiter cares if you sent them a nice email?
Yes, they do. Their livelihood depends on placing candidates. For them, it's mostly statistics; throw enough candidates at a job, a certain % will stick. How do they hedge their bets? They find _good_ candidates, and they keep in touch with them. Some of that is social - just a willingness to communicate with them is a better risk than someone who never responds. It pays for them - literally - to keep in touch, to maintain that relationship. So they make special notes of the nice ones, of the successful ones, the ones that interact with them, that agree to go to lunch with them - of the ones that can help them bring in a payday. Especially in that environment, they're very used to monet