Hacker News new | comments | show | ask | jobs | submit login
Tripling an Engineering Team in Six Months: Setting Up for Success (zacsky.com)
71 points by zacsky 72 days ago | hide | past | web | 44 comments | favorite



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...


> I had the budget to give them a top of the market rate. I didn't need the 10x developer just smart .Net developers.

As "just a smart developer" how I read this line:

"I don't need a Ferrari, a Porsche would do, and I'm willing to pay Honda Accord prices for one"


You missed the part about

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.


The very very rough conversion for normal 1099 contracting is adding the K's worth of zeros to the hourly rate, eg. $85/hr ~= $85K salary.

Apparently with a W2 this number is net whatever the agency skims while covering some things; not sure how that stacks up.


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.


No, double the hourly rate plus zeros.

40 hours x 50 weeks = 2000 hours

So just 2x and thousands.


Here's examples on HN of others using the rule of thumb I shared, which is definitely conservative:

https://news.ycombinator.com/item?id=2185782 (Feb 2011)

> zipdog: $40/hr contract is about $40k/yr permanent

https://news.ycombinator.com/item?id=2438980 (Apr 2011)

> 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.

https://news.ycombinator.com/item?id=5299009 (May 2013)

> artumi-richard: The rule of thumb I was told is 1000 billed hours per year.

--

To try to be genuinely helpful: a discussion documenting that hourly rates are a bad idea vs. charging per day:

https://news.ycombinator.com/item?id=5714930 (May 2013)

> gknoy: If you're doing freelance, you also have to cover downtime, business development, benefits

Here's the article since the discussion's link 404's:

https://web.archive.org/web/20161210162901/https://alanholli...

> Charge More:

> · Take the salary you’d want to earn as a full time employee.

> · Double it.

> · Divide your doubled salary by the amount of days you’d work as a regular employee.

> · This is the minimum rate you should charge per day.

And this seemed helpful too (mostly connecting for my own future reference at this point):

Poll: long-term contractors, what is your hourly rate? | https://news.ycombinator.com/item?id=5769348 (May 2013)


Depends what you’re trying to calculate.

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.


How is it possible to fail fizzbuzz? I don't understand. Just read about it on your link. Is there some trick I'm missing?


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.

It kinda makes me doubt it as a screening tool.


Thank you for sharing.

How can one administer fizzbuzz over the phone?


In a Google doc. While you may say a Google doc is a suboptimal environment for coding, it was literally fizzbuzz.


Just do it in Python:

import fizzbuzz

fizzbuzz()


If someone did that, I'm not sure whether I would give them brownie points for not reinventing the wheel or demerits for being a smart ass.



Thank you. This is incredible.


I can't think of (m)any situations where tripling the size of a dev team in 6 months makes sense. Did it here?


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.


That is a good question!

It made sense from the perspective that the product we were building was good but a little 'behind' our competitors and we needed to catch up.

The scaling has allowed us to tackle new projects that utilise the underlying platform that we would have otherwise not been able to even consider.


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.


I can think of one - you're a single product company that wants to add a couple of new products without slowing down your current pace.


some companies seems to do it before IPO/acquisition. Of course sustaining such an inflated company post-event is another story.

In the title story :

>In 2016 we were acquired through a private investment consortium and given an injection of funding in order to 'go faster'.

I'd not be surprised if the consortium would sell them for a nice profit soon. Would look like a typical private equity operation.


... 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.


I skipped ahead to the 5th installment - how do you know if a hire was successful past the first month of employment?


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.


I enjoyed all 5 parts of this in depth series.

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.


Why no stock options did you increase the salary to account for this difference?


Does tripling mean going from 1 to 3 or from 100 to 300? I even skimmed the article quickly but didn't see any reference to the scale here.


"40-50 over a few months"




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: