NYC Tech and the Compounding Interest of Making a Hire

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

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

What's your training set?

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.

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