HN Explorer

NYC Tech and the Compounding Interest of Making a Hire

4 points by tberghane ↗ HN
In 5 years working in NYC Tech, working with 30+ Startups, it's interesting to see all of the different approaches to Tech hiring. Specifically looking at companies so focused on hiring with velocity, yet struggling with something we like to call Recruiting Hygiene.

From what we've seen in the industry at HiveFive, the average Onsite to Hire ratio is about 1:12. That means for every 12 people you are bringing onsite, 1 will be hired. Now think about that for a second:

Let's say there are 4-5 steps to your onsite (5 hours): A Coding Problem, Systems Design, Lunch, CS Fundamentals and a Wrap Up. Each step is a different person (Sometimes companies even have 2-3 interviewers involved for each) If each portion takes an hour, that's a minimum of 55 hours of Engineering time that's being pulled away from doing their core competency to make 1 hire. What happens when your goal for the quarter is 6 or even 10 hires on your team? At 10 hires, you're looking at an astounding 605 hours that Engineering is not doing their core competency. What do you think your organization could get done with an extra 600 hours of Engineering time? Additionally, how can we expect to compete with the major players in a hyper competitive NYC landscape when you are not able to hire efficiently and, in most cases, can't compete on compensation?

If there's one thing I've learned over the past 6 months that has stuck with me, and just makes sense it's this:

You only need to evaluate for 4 things in your process: Do they have the relevant experience? Can they do the job on a daily? The Level of Engineer Culture Fit

From there, you should have a clear cut decision on hire/no hire and the level of Engineer you're bringing on.

Hiring should be thought of as a product (NOT a sales funnel) Hiring is NOT a Democracy and feedback needs to be gathered individually immediately to avoid bias and group think

Agree of Disagree?

12 comments

[ 4.0 ms ] story [ 37.2 ms ] thread
muzani
I think the best way to interview is still the old school way [0].

Just find people who are smart and get things done.

We've had phases after phases of interview "wisdom". At one point people were just hiring for "passion" and picked any girl who has a Github account and was active on it. But this led to lots of people setting up Github account, not to build things, but to make themselves look good on the interview.

Now we have this whole CTCI trend, because big companies do it. And so developers with 10 years of experience spend 3 months memorizing every algorithm in the book, 80% of which they'll never use throughout their career. Does it make for better programmers? Sure. But in past quarters I've had two major speedbumps - CSS animation and setting up mail adapters, and no amount of HackerRank will make me good at that.

The article [0] also mentions "pointer and recursion". I think this is about as far as you have to technically test people. If you needed to code prime numbers from scratch a smart enough person can learn to do sieve in half a day. But pointers and recursion take a little more effort than a day. You might say that nobody uses C anymore, but we still use pointers - there's plenty of variations of binary search, and that's about as deep as it needs to go IMO.

[0] : https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...

[deleted]
(comment deleted)
JSeymourATL
> Hiring should be thought of as a product (NOT a sales funnel)...

Are you hiring Engineers or Day Labor?

The interview process works both ways--

I'm also score-carding you and the organization.

Frankly, immediate job offers often signal desperation.

tberghane
I definitely agree with you here, that's why you have to evaluate correctly in order to execute in a timely manner versus uncertainty and dragging out the process
lostdog
A blogger (I forget who) said to reject more candidates during the phone screen stage, which I've found to work great. When evaluating a phone screen, many interviewers will think "they were on the fence. Let's see how they do in the on-site," which leads to a lot of unnecessary interviews. Some gentle pressure on your phone screeners to reject marginal candidates works very well. One way to do this is to bring the phone screener to the final hiring meeting, and if you reject the candidate, ask "what could we have done to catch this earlier in the process." More aggressively, you can gather stats and you will find that a few phone screeners are letting through most of the marginal candidates, and some quick conversations with these few will bring down the interview load substantially.

Sadly, too many people running companies ignore the cost of interviewing on productivity. It's very similar to how they view open offices as a "free lunch," pretending that there are no costs, and pushing employees to just work more to offset their management mistakes.

shoo
> reject more candidates during the phone screen stage, which I've found to work great. When evaluating a phone screen, many interviewers will think "they were on the fence. Let's see how they do in the on-site," which leads to a lot of unnecessary interviews.

This is a good tip. My employer is in the process of tightening this up as well. One colleague noted a correlation between people who are able to solve a phone screen problem inefficiently as frequently performing poorly when they make it to on site interviews. So raise the bar for what solutions are deemed good enough to proceed to on sites. Some good candidates may be excluded but the ratio of good candidates making it to on sites should increase.

muzani
Even as an interviewee, I'd prefer more companies do this. Better to be in a small pool with higher odds of getting through, than to have multiple stages or a large pool with low odds.
shoo
> If each portion takes an hour, that's a minimum of 55 hours of Engineering time that's being pulled away from doing their core competency to make 1 hire.

Once you have a new hire on site, there's additional engineering time spent to on board the new hire, depending on: how organised the team & the company is, how simple or complex the work is, how standard or weirdly proprietary the company tech is, how much experience the new hire is working in such a setting.

Suppose you can drive down the cost of hiring a new engineer to zero, there are still going to be costs on the order of engineer-weeks or engineer-months to on board them after they join before their net impact to the business is positive.

What am I trying to argue? I don't disagree that hiring burns a lot of engineering time, but on boarding also burns a lot of engineering time, so there might not be too much value in hyper optimising one phase the process without looking at the whole system.