Hacker News new | past | comments | ask | show | jobs | submit login

Nicholson here.

I sponsored Staffup Weekend, brought Brooke Allen to SF, and helped Deborah Branscum write her story for Medium. I did it because I'm the in-house recruiter for FutureAdvisor (https://www.futureadvisor.com), and recruiting is a mess.

FutureAdvisor hired me to do PR. But after we raised our Series B last year, our main problem was converting capital to talent, so that's what I did. I didn't choose recruiting; recruiting chose me. Just like it will choose many of the hackers on this thread who become entrepreneurs. I hope they can learn from our story.

The first thing a new recruiter notices is that recruiting is incredibly wasteful. It wastes time, emotion and money (contingency-based recruiters charge employers about 25% of a hire's first year salary, so they're paying an extra $35K to hire a software engineer at $140K). It wastes them for both the candidates and the hiring managers. Many of the flaws of the process arise from that wastefulness.

The problem at the heart of recruiting is how to gather good information about strangers in order to make a long-term commitment. It's basically the same problem you have when you're dating.

And, just as in dating, there's a lot of noise in the market. Everyone's beautiful with a little Photoshop. It takes a long time to get to learn who they really are, and what they can do.

To illustrate how wasteful the job market is, just imagine that both candidates and recruiters are sending out very similar, only slightly tailored information to every person on their list, day after day. If someone bites, then you escalate commitment and do a preliminary phone call.

I, as a recruiter, take the call with the candidate, because we don't know how good they are yet, and I cannot waste my engineers' time. We are strapped. That's why we need to hire people. (Non-technical recruiters get a lot of hate from technical candidates who do not understand this.)

If the candidate answers all the questions right that I have been instructed to ask, then I pass them on to the engineers for two technical interviews. If those go well, we invite them in for an onsite visit. In 90% of all cases, the onsite visit results either the company or the candidate rejecting the other. At that point, almost all the information they have gathered about each other is thrown out and never thought of again. (Sure, Glassdoor has some reviews and tips, but they're minimal.) That's the waste.

Those rejections do not necessarily imply that the company or the candidate is bad, or unsuitable to work with at all, just that they're not quite the right fit. It's just like dating. Sometimes the chemistry ain't right. That doesn't mean anyone's a bad person.

There are a couple ways that we, singly and collectively, can try to solve this problem. And they all have to do with how the information is processed. Employers who trust each other could join together in a cross-referral system where they share candidates who were talented but not quite the right fit. FutureAdvisor is part of a couple of those networks, like YC, and they work OK. Their main purpose is to get total strangers one step further toward entering the circle of trust.

Candidates could do the same for each other. It would be a sort of viral networking, where within a circle of trust, everybody's contacts become everyone else's contacts. In both cases, information that one candidate or employer has gathered at great cost to themselves can be shared, rather than thrown away.

Another aspect of the job market is that companies and candidates are asking for the wrong information. Google used to ask for GPAs and Ivy League pedigrees, both crappy metrics. The great thing about professions like programming and design is that you can show your stuff. (Bizdev and middle managers, as a counter example, have a much harder time providing a portfolio of what they do.)

With makers, at least there's a baseline. All hiring managers need to do, after they look at your Github, is figure out whether you are in fact the person who coded it, and how much time it takes you to solve similar problems. Another way of saying this: The only thing that correlates with performance is performance. And that's all that good companies should care about.

So how do they obtain that information in an efficient way?

Batch processing. Staffup Weekend was an attempt at batch processing. We wanted to see a lot of people work at the same time. We made the event free. We asked people to create something they cared about. The ones that came, did so voluntarily. Whether they got a job or not, they walked away having done something they wanted to do. It was a pretty good experience.

But it could have been a lot better. I wish that other employers had been involved, to make it more valuable for the candidates who attended (we invited other companies, but got little response.) I could have given better feedback on the work people did.

On a meta level, teams were invited to create tools to fix the job market. One group created a Chrome plugin called Contactr.io, which shows you the emails of company founders when you visit their corporate website.

There are probably a lot of other ways to fix things. I hope someone on Hacker News will found something that makes hiring and getting a job easier. That person will become rich, famous and universally loved.

I also hope that someone reading this post is an infrastructure engineer with AWS, Linux, Bash and Ruby under his or her belt. If that's you, please write: chris dot nicholson at futureadvisor dot com. Only you can save us, Obi-Wan.

https://boards.greenhouse.io/futureadvisor/jobs/26313#.VMkv_...




It sounds to me like FutureAdvisor might have a problem with low compensation. Previously you mentioned making 8 offers at this event, and only one accepted. And these are candidates who specifically had 2 days free to work on receiving a job, so they have lower compensation requirements then an average dev of equivalent skill, and still 7 of the 8 rejected your offer.

This doesn't seem to me to be a problem of market efficiency, but just trying to use the inefficient state of the market to find the best candidate for the lowest price.

Also to reduce the work of interviewing candidates that won't take your offer when you make it have you tried telling your candidates what the expected compensation is?


That would be fair to surmise, but incorrect. While most startups cannot pay Google salaries, we are competitive with our salary-equity mix. It took us a while to learn what the market price was for various types of roles, and we offer that.

We made 8 interview offers. 7 people either chose not to continue or were rejected by my teams further down the line.

Some of those who chose not to continue were not devs, but client-service specialists. This was not a purely technical hackathon. Many of those people decided they did not want to deal with the math involved in financial services.

You have to remember that SF is a very competitive job market. Devs are choosing jobs that fit their salary expectations, but also their lifestyle choices and their passions. We meet those needs for some people, but not all, since they are idiosyncratic.


Funny, I've actually been thinking about this problem recently and can totally relate to your dating analogy as I see it similarly. As you know, there are several steps in the hiring pipeline, from introductions (getting to know one another), to qualifying (what you're talking about and which has n > 1 iterations- phone screen to inhouse to multiple inhouse depending on level), to on boarding, etc. You initially want to apply a speed dating filter to weed out the few of interest (a guy/girl can walk into a bar and within 30 secs tell which individuals is of interest to them. You want to get there!)

Moving on to the initial qualifying state, I think the one mistake you're making is assuming that only your company can validate this unknown person. To truly scale, we need to figure out a trust scheme (we sort of have it already with our belief in top ranking schools - you mentioned it is a crappy metric, which I agree, but this has historically been the baseline). We need sort of an SSL certificate like system where some third party(ies) can qualify individuals for your company. Again we sort of have this (on the technical front) with top coder scoring, online tests, SO rating, Git Hub Repo, etc. We need to come up with a standard "reputation" service, most likely related to skill, that can be applied in scale.

If anyone cares to bat around some ideas, I'd be an interested party.




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: