Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

So... I worked with over 50 engineers prepping for their first SF/Silicon Valley tech interviews. And I worked at Groupon, interviewed at a bunch of YC companies (including one where I took a job).

In my experience pretty much nobody is taking Ben Horowitz's advice from The Hard Thing About Hard Things—hire based on strength instead of a perceived lack of weakness. Instead everyone seems to be looking for candidates who fill out all the boxes and have zero thumbs down in interviews. That coupled with extreme risk aversion means long interview cycles, and huge amounts of wasted time for some of the most talented employees and founders on the planet.



Well, they sort of are, just not explicitly. The standard process is to have 2 to 5 interviewers, each asking their own question, and pass everyone who get at least one strong yes, and no strong noes. This ends up with a random factor, but ultimately favoring people at least one real strength. The interviewer who sees this strength will fight for them. We've seen people with high skill variance (great at one thing, bad at others) pass interviews at a higher rater than people who are just OK at everything.


Most of those interview questions, don't really have much to do with the way someone actually works. I just went through one of those SV gauntlets at a YC startup, and got a yes, but at no point I thought any of the interviews were any good: Not enough time to actually learn about the interviewer, or solve a problem that a recent graduate couldn't solve. I know some awesome people that wouldn't have passed my interview, and I know people I'd never want to work with that would have passed.

The whole thing made me see why the situation in SV is so screwed up: If we can't really ask for things that show real experience levels, and it's all about short term first impressions, set by interviewers that aren't even necessarily any good at interviewing, how can we improve?

I've always much preferred interviews that asked for the same amount of time, but where people could show a picture of their real output, instead of a little puzzle.

Imagine you are hiring a chef to man your restaurant, and what you ask him to do is get through Chopped: Give him secret ingredients, and ask to make a dish using all of them in 15-20 minutes. You'll be testing something: Some people will do better than others. But are the things you are testing really going to matter, in practice, when what a chef really has to do quickly is to execute a well known, practiced menu, along with kitchen management skills?

We don't test for the things we do at jobs, and therefore, we can't hire. Not a surprise.


> no strong noes

This is the problem. It allows one interviewer with a pet peeve to torpedo an otherwise excellent hire. Where I work, whoever ends up on the wrong side of the majority needs to make a case good enough to convince the majority to switch. Being strongly in the minority is not good enough.

The culture of accepting high false negative rates leads to the "no weaknesses" hiring the GP was complaining about.


I agree, but this is also a management failing, in not noticing the pattern.

I've been able to successfully hire good people by noting that some interviewers are never satisfied with any candidate. Once the pattern is clear, I either remove them from the hiring process, or politely disregard their opinion.

Hiring only with 100% consensus is a sucker's game. Some of my best hires have involved judging which "no" could be overridden safely.


Yeah, I totally agree. We actually asked YC Companies about their fire rates. The fire rate at most of the companies was under 6% (documenting a high false negative rate approach)


Isn't it kind of weird that startup culture is supposed to be all about failing fast, MVP, and pivoting, but when it comes to hiring, it has to be perfect from the start?


Hiring is a critical piece of running a startup. It's one of the few things a startup can control, so hiring choices should be as close to perfect as one can manage. Also, the hiring philosophy at most startups is closer to the 'fail fast' principle than you think. The universal piece of advice is to fire someone quickly when you realize you made a bad hire.


This seems really low in an environment where the consequences of firing are minimal in terms of legal and financial cost (even for the employee, who can probably quickly find another job in this industry). Is this rate much lower for programmers than for other functions? Do you think that's because programmers tend to be nice people and firing someone is highly confrontational?




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

Search: