> How is a process like this in any way shape or form efficient or productive? Because hiring the wrong person becomes a colossal waste of time and money.
That's only because you spent thousands having candidates go through 7 interviews.
this
Ask HN: When did 7 interviews become “normal”?
261–270 of 833 posts
Re: Ask HN: When did 7 interviews become “normal”?
#262This is why I won't ever work for a FAANG company. I am too old for such shenanigans, and I am not underpaid at my current gig. Plus, I'm spoiled -- every single job in my career (even the first one, LOL) has been a trusted referral. So I usually just sit down with the hiring manager and one of their tech leads (if I'm not interviewing to be the tech lead...) and it's pretty relaxed. Sometimes we just go to a local p…
This is where I'm ending up too. Word of mouth from people I trust is really the only way to go any more. Too many companies have dogshit cultures, and I'm happy where I am. Unless my current job suddenly goes downhill, why dance through this insane bullshit for some comp that will barely make me any happier?
Re: Ask HN: When did 7 interviews become “normal”?
#263Earlier quoted context omitted.
I’m a HM at a big tech company with this format as well. Honestly, I really like it. I don’t want to hire the wrong person, it’s expensive and it makes my job awful for a while. It’s great getting data points on several programming interviews, system design, etc. That makes my sell interview so much easier because I can trust the process to assess their technical skills. You need multiple people because you’re consta…
People get PIP’ed and fired routinely that make it through this process. I think there’s a lot of bias in your response. The process worked for you, you work at a large tech company and it gives you validation. It also makes you feel good to lord over the process and boosts your ego, reinforcing your priors.
No post body was provided.
Re: Ask HN: When did 7 interviews become “normal”?
#264Earlier quoted context omitted.
> People get PIP’ed and fired routinely that make it through this process. Compared to what? I don’t think anyone is claiming this process is perfect. Just that it’s better than alternatives. People will always get PIP’d and fired. But the goal is to reduce that as low as possible.
how is it better than alternatives? this seems like a huge straw-man given almost every company that hires developers thinks they’re a large tech company and mimics their hiring process. it doesn’t seem like serious alternatives have been explored.
Almost every alternative you can imagine has been tried. Lots of interviews, few interviews, take home projects, pair programming, hire fast fire fast, trial periods and on and on and on.
Re: Ask HN: When did 7 interviews become “normal”?
#265Having been an interviewer at a FAANG for many years, I can explain some of the logic behind it. I'm not saying this logic is valid , but it's how we got here, imho. First: we no longer trust the hiring manager alone, because probably they aren't a strong developer. We instead trust strong developers that are well trained at evaluating good devs. At the same time, we don't want to thrust a dev onto a hiring manager,…
Why not extend this same criterion to the work itself? I mean you can’t really trust that any developer is writing the best code at any given point in time so it would seem at least a minimum of 5 or 6 developers should weigh in on any given pull request. Maybe that is the way it works there idk and probably never will.
Re: Ask HN: When did 7 interviews become “normal”?
#266Earlier quoted context omitted.
I was going to say this. To add more: a single person (HM) might have biases for or against certain candidates. More people in the loop brings in diversity and helps to keep interviewers honest and consistent. Also these roles are usually high stakes and the cost of a bad hire is too high.
Most orgs use a veto model. If not everyone is a strong hire, the candidate is rejected. The bias is still there, just not a positive bias now. It’s a strong negative bias. And obviously most people don’t want to come across as “too easy”. Essential you’re positively reinforcing to reject more and more candidates and make the whole process a nightmare.
Amazon had an interesting system for this: one of the interviewers, the 'bar raiser' gets the final decision, ideally based on what everyone else says (but not necessarily).
That BR has done 100+ interviews, took a lot of additional training, and is empowered to ask a lot of questions to dive into the feedback people are giving about the candidate. So if someone is being too hard, or has a weird bias, the BR can override them.
It's a fascinating system and seems to work okay.
Re: Ask HN: When did 7 interviews become “normal”?
#267Google had looked at some internal data and decided that after four interviews, you don't really get any increase in signal: https://rework.withgoogle.com/blog/google-rule-of-four/
I worked at Google from 2004 - 2007, and I remember hearing this towards the end of the time I was there in a presentation shared by the people ops team.
It's possible that this wasn't really followed in the hiring process - doesn't mean that the conclusion isn't true. I guess it seems counterintuitive on some level that more interviews wouldn't yield more signal.
Re: Ask HN: When did 7 interviews become “normal”?
#268Earlier quoted context omitted.
You’re asking someone to quit their job to maybe get this new job. And you won’t know for months so all your other offers are gone. So if it doesn’t work out, you’re unemployed with no prospects. Sounds terrible. I’d take 15 interviews before taking that risk.
If it takes months to determine that someone is a bad fit for a team then the team has internal issues that need to be resolved. Moreover, if someone has the skills on paper, and the references to support that, then any tech screening is unnecessary. It just tests for ability to pass tech screens.
I think we should agree to disagree. We both seem to like our own process and see major flaws with the other’s. The best solution is to work at different companies.
Re: Ask HN: When did 7 interviews become “normal”?
#269Earlier quoted context omitted.
PIPing and firing is a huge time and emotional energy suck, and it sucks for people on both sides. To reduce the amount it happens is worthy. You can’t in practice just say, “this guy sucks, lets fire him next week” And it shows, barely anyone in my entire career has ever been fired. I only personally have been close to one.
So you’ve been close to one person getting fired? How do you have an opinion on the PIP process or firing at all if you have next to no experience with it? I knew a guy at a FAANG who earned himself and his report a PIP for the grave sin of choosing the wrong deputy to send upstairs while he was on vacation. The deputized person went to one meeting and ran his mouth (arguably, told the truth). Both are no longer at t…
Been at one of FAANG for a few years. Never saw this play out. Sounds like something that is more likely to happen on the management side than it is the IC side…
Re: Ask HN: When did 7 interviews become “normal”?
#270I'm not sure why part time contract style "interviews" aren't more common. If I ever got into a situation where I was hiring, it would start with a 2 hour conversation. No coding questions. I want to get to know you and also talk shop about applicable technologies. Then after that is simple. I would hire you to do 5-30 hours of contract work where we pair program on real life things. The interviewer would do the driv…
The problem with this approach is that any real task requires a lot of internal knowledge (functional and technical) of the system which an outside candidate will not have. The pairing employee will have lots of it though and it is likely the candidate will appear inadequate even if the employee is aware of the internal knowledge difference. It is not straightforward to be productive on an alien code base from the ge…
I can't imagine this to be true for the vast majority of web/sass companies. Even if there is a lot of knowledge, there are so many areas of the code with technical debt that could just be "How would you refactor this code. Here is how it works." or "This is a small error that needs to be handled. Here is how it works. How would you handle it?"