
NYC Tech and the Compounding Interest of Making a Hire - tberghane
In 5 years working in NYC Tech, working with 30+ Startups, it&#x27;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.<p>From what we&#x27;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:<p>Let&#x27;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&#x27;s a minimum of 55 hours of Engineering time that&#x27;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&#x27;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&#x27;t compete on compensation?<p>If there&#x27;s one thing I&#x27;ve learned over the past 6 months that has stuck with me, and just makes sense it&#x27;s this:<p>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<p>From there, you should have a clear cut decision on hire&#x2F;no hire and the level of Engineer you&#x27;re bringing on.<p>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<p>Agree of Disagree?
======
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...](https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-
interviewing-version-30/)

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

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

------
streetcat1
Why not use machine learning in order to rank candidates and "waste" time only
on the top 3?

~~~
sandman007
This was already tried by Amazon and it failed. ML algo magnified human biases
which were present in dataset.

[http://fortune.com/2018/10/10/amazon-ai-recruitment-bias-
wom...](http://fortune.com/2018/10/10/amazon-ai-recruitment-bias-women-
sexist/)

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

