If he was this successful at hiring, onboarding, and training new devs and getting them up to speed, I must really suck. It took me close to two months and around 14 interviews just to hire four people as contractors - for the right person, I had the budget to give them a top of the market rate. I didn't need the 10x developer just smart .Net developers.
You would be surprised at the number of developers with 10 years of experience who couldn't do what was the equivalent of the FizzBuzz problem. (http://wiki.c2.com/?FizzBuzzTest)
60-70% of the people I interviewed had never done automated testing - I've been teaching them how.
> 60-70% of the people I interviewed had never done automated testing - I've been teaching them how.
That might be a good thing, many think they know and end up with the most obscure, complicated tests imaginable. Massive unit tests, integration tests that don't integrate components, single tests with 50+ asserts, tests with no asserts, tests with no indication what they are testing, I've seen them all.
Ah don't put yourself down. Hiring is super hard and you're supposed to hire slow, fire fast, so perhaps you just did it the right way given your circumstances.
A whole host of factors come in to play too. Timing - was the market just not that full of good devs at the time? Location - you might not have lots of good .Net devs nearby. There's also a healthy amount of luck involved.
We hire .Net divs, and our theory test includes a FizzBuzz and we've seen some interesting results...
for the right person, I had the budget to give them a top of the market rate.
We aren't building self driving cars. At the end of the day we are doing basic CRUD.
By "smart developers", I mean can pick up things fast, they don't have to know everything.
I am a big proponent of the Joel "Smart and Get Things Done" filter when it comes to hiring (https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...). My interviews are far more behavioral than "Describe all of the design patterns in the GoF book and write examples on the whiteboard"
Right, a Honda Accord is a nice car to most people and could be interpreted as top of the market.
Now, if your post said for the right person, I had a budget to give them $150k in Austin, TX then we'd be getting somewhere. "top of the market rate" is just too ambiguous in most experiences.
I know my local market fairly well - it's a major metropolitan area that's not on the west coast . I'm still an in the trenches developer, I just have more team lead responsibility.
Yes "top of the market" is $85 an hour as a W2 contractor. Using my rule of thumb - 1800 hour work year when contracting taking into account unpaid holidays, unpaid vacation and sick time, and gap between employment - that's a base pay rate of $153,000. More often than not, there will be more than 40 hours worth of billable work.
I am fairly aggressive about my contract rate when I am contracting, and I would take that in a heartbeat.
So yeah, all of the contractors that report to me make more than I do. For some strange reason, I'm okay with that.
Whoa, where do you live? I live in a cheap-as-hell nowhere mid-sized Midwestern city and $85 for a contractor's... not top of market. Closer to $125, maybe a bit higher. You might get a discount for a long-term gig, but $85'd be a steep discount. You'd pay even more for someone who has actual skills in a rarely-needed (locally) field or specialty (most of those people move to Colorado or get locked up by a handful of large local companies).
[EDIT] Nevermind, saw your post clarifying/emphasizing the W2 angle down below. That's probably about right, then.
You can't compare contractor pay with salaried pay like that due to lack of benefits, etc. You'd have to lop off like $10k for extra taxes and a bunch for healthcare as well (could easily be $10k+). Maybe you know this, but it wasn't immediately clear since you didn't provide your own salary $.
That's why I specified "W2 contractor". As a W2 contractor (as opposed to a 1099 contractor) you work for an agency and they pay the employment side of SS and Medicare.
Of course if you need to pay for family benefits, that's an extra cost, a lot of the contractors I know are either married and get benefits under their spouse or are single and have a relatively cheap high deductible plan. When you work for an agency, you can buy insurance as their employee.
Ah gotcha. As for finding a lot of seemingly qualified programmers who can't pass fizz buzz, yea idk how you get around that. Fortunately for me I work at a big company and can just not do the first round of interviews if I get fed up with it... but as the only person hiring, ugh.
Let me clarify. The hourly rate I was referring to was what the contractor gets. Not what the agency gets. I tell the recruiter and my manager the offer I think we should make the person and let the higher ups negotiate the bill rates the agency will charge the company. I haven't been second guessed yet.
>
techiferous: But remember that there is non-billable work (accounting, etc.) and a 15.3% self-employment tax. [...] Working as a consultant for $175/hour is similar to being employed at $175K/year.
> danssig: Calling that pay rate $175K/yr is beyond conservative.
NOTE: two users here also recommended your equation
> slashcom: $x/hour * 40 hr/wk * 50 wk/yr = 2n1000
The general rule is always "times 2, add 3 zeros"
>
jurjenh: yes, this is generally the rule I use as well, take the hourly rate and double it and add a K (eg $30/hr = $60K) [...] Personally I use an estimate of about 75% efficiency
> rapind: For 75% efficiency I assume you mean 3/4 * 2 * $175 * 1000 = $262,500 / year.
If the idea is that independent small job (less than a year) contracting results in a 50% loss to overhead, then yes, just take hourly rate in thousands. This helps convince people to stop messing about with self-employment and just work for the man.
If you mean how much money is in your bank account after a year of work for one company, contrasting a 1099 to FTE for a regular company, it’s the 2x + 000s formula. Unlike comments above, if you have your own LLC consulting business and run the 1099 payments through that, you can pay less tax as self-employed taking care of your own insurance and benefits.
I failed fizzbuzz once in a phone interview. I was really nervous. I've since gone on to have a reasonably successful career in software. It can happen.
I nearly fucked up Fizzbuzz on a tech interview once, but managed to pull it out at the end. Later someone told me the guy who interviewed me said it was one of the best interviews he'd ever done.
If you have absolutely runaway traction in a winner-take-all market, then tripling the size of your dev team in 6 months can make a lot of sense.
Facebook, Google, and Uber have all had periods of growth that fast.
For example, Uber's overall employee headcount went from ~2500 at the start of 2015 to ~13,000 at the end of 2016 -- although that includes non-engineering hires.
But for companies that aren't Facebook/Google/Uber? A slower growth rate is almost always the better decision.
I imagine many large projects start out as small experimental ones. Once they get validated you light a fire under them (with money) and expand the team. IIRC Docker started out as a 2 man team - I'd imagine they had a doubling or a tripling that was well justified after that.
... on a 20 year old product. This was not a market-driven need, this was an investor-driven push for profit. It is their company, so their call to make, but it needs to be made clear that this was a calculated risk by the business owners to make money, not a launch strategy for a new product.
In 2016, after being acquired by private investors, we were given the green light to triple our engineering team as fast as possible. In this article (part 3 of a 5 part series) I focus on all the preparations required before starting to hire.
A lot of the things I recommend doing in the first month are just repeatable for the length of their employment. But there is a greater question I think you are asking around how do you know when you made a good hire? That's a big curly question probably worthy of a follow-up post.
Would be nice to have a 6th post about how the engineering team ended up being organized, but all in all a great overview of the goals, techniques and tactics needed to make a big hiring push.
Thanks for your comment. Glad you enjoyed the series.
I did consider a 6th article looking at the longer term outcomes but decided at the time to cut it. Might have to reconsider as there seems to be good interest.
That's the bit I was interested in reading. The level of detail in the hiring process turned out to be really good. The thing that got my attention about the series, though, was "Ooh, I wonder how they handled communication and work distribution among the organisation."
Hiring is the easy part. Rampant scaling of engineers is easy to do, if you're not paying careful attention to quality, or you're dumping cash and or options/RSUs with the promise of riches (case in point: Uber sounds like they overhired and then imploded).
How successful was your hiring? What was the performance ratings of the people that you hired and how many met your expectations and how many didn't? What was the average tenure of those employees after this big hiring spurt? Those are the more interesting pieces of information.
+1. I think rapid scale means you can't take advantage of many of the useful things about organic growth. I.e. assimilating gradually, not sabotaging the chemistry of the existing team, etc.
It also means reliant on cross-cutting resources: "architects", "product managers", etc.
More than anything, it also means a lot of firing and attrition.
If you need 100 to stay > 3 years then hire 200 and expect to lose or fire half within a year. It may sounds ridiculous but it's the cost of scaling.
Quality (for engineering skill AND attitude) was the top focus, salaries were market rate, and there are no options/RSUs involved.
Thanks for the suggestions about the follow up to hiring and measuring success. It seems most of the comments want to know more about this so I will look at a follow-up post.
You would be surprised at the number of developers with 10 years of experience who couldn't do what was the equivalent of the FizzBuzz problem. (http://wiki.c2.com/?FizzBuzzTest)
60-70% of the people I interviewed had never done automated testing - I've been teaching them how.