Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: When did 7 interviews become “normal”?
711 points by geeky4qwerty on April 2, 2022 | hide | past | favorite | 813 comments
edit: I love this community! Thank you so much for all the insight. For those who complained, I'm sorry if this post comes across as complainy or redundant, I respect the HN hive-mind and was genuinely curious about everyone's thoughts on the matter.

Hello fellow travelers, I'll do my best to keep this brief(ish).

I've been in IT professionally since Y2K, data entry->QA->SysAdmin->PM->consultant->founder->sold and with the money took some years off, bought some property and a fixer upper and went to school and got a BSBA degree (never graduated from high school but wanted to show my kids the importance of a degree). I missed working and creating things with people so decided to reenter the job market in the PM space. So now that my hat is in the ring I have been told by recruiters what I need to "expect" in this "new market."

I was told "5 to 7 interviews is normal". What? I genuinely feel like I'm having a 'Blast from the Past' moment in this whole thing (good 90s romcom kids, look it up).

When did a hiring manager lose their authority and the trust of the organization to do their job? Am I just out of touch? How is a process like this in any way shape or form efficient or productive? Am i missing something? HN, please help!




Having 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, so they also need to interview you too and have a say.

Second: Is it really fair to have just one or two developers evaluate you? When I first was an interviewer, I liked everybody! I would have hired them all. So getting multiple data points matters. Best to have at least a couple dev interviews.

Then there's the whole problem of needing to evaluate you on multiple dimensions. Can one interview really tell if you're good problem solving, coding, algorithms/data structures, and any specialization the role has? What about the soft skills aspect? We're going to need to have at least 3 or 4 interviews to cover all these aspects. These roles pay a huge sum of money, so there's a lot of worry that someone will be hired who doesn't really meet the bar, you know?

But now we have a bigger problem: if we're going to invest 4+ people to spend an hour of time with you each, we'd better have some data points that you're worth that investment. So maybe we need one or two initial interviews ahead of time to weed out any obviously unlikely candidates.

After that, it's every other company going "Oh shit, Amazon does 6 interviews? We should do that too!".


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 constantly training up new people and need to calibrate everyone fairly.

Scaling any process to thousands of people is always hard.

Is it annoying for candidates? Yeah, but we pay you a lot of money, and it does actually work for us. Is it perfect? No, but it does work.

“Hire and Fire fast” doesn’t actually work well if you want to give people a chance to succeed. Also people tend to keep low performers around too long. Best to avoid this as much as possible.


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.


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


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

PIP politics are absolutely routine in FAANG and if you’re arguing the other side you don’t know. FAANG is actively trying to fire or replace you at all times. I’ve worked at two so I can’t speak for three, but I’ve also worked for the two in that older acronym that you’d think of as the “nicest”. People read that that and probably hear me saying “giant evil entity is out to get you”, but it’s really middle managers cosplaying Kings Landing in the office, mostly unchecked, that does it.

Seriously; people want to work at a FAANG/MAMAA or whatever so they often assume it’s good. I had someone ask me if I noticed how light my calendar was now that the org considered me irrelevant. There’s an idea that FAANG is a bunch of nerds with glasses cooking up cool shit in a Zen commune with ambient drone music but it’s honestly some of the worst office politics I’ve ever seen across what is now two careers, and the PIP process is a big tool in that kit.


I worked at a FAANG for 3 years and I'm pretty sure no one I worked with was on a PIP. A PIP is extreme. It's sufficient to simply not give people raises, most people can and will easily find another job earning 10% more.


How would you really know? People don't usually talk publicly about their PIP.

I went from long time IC to manager at a faang adjacent company. It was eye opening to see who was on a PIP and go through calibrations.

There were well liked, competent people who others on the team got along with but they just were not delivering at the expected level. Sometimes the problem was lack of motivation or bad role fit.


> but they just were not delivering at the expected level. Sometimes the problem was lack of motivation or bad role fit.

Another i think is when management doesn't understand that someone is, in your wording, a "well liked, competent person", doesn't adequately understand what they bring to the team. Performance reviews, especially of ICs but not exclusively, have a bias towards perceived individual contribution and against teamwork.


Um, this is an antonymous forum, wouldn't you expect many comments from people that were PIPed if it was a very common thing?


Sure, but that doesn't give you any information about your particular company or team. In my experience, how aggressive companies are about "performance management" (using PIPs but this can also include other strategies like layoffs and outright firing) varies quite a lot.


I've worked at a FAANG for almost 5 years. I know probably a dozen or two people who have been PIP'd. I even know one guy who was PIP'd twice and then left when he was given his third PIP.


The smartest person I ever met at Google got PIP'ed, and a few of the engineers from my vintage did as well.


This sounds awful. Disrespectful. Glad I never worked for a FAANG.


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…


Most ICs are pretty well insulated from this, because if they understood what went on at calibration a lot of good contributors would become pretty bitter.


I had a lot of managers and higher level ICs explain calibration and rage quit (although it was long overdue) after an unfairly low review. There were extreme politics happening at the time that the current ED laid out to me in an exit conversation, and most of it came into play. I should have made way more money off of my contributions than I did but didn't play politics, and honestly, given my role and position could not. I was a resource and not a player:)


Thank goodness ICs never see the top-level calibration with the executives. It's the most insane, ill-informed drive-by management I've ever experienced.


FINALLY someone on this thread that understands politics and freaking understands that human beings are not spherical and frictionless.


> PIPing and firing is a huge time and emotional energy suck, and it sucks

So is the 7 interview gauntlet. But I guess it just shifts the burden on the candidates and externalizes cost.


It also selects for people who will put up with anything, which to a cynical manager might sound like a good employee, except that our job is to replace labor with machines.

People who put up with anything are expensive. They keep billing you hours for tasks that could have been reduced to minutes by someone with a lower tolerance for BS.


I swear some of you have had terrible work experiences. I've been an engineer for the last 20 years. The first time I tried being manager, I sucked and it sucked. (I definitely sucked more because the place sucked but I wasn't great.) That was a decade ago though and I've gradually stepped back into management because I've had great leadership and learned a ton along the way. My primary goal as a manager is to ensure the team is happy and healthy, so that they are able to work effectively. Our hiring process supports this by ensuring we're not hiring dead weight, toxic people or engineers that can't provide value and drag the team down.

Where do you people work because I'd like to (a) avoid it and (b) poach people because your world view sucks and I can only assume that's a direct response to a shit environment.

To put it into perspective, my first 1:1 with everyone on the team includes questions like "what have previous managers done to help you be successful?" Managing people can be difficult but managers shouldn't be.


Or it selects for easy going people with patience, grit or humility, which seem like positive traits. It is true that companies tend to only hire the suckers that complete their full interview process.

My current company ambushed me with a full interview panel, Gilligan's Island style, when a former coworker invited me to come in for a 3 hour tour. I took it in stride and had fun, and it gave me some additional leverage while negotiating compensation. I remember writing an architecture doc and unit tests when they asked me to code something in an hour and a half. I've been there 6 years and it's been most rewarding for me and my family.

My first job out of school was a solid 8 hours of interviews, and I had a lot of fun during that interview too. I got to work on space ships, and in time made a fortune in equity. I remember preparing a presentation slide deck completely in valid C++ syntax. I also remember taking a red-eye after that interview for another 8 hours of interviews at another company, which I also enjoyed despite having only had 4 hours of sleep.

The 2nd company I worked for decided last minute to interview me for two different roles. That was like 11 hours of interviews. I actually ended up taking the 2nd role because it was a significantly better fit. I brought a large cast iron skillet to that interview, which was a nice ice breaker.

It's true that I put up with a lot of frustrating tasks without complaining, but I personally have zero tolerance for BS. It turns out that the more I push back on BS within an organization, the more I tend to get paid, so in that sense I suppose I am expensive!


What's with the skillet?


One of the interview sessions was with an industrial designer. Seemed silly to me as a software engineer but what do I know. Leading up to the interview, they asked me to bring in a photo of something I thought had elegant design. After brian storming for not very long I decided on my skillet, and I thought it would be more fun to bring it along. When they asked for my photo, I pulled it out and plopped it on the table. After the initial WTF moment, we had a lengthy and interesting discussion about the merits of cast iron cook wear. All the subsequent interviews started with, "why is there a cast iron skillet?"

Going through TSA with a cast iron skillet in your carry-on is actually pretty fun because it's impossible for the screener not to giggle. I've also gone through airport security with a 20lb printed circuit board with about 90% copper fill, which surprisingly got less scrutiny.

Having something fun to make your interview memorable seems to go over well. I got selected for an internship because I showed up to the "interview" in a Hawaiian shirt. Apparently every other candidate showed up in a suit. We were meeting at a coffee shop on a college campus, so I just dressed for the environment.


It's probably also selecting for people who are unemployed and therefore much more able to attend the entire gauntlet than those already employed.


I would think the opposite is more likely.If you are employed, there is no pressure. You may go through 12 interviews for a 12 different jobs and be only so slightly offended. For the unemployed, time is most likely ticking, if not financially, at least emotionally. A relative slowness at any step of the process affects the unemployed mindset. Stress alone lowers interview performance, especially on the soft skills side. I would guess that more people in the employed pool make it through.


If you're employed it's more likely you don't have time for 12 interviews because you're working.


You do have time. those interviews are scattered across multiple weeks, if you work place doesn't let you take a couple of hours of working hours away for personal matters, you got to quit even before having a lined up job as you don't want to stay there for far more important reasons than inability to take even 5 interviews


True but being employed goes a long way to giving the perception that you are employable so in the cases that the decision is a toss-up between an unemployed person and an employed one I’d be willing to bet the employed one wins almost every time.


So what its a circle jerk of people putting up with BS, then going through BS again because they did so well the first time?

I mean, maybe their other job isn't doing great, because they clearly have all this time to interview, wonder what is going to happen when they join your company...


exactly my point, well said for me :)


There might not be pressure, but you have to schedule time away from your current job to take interviews.


How would this really be possible while currently employed, kids, real deliverables?


To some extent, perhaps it's analogous to poor vs. rich people buying boots. Someone living paycheck to paycheck can only afford cheap boots, so they wear out quickly. Someone with money to spare can afford the high quality boots, and they last years.

Similarly, someone with a flexible, relatively good job is more easily able to look around and find an even better opportunity.

On the other hand, it takes some courage and risk tolerance to step out from the day to day grind and find something better, even if it could ruffle some feathers. That's not something that comes naturally to most people. Break some eggs to make an omelette.


No kidding! The best people already have jobs and you want to steal them away from somewhere else. 5+ interviews? giant take-home projects or multiple coding assessments? Pass, they're not going to put up with it. "Our 7-interview process ensures we only hire the best" ... of the 10% willing to go through this nonsense.


Well no.

It's expensive for the company too. All of the people involved in the interview process are still getting paid while they are interviewing the candidates. They aren't working on their projects that they have to complete. The company probably has a recruiting or talent acquisition team and the people on that team don't work for free. The company might also work with outside agencies or external recruiters. If you hire one a candidate from one of these sources, you have to pay them too.

It's really expensive in terms of time and money to hire people. It's really hard to build a great team.


> All of the people involved in the interview process are still getting paid

Except the interviewee.


There's often a signing bonus. If there's a 10% chance of getting the job and a $50k signing bonus is common, then your EV is $5000 per interview.

Even if there weren't, then 10% of the extra compensation vs. an easier-to-hire company with your discount horizon applied would also count as payment.


> $50k signing bonus is common

I clearly live in a different labour market to this conversation. How many places in the world is this common?


If you’re 10% likely to get a job with a 50k signing bonus and you’re doing 7 interviews for that job your expected value is $715 per interview.


If you do it right, candidates can leave with a positive impression even after being rejected. I've maintained correspondence with a few candidates over the years because they felt like they learned a thing or two about engineering during the course of the interview, and they wanted some additional mentorship.


The interviewee is usually interviewing on their current company's dime. It's even easier now with many folks working from home, you don't even need an excuse.


Yes it’s an expense but you’re not doing it out of charity it’s for the benefit of the company and so it is also a part of the job.


In my experience, it seems to take a company about 1-1.5 years to fire someone that's well intended but ineffective in their role. 15 or so "wasted" person-hours up front is well worth avoiding thousands of wasted person-hours, especially considering maybe 1 in 5 candidates that make it to a full interview are a good fit.


15 extra hours * N candidates per opening * M people onboarded per additional marginal employee discovered.

Picking numbers from a hat say 15 * 7 * 20 = 2,100 unproductive hours to avoid a subpar employee that still actually gets something done in the ~3,000 hours before being fired. That could easily be a net loss depending on how much onboarding time is needed and how unproductive they are on average.

Honestly, I think those numbers may be overly generous to long onboarding processes.


I am still fixing up the code of a developer from five years ago who was there for two years prior to me. He had ideas about how things should work and completely disagreed with the conventions of every framework.

And so, every time I go in a section of code to fix a bug or adjust a feature and I see his name in git blame... I spend another few hours to make sure that I'm not breaking some of the twisted framework code that he had and possibly fix it up a bit and adding a unit test for the functionality before I touch anything to assure myself that I know what it is doing.

An unproductive poor employee is bad... a productive bad employee is where the real problems are for years and years to follow.


The question is how likely a longer interview process with avoid such employees not that they have a cost.

In your case code reviews could have caught the issue early before it became such a problem. Though obviously they also have a cost.


I don't think a longer interview process is strictly necessary to avoid hiring unqualified people. Rather, a longer interview process helps to hire more people while maintaining high standards. Individual interview sessions go poorly all the time for silly reasons. If a candidate only had one interview session and botched it, they're probably done. If they had several sessions and botched one but showed excellence in another, they would still have a good chance of getting an offer.


shrug hiring the wrong person into an engineering role is incredibly expensive and painful for organizations with a long term outlook. It cancels out the productivity of at least one good engineer, and stresses out at least 3 people.

I've been a hiring manager before, and hiring good people is a huge time investment. The reality is that something like 99% of applicants aren't qualified, and the majority seemingly lack enough self-awareness to know it. The really good people also tend to be bad at marketing themselves. I don't think of interviews as a waste of time, though, even when it's a no-hire.


> 2,100 unproductive hours to avoid a subpar employee

You also need to factor in the odds of this whole process working.

There’s not a whole lot of empirical research that measures the correlation between the interview process and employee performance.

And of course, employee performance measurement is as dubiously effective as ever.


There is a lot of empirical research, but it’s internal to companies.

I know multiple FAANG companies that track this data.


"it seems to take a company about 1-1.5 years to fire someone"

Well maybe thats the actual problem the company should be fixing?


If someone is working hard and trying to make it work, the rest of the team is going to try and make it work too. A seemingly good rule of thumb is to start seriously considering firing someone the moment the thought enters your head. Typically by the time you're having those thoughts, the situation is likely irredeemable. In a generally positive work environment, folk aren't typically thinking about firing each other, and so it can take a while.


How do we know this isn’t blind faith and the numbers are “made up”?

Other than fiat wealth generation, what gains are there to treating each other like this?


I'm not sure what you mean? Are you suggesting that companies shouldn't avoid hiring unqualified people that generate less value than their cost on average?


Research into who brings value, what technologies improve efficiency, has been inconclusive. The models end up with so many variables the conclusions are meaningless; any one parameter is insufficient, all the parameters needed mean no one parameter is greater than another. How can a value assessment being useful given all the required context that also has to exist? Is it a measure of value or traditional human bias?

Humans are prone to group think, belief in words of power, sigils; why believe in unfalsifiable value assessment when it comes down to tried and true ownership?

If traditional politics win at the end of the day why the belief this matrix of value isn’t just another cognitive boondoggle?


I think there's a bit of a misunderstanding in what interviewers are testing for. Interviewers at most companies aren't trying to evaluate or quantify a candidate's inherent value or general technical prowess. They're trying to determine whether or not the candidate can help solve immediate and real problems that the company has, while also trying to get a sense of whether the candidate has the potential to grow with the company long term.

There's very little science in interviewing, and it is indeed heavily based on heuristics. The whole point of lots of interviews is to reduce bias. Unfortunately, it's possible for candidates to mistakenly think an interview went poorly because they didn't get the answer right away, when from the interviewer's point of view it was one of the best answers they've heard because of the process by which the candidate arrived on the answer.

A popular metric for whether a candidate is likely to be able to solve practical problems is whether or not they've shipped products before. A lot of people pad out their resume with collective achievements, though, and so it's something that needs to be dug into. It's unfortunately not uncommon for folk to not understand the stuff on their own resume.


There is no misunderstanding on my part.

I never consented to this culture. I see little different here than a church, meat based tape recorders thinking the noises they emit are “the way” with little proof except “feudal capitalism” continues to “work”.

We don’t owe deference and agency to CEOs, VCs, and founders. The syntax is different but the LARP of being sheep for “wise men” is the same.

Only 13% of the country has an advanced degree (mine is MSc in math earned in the 90s; I’m old) and knowledge is not locked away in those heads. Education does not make people infallible and omniscient.

This is a result of traditional political memes; owners rule, everyone else drools. The filtering and sorting inside that cognitive bubble is just the proles making proles dance like jesters. No scientific theory makes this the one true way of organizing effort.

Memorizing semantics is not proof they’re correct. If GME can be shorted to the extent it is despite that being illegal, our institutions are built on deference to BS, since that system is the bedrock used to prop up tech VCs.


"If GME can be shorted to the extent it is despite that being illegal"

Shorting is only illegal if it's naked. When I ask people who say this what they mean, the answer is usually that the shorting must be naked because so many shares are being shorted. But that isn't how that works. If you have other evidence though, I'd certainly be interested.

https://www.fool.com/investing/2021/01/28/yes-a-stock-can-ha...


Here’s my investment advice; go back to the late 90s, load up on tech, use the gains to dabble in btc, use those gains to retire by 40.

Worked for me.

I know how the boring numbers game works and optimized for it. I’m being honest instead of equivocating in Anglo-babble reasons why a process is an acceptable measure for filtering some people. To see poetry in this is a bit weird. It’s the same old fundamental arithmetic operations applied to different geometry. Pretty routine for us been there done that’s.


You seem extremely jaded, and the way you speak about religion is rather boorish in my opinion.

I enjoy living in and participating in a society. Thanks to the productivity gains of specialization and free trade, technology has been developed to the point that I spend my days designing embedded software to fly autonomous aircraft. Those aircraft deliver medical supplies, primarily in developing countries with poor road infrastructure. At least a few people a week don't die specifically because a UAV I helped make was able to deliver them a blood transfusion. The company is for-profit, and in exchange for my work I am compensated in salary and in equity. The better the company does, the more people have access to life saving medical care, and the more money I personally make. The UAV system also requires people to operate them, and so the company employs hundreds of people in those developing countries. One of the earliest and most tenacious in-country employees quit a couple years ago because they got accepted to a robotics program at Stanford.

The last employee I personally managed the hiring of only had a couple years of community college experience and self-proclaimed ADHD. Despite my intent for them to only spend 6 hours or so on the interview process, they spent probably 16 hours because they found the interview process itself personally rewarding.

The company CEO drives a crappier car than everyone else at the office. By coincidence, I had a serious problem last week that required intervention, and I quite literally made the CEO dance like a jester for me in order to make a point. There was no scientific theory involved.

I'm right there with you regarding the corruption of most financial and government institutions. I don't think it's as black and white as "capitalism bad", though.


I’m dubious that companies can accurately measure ability or performance, either in the interview process or on the job.


Have you ever been in a job or taken a class with other people and not been able to see the different between the more competent and more incompetent people?


Yes, but I only see facets of their performance. And I’m only interested in specific areas, and might be blind to other talents or issues. They might be the brightest bulb in the training class, but spend all their day reading hacker news and creating memes.

It’s very difficult to quantify individual performance, and even harder to put a dollar figure on it.


Re: experience and working hard vs. working on what the project needs, that's definitely a trait of more seasoned engineers. I'd say it's a matter of learning strategy over tactics. I've gotten pretty good at that balance over the years. When I came into my current project I focused on aspects of the software that had been sorely neglected before me, and plenty of folk where skeptical for the first year or so. Now in hindsight the results speak for themselves, and it's apparently become a story of legend that my coworkers tell new hires.

Last week I had fully intended to spend at least 20 hours heads down coding, but instead I spent the entire work week writing and updating an architecture document. It was the best use of my time, though, as it allowed two other people to be heads down coding instead. Now this week it's three of us frantically writing code instead of just me, and we all know the final result will work and be boring. We're replacing a 7 year old piece of critical infrastructure.


This is one of those things I stupidly thought I understood when I was a Jr. Engineer, and now understand quite a bit differently after decades have gone by.

The more competent people weren’t necessarily the ones getting more things done, or the most visible, but were those engineers who understood the long term implications of what they were building, how it related to the business, and their relationship to other teams and customers. It’s trivial to be a good “performer” toiling away on a feature or system that shouldn’t exist. It’s exponentially harder to have the awareness to identify where the real problems are, and make sure you’re investing effort where it actually needs to go.


Indeed. Experienced interviewers can size up a candidate in the first 10 minutes and fairly accurately predict how their debrief will go. The rest of the interviews are just building up confidence, and making sure there's enough redundancy to tolerate the occasional bungle or accidental awkwardness. Folk get hired all the time despite getting imperfect interviewer feedback. I've had interviews where the first 45 minutes were painful but then the candidate blew me away in the last 15 minutes.


Perhaps, but PIPing and firing is bad for the employee, bad for the manager, and bad for the PIP'd employees teammates. PIPs don't happen immediately; it might take a month or two before it's clear to a manager that a new employee isn't performing to the expected level.

So I think I'd rather have a candidate spend 7 hours interviewing if it could save months of pain for multiple people later.

(This does assume, of course, that the 7-person interview panel actually does decrease the incidence of hiring-the-wrong-person enough to be worthwhile. I don't know if that's actually the case.)

Out of all the things I think are wrong with tech jobs -- and with employment in general -- I don't think "I have to interview with 7 people instead of 1 or 2" even cracks the top 50.


Cost externalization is the entire basis of businesses/corporations these days it seems.

Maybe it was always that way though


I think it has gotten better in some areas. Sales processes used to be brutal for buyers. Pricing today is more transparent in general.


Compared to PIPing and firing? Interviewing is probably way, way less of a time and emotional energy suck.

Granted, I've only ever taken and given interviews, never given (or, fortunately, been under) a PIP or firing. But interviewing is just a few weeks or so of preparation and then a day or two, and the preparation is often fun, and so are some of the interviews. Nobody thinks PIPs and firings are fun.


Speaking as a senior dev who has interviewed dozens (if not hundreds) of candidates, I assure you that the bulk of the burden is firmly on the interviewers, not the candidates.


It doesn’t externalize costs at all. We’re talking easily 20 developer hours per candidate. That’s real money.


> To reduce the amount it happens is worthy

The point is that there is little, if any, evidence that a given interview process does this.


I've worked and interviewed at dozens of companies and literally never experienced a company that had more than 2 interviews plus a discussion with a hiring manager or HR.

I make half-ish of a FAANG salary, but it's enough to comfortably support a family and I'm generally pretty happy and get to work on cool stuff. The only challenge I never get at work are problems that have huge scale components.


Interesting, I’ve interviewed at all of the FAANGs other than Netflix, plus maybe 10 or so much smaller companies. In general the smaller companies all seemed to want to emulate the FAANG hiring process with 4-6 rounds of interviews with engineers after an initial phone screen. I think only 1 or 2 of them limited their interview to just 2 rounds.


I've been approached by a couple of FAANG and told them to stuff it because of the recruitment processes. I'm in London, and here at least they're extreme outliers.

If you're early in your career, they probably matter and it might be worth it, but for me it's not.

Maybe it'd be different in Silicon Valley, but in London they just aren't willing to offer enough over and above the kind of jobs I've had elsewhere to be worth the misery (with the big caveat that I'm at the high end of non-FAANG London market rates; for someone who is not, FAANG may be worth it here too)


You're being kind. "Extreme" doesn't describe it from my experience. For me it was 1 phone call/online meeting and 2 face 2 face. That is about it in terms of interviews. And that is a Fortune Global 500 company that I'm still working for. I was put on a 6 months contract and after 3 they switched to perm.

Other interviews back then and more recent were pretty much the same. Max. 3 x 1h-ish meetings. I do have a bad habit of asking the interviewer to sell me the job on the first face 2 face meeting though. This does offend some of them and we drop it there. No point beating around the bush and wasting time if they think the interview is a one way street.


The part about expecting them to sell the job is a good point, and important. Don't think that's a bad habit at all.

I also tend to make it clear from the outset I will not come cheap, in a "are you sure you can afford me?" kind of way. Not mentioning specifics, but making it clear I know my market value and won't consider low offers.

Some get very taken back, but it sets a tone. I think you're absolutely right you need to make sure they know it's two way, and to give a clear impression they're chasing someone high value, and that they're not the prize, you are.

But if their pitch is all about "changing the world" but they're not willing to share the upside, I know I'm wasting my time, so I want to make sure they know that I expect my share too, not just fuzzy feelings.

E.g. I a while back came across a company that was very proud of how rapidly they were growing, but somehow thought that mattered to me when they were not willing to offer any shares or options. I was meant to be excited about making other people rich...

I pointed out to them I've not once taken a job on terms like that in the last 25 years and called off the process after the first interview. I also explained to the recruiter just how far off market they were for someone at my experience level.

If that had happened after 5-6 interviews I'd have been incensed...

FAANG recruiters in particular also seem to get confused when I insist on getting an indication of salary range and option/rsu amounts before being willing to agree to an interview. Several times I've had recruiters come back to me days later after digging up the information, as their first line seem to not even know, just expecting people to be all excited they're even calling. For my part I'm shocked more people aren't having that conversation. But that does explain leaked info some time back about how Facebook is dealing with high rejection rates once they actually give offers.


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.


Hire fast fire fast is by far the best one, should you really need it. A 20 minute technical conversation and then firing within 2-3 weeks if they do not seem self-directed has worked in my experience.

If you can't get someone up to speed with your internal processes fast enough to at least gauge if they're following along that indicates an internal problem.

The problem is, I think, that HR does not want technical staff to see the hires for (probably made up) legal reasons. So the decision is mostly made by people who can't actually gauge competency.


How do you handle the obvious problems of churn and reviews at places like Glassdoor? I can just see it now:

"Interview was weak. They don't know what they're doing."

"Aced the interview. Fired after two weeks. Leadership doesn't know how to hire or manage."

"Never seen a place with so much churn. In the last six months, I've seen at least half a dozen engineers exit after two or three weeks."

Know what raises the level of difficulty for finding candidates? Shit reviews about the company. You can have the best tech but if you have a toxic smell, you can't hire. To the outside, perception is reality and reviews are how you get that perception. You can't do the opposite though and say "J Smith passed interview but we let them go after two weeks because they couldn't do more than pseudo code on a whiteboard." and even if you could, you'd look like a shit company and you'd still have an impossible time hiring but for other reasons.

This idea of quick hire/fire is so bad that all you have to do it go one or two steps further to find the obvious problems. But hey, start a company and use that model. See how it goes. Prove us all wrong.


Low performing folks are ubiquitous and them being let go sounds good to me, would put a plus in their column if I read that.


Yes but the damage that they’ll due to your reputation online will make you have to pay more for better talent. They are going to read the glass door and see your company environment as shit and say “I want an extra 20 grand”

Not to mention the amount of technical debt high turnover causes for tech companies


Not that many people actually get fired in a hire fast fire fast workplace. The whole point of hiring this way is allowing yourself to not overprepare in an aversion to hiring poor talent. When you get a poor performer, you just let them go, but the average is not that bad, and you end up filling your billets faster where another company may not at all.

The opposite is 7 interviews and shedding most of your applicants for trivial reasons. Most businesses can't support that, too much work would go undone and they would stop being competitive.


No question the interview process is akin to testing a marathon runner by their 100m dash time.

I was just talking about to implications of poor company chemistry which stems from lack of trust and job insecurity.

I think the best way to evaluate a person is just to talk to them about their experience and why they do what they do. Passion is a critical indicator


Indeed. I remember interviewing for several positions and could have done them with one hand behind my back. A ~year later they were still trying to fill the position but hadn't.


> Hire fast fire fast is by far the best one, should you really need it.

I can only say that: Oh my gosh do I not want to work for a company that "hires fast and fires fast". For many different reasons.


Working is one thing. What about when you need to get hired and don't have six months to waste? If it weren't for finding a quick place to give me a chance I'd be unemployed.


Fired after 2 weeks if they don't seem self directed? I have been at one place where I didn't even have my laptop in the first two weeks and multiple places where I did not have access to the codebase yet.

Most people except for a few outliers will be fumbling around the first month while they learn the code and the company.


this is rather terrible for people who leave a job to come work for you. Hire fast fire fast only really benefits the employer -and only if they successfully manage to pick up on toxic people that fast. It can take months for someones true colours to show and then in many countries you are past the point you can "fire fast".


All of these are used in the wild at various companies. Maybe these companies are entirely staffed by subpar engineers, but FAANG style whiteboarding is extremely gameable, especially if you know someone in the inside already, but even if you don't and leetcode enough.


I personally suck at pairing interviews but I still think they're some of the most relevant & illuminating- if the problem is easy and you're looking for how the candidate works and communicates.


How exactly do you reduce that number when it’s a fixed quantity at FAANG, big tech with their stack ranking, managing out and OKR’s that requires to put a certain number of people as “under performs”?

The entire system makes absolutely no sense, precisely when looking at the numbers. You could do anything you wanted during the interview and that still won’t change the outcome that the same number of people will still be fired at the end of the day.


My company has a phone interview with a developer to ask some technical questions and then whoever passes that is invited in for a single in-person interview with a developer and our supervisor. It has worked for us - every developer we've hired this way has done their job well and stuck around for a long time.

We make an effort to take up as little of the candidate's time as possible.


Umm how is this normal when you have stack ranking (sorry curve fitting) to identify the yo-be-fired?


How does me being okay with a smaller role in the overall hiring process equate to me wanting to lord over people? I’m a hiring manager, it’s literally my job to pick people to hire. I’d rather have the opinions of my colleagues in addition to my own.

My response was in good faith, and yours is not.


I think mylons had the perception that you were a senior engineer conducting technical interviews as opposed to a hiring manager.

Having had a fair bit of experience interviewing on the technical side, I've observed a huge variance in quality of interviewer. Sometimes you get someone who values communication, creative problem solving and asking good questions. Sometimes you get a whiz kid who gets off on playing gatekeeper and judging people as below their superior intellect.

Even a single person in the chain who falls into that latter group can completely derail a potential hire, leading to an overabundance of false negatives, IMO.


Let me add my experience. I've never had the FKANG experience but for a number of startups that I've contracted for I've had a chance to observe if not participate in the hiring process.

They were US startups and they've all tried to emulate what I think of as the FAANK process: so you have an initial call, a technical screen a couple of other rounds of technical screens, that maybe include system design, and fit/behavioral with people you might be working with. In practice the people who got hired endured 5 to 7 interviews.

It's interesting to see the statements here saying that the reason for the large number of interviews is to assess the candidate from a number of dimensions and perspectives. What I observed was that was not how it really worked.

My position as an outside contractor, as well as someone who loves chatting with people, made me sort of the ideal confessional for the engineers who directly participated in the hiring process.

The main dynamic that drives having such a high number of interviews is that the hiring process is less about assessing the candidate (beyond a certain point) and more about allowing to play out the implicit political power and conflicts of the people who are judging the candidate.

For example in the first startup we had this engineer who was identified by the CTO and co-founder (who formally stepped down as CEO) as being a good potential hire, and they excelled in the technical aspects of the interview but they received meh votes from one of the engineers who was lead on a significant project and had a bit of clout, at 3rd interview, and were subsequently rejected, after 7th interview.

So basically the feeling of the staff that I talked to was the reason there existed four more interviews after the consensus was to hire, was to allow the political player to promulgate their preferences and manufacture consent with the motion to reject. So through a careful orchestration of four additional interviews closely managed by the political player who asked doubt-casting questions in each debrief this lead was able to cultivate doubt where formally there had been consensus (besides his sole dissent -- he wouldn't have been working with a person anyway, heh :)). So basically it would have been intolerable for this politically clouted lead person to have "lost" to those other staff with less clout by having their preference denied. I felt really sorry for the candidate but I heard that when they got the 7th interview rejection that already accepted an offer at a FAANG, go figure. Heh :)

Observed a similar dynamic play out in another hiring process at a different startup. That stage we had the director of engineering identify candidate that was a good hire. And basically softly railroad them through the process which didn't prove difficult as everyone was mostly on board and the team was really desperate for high quality technical talent with the right skills and this person had that.

So what was interesting to observe was that the other candidates in the pipeline at that time were still taken through interviews even though this person was basically from the initial screen stage already being moved to be hired internally, and all of the other interviews were basically friendly get to know you sessions with super lightweight technical questions and a lot of I suppose you could call it confirmation bias but it's really just you know people being nice to someone they want to work with.

But all of these other poor candidates in the pipeline were still put through all these interviews with the idea that you know there was still a role out there for them being told the same things they would have been told were they you know actually under contention. Or maybe that was because we didn't know if the candidate was going to accept or not but they seemed pretty keen and the thing is I'm almost 100% sure the team wouldn't have hired any of the other candidates in the pipeline anyway.

But again I observe the dynamic where the debrief interviews about these non-starter candidates were basically role-playing games for politics in the organization where people projected their preferences into little power games against their colleagues to try to have their own preferences be the ones that win. Decidedly wasn't about those candidates at all because they had not even had any chance of being in the process. The only point of the subsequent interviews of all those non-starter candidates was to act as an arena for the staff to role play their sort of political status conflict games with each other but this was never exposed or stated it was just this sort of implicit thing.

So given that experience I wonder how much that is a dynamic driving these lengthy and in a lot of cases unnecessary interview processes across all of the tech hiring and organizations that are utilizing this type of process these days.

I don't think it could apply everywhere I think there's probably places like Amazon where they are really doing something different. And like I said I don't have any of the data from the ZFAMG stuff.

But I'm reminded of something Peter thiel said which is you know in academia the battles are so fierce because the stakes are so small. But another side of that is everything so secure there and that's why the stakes are so small. Same thing is true in tech I mean once you score one of those 150k plus contracts and you're doing something that you basically love doing it is a great ride and everything really is so secure so how do people take out their natural ape brain competitive urges in that environment? I think as another commenter said, where can people project their risk-focused paranoia in such a low risk environment? and it's onto personnel.

So I think there's definitely the case to be made for maladaptive pathological psychological underpinning of these lengthy hiring processes as much as there is a case to be made for how they could be useful at getting data from from a bunch of candidates.

Personally I think the best types of hiring interviews are some sort of pair programming work emulation. The problem with that is in my experience companies are generally very terrified to open up their internal code base to the eyes of outsiders because they're basically scared that oh my God people are going to steal our code.

But it's always the case where after someone's hired and you start working with them that's something you end up doing and that's where you really get a sense you know if can I trust this person to deliver and do they match what people are being saying about them from the interviews.

So I just think those sort of work emulation tasks you where you're pair programming or talking through something with someone it really has more of a place than it seems to have been given so far in most of the places that I've seen and heard about.


this is the in-depth reply that illustrates my flippant comment. there can be an inherent competitiveness in white-boarding interviews. the interviewer can implicitly want to show their superiority over the candidate. i think that's the core reason behind a lot of overly difficult problems being offered that have no analogous presence in the day to day work. how many times have you written a graph traversal algorithm on the job? or implemented a geofence in 45 minutes, from scratch, without a search engine?

i whole heartedly agree on the pair programming approach being practical and yielding good results. i think you can skip exposing the candidate to the internal codebase, and replicate an internal problem in a more generic and high level way.


>>> there can be an inherent competitiveness in white-boarding interviews. the interviewer can implicitly want to show their superiority over the candidate

This can be present even in non-FAANG interviews. Early in my career, I had an interview at a financial company and for a question about how do you style html pages, my answer was CSS and the interviewer expected something about ASP.NET webstyles. He was't ready to accept my answer saying you are a dotnet dev and should use ASP.NET functionality since it was more superior rather than CSS. I was like CSS is a web standard and anyone even designers can modify CSS.

So yeah, it depends on the maturity of the interviewer.


right — it’s certainly not FAANG specific but seems to arise from these styles of interviews. maybe it’s lack of interviewing training or standards? i think the standard now is, “pick your favorite hard problem and have a candidate do it on the whiteboard.” which presents this opportunity for an interview lacking compassion.


agree, now let's you and me apply to YC with our disruptive, upending-the-traditional-inefficiencies in tech hiring startup idea. Ho ho ho! :)


haha — my email is in my profile page if you really want to talk about it. i have interjected at previous companies where it was possible to influence the process a little bit. my biggest question would be “how could you do it differently than triplebyte when they first start?” they started by interviewing people themselves which is hard to scale.


YMMV, but it's actually quite difficult to get a PIP in many tech companies, and it's rarely if ever for lack of tech skills. The ones I've seen usually involve either motivation, output, or both plummeting to zero for extended periods of time due to burnout or a similar extended personal crisis.


From what I’ve seen it’s almost always as you describe or something political like a manager taking over a group and wanting to make room for their friends. But if employees are burning out and then being PIPed instead of getting support I think that is a rather sad indictment of our industry in an of itself.


>if employees are burning out and then being PIPed instead of getting support I think that is a rather sad indictment of our industry in an of itself

The thing is most big companies don't care about your burn-out or personal situation, they either have product launch deadlines to meet, or revenue targets or customers to please, and people in the trenches are considered replaceable so churn is something they account for in order to meet those commitments.

If you're lucky you might have an understanding manager, but he himself may have targets to reach for his bonus or promotion, and if you're dragging his team down and his bonus promotion with it, then ... it's nothing personal, it's just business, you will be let go.

I worked for a major European semi company and the churn there is insane, either they fire people or people leave by themselves within the first 2 years. All because managers are given near impossible targets, along with great bonuses and stock packages to incentivize them to use whatever means necessary to deliver on those targets, usually at the expense of people in the trenches which are treated as expendable commodities.


Your manager might also have a specific target for “unregretted attrition”, i.e. getting rid of people using the PIP process. If there is not a clear person who is the weakest link, then the manager will pick their least favorite. And remember, performance is very subjective.

I have seen a couple of people get fired for cause; that was always clear. I’ve never seen an unambiguous PIP.


As far as I know only Amazon has targets for “unregretted attrition.”


I heard Microsoft did this for a long time as we. It’s my under it changed though since Nadella


Presumably, any Jack Welch-esque stack rank shop is going to have URA targets.


> YMMV, but it's actually quite difficult to get a PIP in many tech companies

Generally, the more the company practices “hire fast, fire fast” the easier and more common it will be to PIP people.

The companies with 4+ stage interviews and entire departments devoted to recruiting and candidate evaluation tend to not have as many PIPs because they’ve studied their interviewing processes and prevented most of the underperformers from getting hired in the first place.

The most quick-to-fire company I ever worked for had barely a 1-hour interview process. They’d hire anyone who seemed remotely qualified and then they’d fire everyone who didn’t work out. It was terrible and now I’m actually suspicious of companies that don’t do much technical screening for applicants.


How do extended interviews root out people that are going to later go through some kind of major personal issue or have burnout or have a lack of motivation?

Lack of motivation and burnout maybe could be somewhat sussed out in an interview if it was obvious, but the people that I've been around that's happened to (and myself at one point in my career) were completely fine, but I'm skeptical of any interviewer that says they can reliably fish that out.


They don't/can't, which is why you still see both at any company, no matter how it interviews.


I think this is highly dependent on your company. People talk about FANG/SiValley companies like they're all the same but that is completely untrue. There are orders of magnitude difference in culture between companies and even within companies. I guess when you're on the outside looking in it all seems the same. It also changes depending on how the business is doing. I suspect, for instance, things are about to seriously go downhill at Netflix. That may cause the culture to become even more cutthroat.


> it's rarely if ever for lack of tech skills.

isn't output related with lack of tech skills?


To a point, but it's rarely the inability to code that is leading to lack of output. Output often means "did sufficient work that was seen, by management, as impactful enough". This has more to do with communication and task choice than anything. This is not really a skill that we even really attempt to measure in interview.

In my experience in high performing tech companies, I've seen about 40 PIPs. There are 'utter tech incompetence' PIPs in the world, but as far as I've seen, they are far less popular than 'thoroughly uninterested in working' PIPs, 'disliked by new manager' PIPs and 'person has a work unrelated crisis' PIPs. Those tech related PIPs will normally have all the symptoms already in the first review cycle. If someone made it to their 2nd year in the company, tech incompetence is not really the issue. It's just unfortunate that nobody provides stats for this kind of thing, so we don't have to just rely on "you have seen" vs "I have seen" arguments.


> This has more to do with communication and task choice than anything.

In some cases, task assignment instead of task choice. Sometimes by unluck of the draw, you just get assigned to a shit project with no visibility. You could be Einstein, write entirely bug-free code, and you’re not going to get rewarded for the work.

I’ve seen really mediocre people brown-nose and schmooze themselves onto a rocket ship project that takes off despite their mediocrity, and they get promoted to the moon. That’s how some VP’s and Directors are made. Meanwhile, a literal genius languishes away improving the performance of InvisibleInternalTool by 500%.

The older I get the more I realize how much corporate tech performance evaluation has to do with politics and bullshitting and “being highly visible” and how little it has to do with performance.


Not if output was satisfactory before and then drops


not really, plenty of talented lazy people out there


I don’t think that’s routine. While I know it happens, certainly I’ve personally never worked with someone who this has happened to.

There will always be burning mistakes, or people who lie or are otherwise hard to predict will be a disaster. What else would you propose?


making the interview process similar to the job is a good first step. when I worked at Invitae this was my proudest achievement from my time there. I suggested that we change the interview process to a paired programming session that were situations from our day to day work. the candidate brought in their own laptop or was provided one (their choice). the session was 90-120 minutes and didn’t involve leetcode hard problems, just practical day to day stuff a web developer might run into on the job.


I think this would be the most fair to the candidates, especially ones with prior experience who don’t want to spend time on useless leetcode questions that have zero to do with the job itself. I can’t help but feel this is just gate keeping.


The problem with this is that many jobs require weeks worth of on ramping into internal systems, code bases, etc, not to mention many aspects of the job would be working on otherwise secretive stuff. I don’t think this would work at a FAANG, and many bigger companies.


of course — so you have to make it accessible to the candidate. using the internal code base is probably not the best choice. we had them write up a small API with specific requirements in the tech of their choice, and tried to have someone programming with them familiar with their choice of tech.


I doubt many engineers "lord over the process" - it's seen more as something you volunteer your time for for the good of the company.


What is PIP?


"(Personal|Professional|Performance) Improvement Plan". It's the first formal stage in the firing process at most companies with HR depts, which would almost certainly include any publicly-listed company.

If you're at the PIP stage, it generally means your boss and your superboss have decided that it's time for you to go, but for legal purposes, they need to look like they tried to give you a chance, so they work with HR to craft specific-but-typically-unattainable goals which would theoretically allow you to save your job if you hit them all. But with boss+superboss already wanting you gone, the likelihood that they'll agree you've hit an improvement goal that's usually a thinly-veiled form of "stop me from hating you anymore, lol" is pretty low.

If you get a PIP, in nearly 100% of cases, you should just take it as notice that your employment is going to end at the specified review date in the PIP. It's not usually worth trying to hit the goals. Focus on interviewing.

That said, I once managed an individual who had survived 4 PIPs by the time he reported to me. I heard that he was eventually fired about 2 years after I left, but not sure if it was his 6th or 7th PIP. He was a particular discrimination liability at a company that was very sensitive to that type of thing.


I once was told by an HR person at a prior job, who almost certainly shouldn't have said it, regarding my PIP (I had extremely pathological sleep outcomes sometimes, unpredictably, but my boss and boss's boss etc loved my work), "It's really neat to see - usually when we get people on PIPs, it's because their bosses want them gone, but your boss really really wants to keep you. "

It rather stuck in my mind.

(I also did not, ultimately, end up exiting the company as a result of the PIP, just for completeness given the context of the thread.)


It might be true where you are, but that's not strictly correct everywhere. Here in Australia, if a company wanted to fire an employee, the employee has a chance to sue on an "unfair dismissal" grounds. One of the ways a company can protect against allegations of unfair dismissals is to demonstrate that a) there are genuine performance issues, and b) the company has made good-faith efforts to improve the employee's performance, and that's where the PIP cones in.

This means if an employee here were put on a PIP, it's usually (but not always) the first step towards them being fired.


PIPs are not exclusively foregone conclusion/CYA before firing. I've personally been on a PIP while in the "red zone" before an expected promotion, and came out the other side with an "exceeds" rating and said promotion during the next cycle. Sometimes, it's legitimately just a formal way of stating "this is what we expect from you if you want to stay here"; if you can meet those expectations, then great!


Are you sure that was a PIP? That’s really not what a PIP is used for.


The cover sheet has the words "Performance Improvement Plan", with key goals to achieve in a 30 day period, with the final page to be signed by me and my manager.

https://cdn.n7.gg/pip/pip-1.png

https://cdn.n7.gg/pip/pip-2.png

Not every company is awful.


I wonder what these performance expectations are.


Basically boiled down to:

1) build a plan and make meaningful progress on a high impact, but stalled, project

2) communicate about progress and/or roadblocks to the team, and ask for help where needed to get past said roadblocks

3) be more proactive about finding and proposing high impact work, or areas where others could bring their expertise to help benefit my work or get it done faster

Details are confidential, of course.


In your exp


> it generally means your boss and your superboss have decided that it's time for you to go

The problem is that those are two highly correlated data points. Toxic bosses are eventually found but at that point they leave a track of dead bodies.

What I have seen sometimes is moving around disgruntled employees. It has its own problems but a lot of the times they are recovered and even become very productive again.


> The problem is that those are two highly correlated data points. Toxic bosses are eventually found but at that point they leave a track of dead bodies.

Agree, and this is often overlooked. There's a handful of people I used to admire whose tendency to readily believe whatever's being sold by their middling middle management chain has left me deeply disappointed.

Middle management is a necessary evil, but there's little hope if upper management fails to recognize and subvert its inherent incentive structure.


At the company I work for PiPs _usually_ lead to issues being solved. There are several developers I've worked with on PiPs (we do specific mentoring and follow ups on the areas of concern) that were able to improve and are now doing great. It isn't always a terrible thing, certainly not comfortable for the person on the PiP but it can be a positive thing in the long run!


Good on your company; PIP should focus on shoring up skill gaps or finding better role fit or invinting someone to take unpaid LOA to work through whatever life challenge they have.

BUT, I’ve only ever seen the “unattainable goal” type.


That rules


I was wondering the same thing! After a bit of searching, my best guess is "Performance Improvement Plan".


Performance improvement plan.


Performance improvement plan. It’s basically a social credit rating system for employees.


Isn't that only at a handful of companies?


[flagged]


And yet, when you fail these interview processes it's racism from Chinese or Japanese interviewers. Very interesting. https://news.ycombinator.com/item?id=30520988


Yeah probably because of racism. Can’t prove it and didn’t think of that angel until I saw the discussion from HN.


Objective answer? Pretty much every single sentence is a subjective statement... "I like it,... I don't want... , my job would be awful, ....I can trust...."

And all the two non-subjective statements are provided with "trust me" and 0 data.


I would agree with you if the interview process included ANY feedback to interviewees when they were rejected. Prior to COVID, I got flown to Seattle mid-week for 2 nights and interviewed well (the recruiter told me to start looking for houses). But 20 days later I was basically ghosted by my recruiter and I had to escalate to their manager to get a response that I was rejected. They gave me no feedback at all.

The interview process asks a LOT of the interviewee and then does not provide anything that could help the person improve next time, so the entire process feels like a complete waste of time. In my case, I was also disrespected by the recruiter.

The next time they reached out, I failed the phone screen somehow by someone who sounded 20 years younger than me (which is frustrating when you have already passed these same steps before). I don't respond to Amazon recruiters anymore.


> I failed the phone screen somehow by someone who sounded 20 years younger than me

I am definitely a little pretentious for saying this but I get kinda peeved when I am interviewing for high-level roles and my initial tech screen is by a junior engineer. It's not so much that I think I am too smart to be properly evaluated by them or that they aren't worth being part of a hiring pipeline (they very much should be!), but my opinion is that junior engineers aren't properly tuned for what is and isn't a good engineer and if they are, they shouldn't be a junior engineer.

The other side is when I get reached out to interview for a high-level role then get talked down to about how I don't fit their criteria and I basically wasted the executive vice president of external internal engineering's time.


> but my opinion is that junior engineers aren't properly tuned for what is and isn't a good engineer and if they are, they shouldn't be a junior engineer.

Presumably they aren't instructed to evaluate for that, but instead to identify glaring communication or other interaction issues.


I went through the exact same thing at a big tech company a few weeks ago. Basically told me I got it, ghosted me for weeks, I had to escalate to higher managers, got told a generic “someone was a better match”. Do these companies think about the reputation hit these kinds of things cause? Amazon is the best example - I’m sure half the people on here would never apply to Amazon because their reputation is beyond repair at this point. Some other companies aren’t far behind. They alienate and disrespect people and those are the people that talk and spread the word.


From what I've read from managers of recruiters from FAANG companies is:

1) Recruiters at these companies are under a large amount of pressure to bring candidates in.

2) There is only so much time in the day

3) They feel all of their time must be spent on potential hires because of #1 and #2

4) No one likes giving bad news

I don't feel like any of these reasons excuse you from being a considerate human being. Ultimately, it happens because recruiters are never rewarded for being considerate. People who fail the interview process are treated like legal liabilities.


And the ultimate irony…they send me an e-mail a few days later asking me to take a few minutes to give feedback on their interview process.


> "...I failed the phone screen somehow by someone who sounded 20 years younger than me..."

Consider, possibly, that the mismatch is explained in this sentence.

I will absolutely give high weight to how the receptionist is treated by the candidate.


If you are implying that I was rude to this person, you are mistaken. I treated the interviewer with the same good nature and respect that I would treat anyone. The difference between someone less than 5 years out from school and someone who has been doing this for decades is that, when you are younger, you believe that software engineering skills have anything to do with what you learned in undergrad. I misspoke on a topic that I hadn't thought about for years and I heard the shift in his tone. When I interview people and they miss something that seems obvious to me, I usually give them another chance and think of a new way to ask the question.


> If you are implying that I was rude to this person, you are mistaken.

Nothing rising to the level of implying and certainly not implying rude.

Just, "I failed the phone screen somehow by someone who sounded 20 years younger than me" might be suggestive of something to self-examine.

But since you're confident that you are fully innocent in the interaction and the rejection is solely due to your interlocutor's naivete and inexperience, then it's no doubt true.


At amazon your interviewer is supposed to be >= the job level you're applying for.


> ANY feedback to interviewees when they were rejected

This is a lawyer thing

Without large societal changes to no longer have the US be crazy litigious, no big company will ever give you actionable feedback about your interview.


I’m skeptical. Several times in my career I’ve traced back “it’s a legal restriction” and found that it was not in fact a legal restriction. It was a mutated and distorted version of a legal restriction passed down a game of telephone, in some cases stretching back years.


Legal counsel will almost always give advice based on the worst case scenario. This isn’t reflective of the likelihood of the worst case scenario so, unless they can point to a strong amount of evidence that shows companies being sued and losing for giving feedback, blindly following such advice is just lazy. I’m more inclined to be grateful towards and have more respect for any company that gives me useful feedback than I would be vindictive.


I got some from IBM, of all places, so it's not impossible.


> I’m a HM at a big tech company with this format as well. Honestly, I really like it.

The truth is that nobody likes being interviewed. Getting tested and judged by strangers isn’t fun.

But developers also really don’t like being surrounded by unqualified developers who slipped through a weak interview process. They also don’t like having significant numbers of their teammates fired and replaced all the time because the company had “hire fast, fire fast” interview styles. It’s miserable and slightly terrifying to work at a company where nobody really wants to invest much time into building relationships with new hires because many of them are going to be PIPed out before the year is over.

So while the interviews may not be fun, the reality is that strong developers really appreciate the outcome of such a rigorous process. It also helps protect people from becoming false negatives because they didn’t mesh with a single interviewer or struggled with a single interview problem.

So now we’re at this weird equilibrium where devs simultaneously hate the interview process for themselves but appreciate it being applied to everyone around they (even if it’s not immediately obvious).


> The truth is that nobody likes being interviewed. Getting tested and judged by strangers isn’t fun.

I do. It might be because I'm way better at performing in interviews than in the actual job. It's also way more exciting to do. I have also done interviews on the hiring side of the table, and that's not nearly as enjoyable. However, especially finding people to work with you is quite rewarding.


> the outcome of such a rigorous process. It also helps protect people from becoming false negatives because they didn’t mesh with a single interviewer or struggled with a single interview problem.

Not really. When I was at Google there were tons of candidates that would get passed on because of one of the interviews going badly.


> The truth is that nobody likes being interviewed. Getting tested and judged by strangers isn’t fun.

I sort of do. It's fun problem solving, at least sometimes.


> the outcome of such a rigorous process. It also helps protect people from becoming false negatives because they didn’t mesh with a single interviewer or struggled with a single interview problem.

Only if we assume the managerial class doesn't use this extended process as a chance to do politics and if we assume a longer interview results in better matches.

My experience in casting actors (different field I know) is, that after a certain duration you will get diminishing results. You can tell most of the time within an 20 minutes or less of someone could do the job or not. The rest of the hour is needed to figure out how they work in different situations.

What I would never do is have my existing actors interview them. They can veto someone, they can tell me what they think, but why on earth would I let them interview someone?


Funny, last time around it wasn't the interviewing that got to me, but the nightmare of lining up and going through interviews while also having a young baby and working full time. I remember working during the baby's naps on the weekend and then doing take home quizzes / online tests at like 10pm and like, barely scraping through.

I considered applying for Google at the time, but the combination of the famously arduous interview process, AFAIK both in terms of the time taken and difficulty (for which the recruiter recommended taking further studies in advanced data structures and algorithms) meant that attempting it would be silly.


> nobody really wants to invest much time into building relationships with new hires because many of them are going.

That's what a "farm team" is for, developing folks with a growth mindset. Never thought of it as either miserable or terrifying.


“Is it annoying for candidates?” Not just annoying, it can be downright demoralizing going through the interview process when the standard is “reject for any one reason, only accept if all agree.” and no feedback whatsoever is given.


Also the fact that hiring almost ends up looking to the most senior engineers for up and down which means you've just wasted multiple hours having less senior people interview them.

Rarely have I ever seen a candidate be rejected by seniors or leads and still get the job even when the decision had to be argued until it was unanimous. Pretty much if a senior goes thumbs down, the decision has been made and the meeting is over.

Leads and CTOs especially have to be mindful of either not being part of the decision or being the last vote, as to not taint the results... which again, means that the most senior vote will flip a "yes" to a flat "no"


That is a fair point, thank you for commenting.

Discussing how many no’s it should take to reject a candidate is a worthwhile discussion. I can override specific no’s with good reason at my company, but not all companies have that.

My broader point is that this is a specific issue with the process we can iterate on. We don’t need to throw out the whole process.


There is another thing - if you want to work at a FAANG, presumably you want to be there a while. Anyone who can't put up with a little bit of nonsense and headache for something meaningful is likely to struggle with any nonsense and headache generally. Working on any large scale project at a FAANG is going to involve a decent amount of nonsense and headache, and you gotta roll with it.

And then on the flip side - if you are really a star, and you are interviewing at a small company you should want 5-7 interviews to gauge the caliber of people you will work with.


Maybe it's an age thing, because I've already hit 40, but doing 5-7 interviews seems like time lost for all the people involved. If a company cannot decide after 1-2 interviews if the person they're trying to hire it's worth the effort or not then it means it has lost its golden touch, especially in this industry. And vice-versa, if, as a potential employee, you don't "sense" your employer after 1-2 meetings then it means it's not meant to be.

Case in point, all these FAANG companies which pride themselves in doing 6-7 interviews, they all are spitting out shitty product after shitty product (that is when they're launching any new products at all). Exceptions do exist, I know of that, and when do they show up everyone is so surprised (see Apple and M1 recently). The pay at these companies is also very good, that is correct, but it's not correlated with the quality of the people who work for them or to how their talents are put to work. More exactly, a company so immersed in bureaucracy that it needs this amount of work to hire just one person is sure to waste the talent that it already has at its disposal.


This is my conclusion as well: exluding total unusual cases, where three candidates are all equally good and you can't decide: not beeing able to tell whether a candidate fits after more than two interviews tells more about the company than the interview.


I agree with this. Honestly, as a candidate, I don't mind the longer interview loop. What I do mind is if it's very spread out. I'm willing to invest an hour up front + a full day round, but I don't want that longer round spread out over the course of multiple days. I'll give you 6 hours in a day, but not 2-3 days of 2-3 hours each.

My expectation at this point is:

Pre-onsite:

- 15 minute with a recruiter, tell me a little bit about the role, spend the majority of the time telling me why I should join the company, and take a few questions

- 30-45 minutes with the hiring manager. Tell me about what you really want, scope, the challenges, and let's talk about how I might fit. Do enough Q&A both ways to feel comfortable, and then let's make a call right there as to whether we want to continue on. For my part, I always tell the HM at this stage whether or not I'd be excited to continue.

Up to now, I've invested an hour. This is reasonable. Maybe we both like each other, so presuming we do, when you call me about the on-site, we should work out acceptable comp ranges. These may move upward after the on-site based on what I learn about the role, but let's make sure we won't waste one anothers' time with the on-site.

Continuing to the on-site:

- 60-90 mins on whatever technical background is required for the role. I'm fairly senior in management, so this usually doesn't involve code, but should cover whether or not I have a clue how to lead it. For an IC technical role, if we're smart about it, we'll know enough without doing 5X leetcode and 3X design here. I can also evaluate whether I care about your problem space if we don't make the content entirely synthetic. In 90 minutes, it's perfectly reasonable to do a design exercise + picking something in there to write some code around. This is it, though. One technical round!

- 30 mins x 3-4 with key peers/stakeholders. Make sure my behavioral stuff works for you, that we can understand one another, and yeah, that we might actually like each other enough to work together. I like to talk, and so if the other person does, make it 45 mins.

- 60 mins with the HM again to dive deeper on the role with the context gained from the interviews. Heavy Q&A. Let's give each other enough to make a decision.

- If you want, 60 minutes with whatever executive (besides the HM) will be closest to the role. Whatever you want to talk about. Let's just see if we can communicate.

You can cut this to half a day if you cut your most efficient interviewers down to 45 mins and don't overdo it with peer/stakeholder interviews, but I'd rather make it a full day with some breaks. This is because I need time to interview you, and that mostly happens after you've run through your things in each interview. We should all have enough information to decide here, and I'm not taking the on-site anyway if the first hour we had together didn't generate strong interest, right?

After this, call me within a couple of days, let me know if we're doing an offer or not. If we are, let's confirm expectations. The only things that will offend me at this point is if we're not in the ranges we previously discussed, or you want to do more rounds. I'm open to one more if there's a good reason for it (not wanting to use that person's time for the on-site is not a good reason). But we've had a day together. While one day is not necessarily enough to know for sure that things will work well long-term, even another full day isn't going to change anything about that.

Also, while the focus of the original post is mostly critical of the lengthy process and it being annoying to candidates, there's also the reality that the longer the loop, the fewer candidate throughput the hiring manager can have. There are only so many interview cycles per week before an interviewer burns out on it or can't get their job done as well. I'd argue that if you stretch these things out to a day, you will think harder about who you are bringing on-site.

If we agree for the most part that the time together wasn't nonsense and a headache, as you put it, that's a good indicator that we should work together!

tl;dr - I'm fine with 7 interviews if they're the right 7 interviews and planned thoughtfully.


> Honestly, as a candidate, I don't mind the longer interview loop. What I do mind is if it's very spread out.

As a candidate, I would also be wondering what it would be like to work for a company with a spread out interview process. I have been through multistage interviews, but decisions were always made quickly. Made it to the end of the phone screening, at the end of the conversation there is an offer to be flown out for a panel interview. Made it past an interview with the IT manager, then head straight down to someone else to discuss software development. Made it past the interview with the lead scientist, then head straight down to the lab to see the lab and meet the research team. Even though I was in my prime, I was by no means special and I only secured some of the positions I applied for. Yet I always knew one way or another within days. I was happy to work for those who I did get hired by and I would have been proud to be hired by those who declined.

Thankfully, I have never had to endure a strung out interview process. Because of that, I don't know how I would feel in such a situation. Yet looking at the prospect from afar, it leads me to believe that it would be difficult to work in such an environment: it would involve dealing with people who are more concerned about process than decisions, and with people who are not available when decisions need to be made (or even for process to be followed).


I’ve been employed by everyone from small consulting firms to big tech to FAANG and I’ve never seen anyone let go for performance. This includes serial low performers that produced nothing for years. Aside from a very few (like 1 or 2) select companies, the bar to staying employed is laughably low in tech.

In my opinion this is a big problem. I wish there was a stronger culture of letting low performers go quickly in tech. This would reduce the need for exhaustive interview loops and ultimately make the industry more inclusive because you could afford to take a chance on someone without being chained to them for years to come.


> Is it annoying for candidates? Yeah, but we pay you a lot of money

I had to go through 8 interviews for a senior position at Facebook and ended up not getting the offer. I wasn't paid a dime and had to use a few vacation days at the job I had at the time in order to take the interviews. Technically I lost money interviewing at FB.


I went through the same interview for senior at Facebook and failed. Thankfully I got a Google offer a couple of hours after I got my Facebook rejection.

What pushed me over the bar for Google was probably making fewer mistakes on the technical loops but also having more people vouch for me on the inside (they like refs that work at Google).


Yep that's similar to how I got my current job. Strong referral from someone else inside the company, we had worked together for about 4 years. I had one phone screen which was a combination "culture fit" and general talking about my experience programming. One technical interview which was way less abstract than the FB ones. And a final meet-the-team interview which was more of a hangout.

The pay isn't Facebook-tier but is still pretty darn good, and I'm enjoying it a lot, which I'm not sure I would have at Facebook. It was probably the better path for me overall.


In over 20 years, I've never used vacation days for an interview. I just either 1) called in sick, 2) needed to stay home waiting for a repair person (your internet is having trouble!), 3) had a few doctor's appointments. With working from home, fewer of these excuses are necessary. Last couple jobs I'd just disappear for an hour here and there. Nobody notices.


Multiple interviews is annoying as a candidate, but how they are used (or appear to be used) is the bigger problem. Instead of being used to strengthen a consensus they tend to be a series of filters where any "fail" invalidates everyone else's input. After all, why hire someone who everyone doesn't love? But that is the same logic as combining bad mortgages into tranches reduces their risk - sounds good on paper but doesn't work in reality.

Since you have a chance of getting cut at each round as an interviewee you are left hoping not to run into: some esoteric corner of programming you could learn in 10 minutes but haven't seen before; an interviewer who always asks a pet question (even if told not to do this); a personal dislike that is illegal but not challenged (age, gender, race, etc., waved away as "a bad fit").

If multiple interviews were used only to strengthen assumptions about a candidate and each interview had a narrow intent, they COULD help companies avoid more bad hires. But after interview #3 you are probably just filtering reasonable or even exceptional candidates based on random chance.

On the other hand, this may be a fantastic method to strengthen a "hive mind" culture, but that doesn't sound like a worthy goal.


It may work well for hiring young people.

I can guarantee that you will never see me in one of your interviews. Would I be valuable to your company? Maybe, but we will never know because the process is too long.


On one hand, I don’t want to ever get hired for a position and in a culture where I am not a match, so I myself believe that the more datapoints, the better.

On the other hand, I struggle with impostor syndrome. While fairly successful in my day-to-day, I will likely fail whiteboarding sorting algorithms etc. Imagining a series of five interviews stresses me out and I’m not even looking right now :)


> That makes my sell interview so much easier because I can trust the process to assess their technical skills

What makes you think that the process provides an accurate representation of the skills needed for the day to day job? In my experience it simply tests whether the candidate has invested lot of time cramming for that very specific type of test. If I was running a small company I would much rather discuss a candidate's experience with them and leave them the time to build useful skills, not worthless ones for passing a test.


> Is it annoying for candidates? Yeah, but we pay you a lot of money, and it does actually work for us

The best candidates can get jobs paying the same or more money with fewer interviews, so the very best aren’t going to pick you.


I'd be very suprised if this is the case, I just finished a few months of interviewing and very few places outside very small startups deviate from this format.

Not saying I am the very best, but I just didn't find opportunities for anyone to out earn by skipping the FAANG style loop. Unless you mean getting lots of equity and riding it to an outsized liquidity event, these places just tend to be not competitive to the top FAANG compensation; you would join for other reasons.


Top engineers are often recruited by people they worked with before, and aren’t going through the normal interview process.


Yeah, but the worst will also have an easier time. Missing out on a great developer is still a good deal if you also prevent 10 mishires.


> Is it annoying for candidates? Yeah, but we pay you a lot of money, and it does actually work for us. Is it perfect? No, but it does work.

I've never been paid for interviewing. You mean you pay the successful candidates well, which is what? 10% of the people you subject to this obnoxious process?


My FAANG team does 2x screening interviews plus a round of 3 to 4 full interviews. We try to interview at most 4 candidates in the full loop. That’s about 5 hours of interview time, and the average candidate will succeed by the 3rd or 4th interview.

Given that we are making a $200-600k+ decision and that the average candidate stands to gain tens of thousands of dollars or more, the 20-40 hours spent interviewing seems time well spent on both sides.


> and the average candidate will succeed by the 3rd or 4th interview.

What does this mean? It seems unlikely that the average candidate succeeds at all.


Is it annoying for candidates? Yeah, but we pay you a lot of money

Well, no you don't. You pay a lot of money only the people you hired.


However what does a hiring process like this communicate to those being hired?

I had more than one interview, where the things I discovered during the interview made me reconsider my options and go for another company. Not because I wouldn't have fit with the team or my skills were not there, but because this kind of thing tells me how processes are organized or not organized within your company, how people treat each other etc.

What candidates does a hiring process like this drive away? Are it specific character traits that pass through the sieve? If yes, how will that shape your corp and the culture in it in the long term?


Yeah, but we pay you a lot of money, and it does actually work for us

I just want to highlight that this works specifically because there are a very finite number of these we pay you a lot of money companies competing for talent and that's the primary reason candidates put up with this [expletive deleted] treatment. And the result are beneficial for these companies, yes.


I'm a HM at a big tech company as well. We do 3 one hour slots.

In a previous company we pair interviewed, 1/2 hour screen + 2 one hour slots. I liked that format a little bit better.

I've been interviewing people for about 40 years now, I was just reflecting on my first ever interview that I participated in when I was still a teenager.

I would say there are some factors that are not going to come out in any number of interviews. Conversely there are factors that are immediately noticeable.

I can tell in 10-15 minutes how strong someone is technically. At least I can tell the difference between "weak", "maybe", "strong" in 10 minutes.

Going back to my first ever interview. The guy was brilliant. He was technically good. He ended up being a not so good hire for reasons that would have been very hard to discover during the interview. It was partly the intersection of very smart without the experience to match and partly that he was just weird in some other ways. He was hired, he left within a year or so.

I think the science says the best predictor is an IQ test. The rest of our practices are not really evidence based. We tend to want to hire people that are like us, that know the things we know, we have all sorts of biases during the interview process, and throwing more people/time at it doesn't really seem to make a big difference.

I would say the most important thing you can do to get good people is to make your company a place that good people want to be. I.e. what matters is more what enters the pipeline then the interview process. I would bet that having 7 interviews vs. 3 has a difference that's completely in the noise and that at least there's no solid evidence that it gets you anything re: the quality of people working in a company. Every company says it has the best people. Mostly channeling Joel Spolsky here but I've seen this principle in action.

EDIT: Another random thought is that there are other factors that influence whether someone is going to be successful in a given role. Even the best software engineer can fail if the conditions for him to be successful aren't there.


Anecdotal, but I am a HM. The process goes I review cvs with senior engineers, we filter, 1 tech interview to validate cv, one with me to validate decision. Done. 3rd interview only for someone who would be a HM themselves. To be fair, if we could validate that cv is accurate we would not even need the interviews. Junior people are our responsibility to develop, senior you can understand their fit with some key indicators. I believe the detail in recruitment either reflects lack of trust in team or focus on accurate placement of people, which does not lineup with my expectations about how a team of creative people should be run.


Are candidates paid for their time when doing such extensive interviews? Doing 7 rounds, including preparation and travel time, may well add up to a full week.


You pay them a lot of money if they pass, but the others get zero. You’re basically annoying lots of people to make that one person happy.


You can take something out from an interview: practice for other interviews, insight of how others interview (what did you think were good or bad questions, what annoyed you). I know it's not the best use of your time but it's better than a total waste


How do you know that it actually works? Are there formal studies that compare different approaches? (it doesn't look like the difference can be easily evaluated and therefore it is extremely easy to mislead yourself on the effectiveness of some baroque process)


> Is it perfect? No, but it does work.

How do you know it works?

> I don’t want to hire the wrong person, it’s expensive and it makes my job awful for a while.

There we are. It is all about you.

No need to say anything else - your life is all about you, so of course if it works for you, 'it works'.


No, it's all about everyone. If I hire a person and fire them in less than a year, that's almost always because of a performance problem that's impacting the team or the org. If you're the one being fired, you probably left a job or didn't take some other job to work with us and now you're going to be unemployed. Additionally, as a hiring manager, I too am a human who wants to enjoy my job and have positive experiences and firing people sucks. It always sucks. It takes a toll on you.

Filtering early is best for everyone. If that means more rounds of interviews to be sure, that's what I'm going to do. I do my best to schedule around candidates and I'm forthcoming about the process during the first call but we try hard to be thorough because we want this to work well for everyone. Would you rather be hired and then fired quickly because we didn't realize there was a misalignment? I wouldn't.


> Would you rather be hired and then fired quickly because we didn't realize there was a misalignment? I wouldn't.

The fact that your knee jerk reaction to a misalignment is firing someone rather than mentoring them and aligning them with the org speaks volumes about your management style… And managers wonder why they have such a hard time hiring or retaining people right now…


They want to outsource the costs of developing talent. To their own detriment, then they want to blame everyone else.

This is of course when they're not busy abusing someone on a visa to make them do more work than a human should have to do.


You've had some bad jobs, haven't you? Want to talk about it? We don't abuse anyone on a visa because we're fully remote and don't do visas. We target the high side of comp in the person's country. We specifically hire senior people because we're small and building. Developing talent is great but the time to do that is expensive and until you've hit a certain scale, it's detrimental to launching a startup. Look around the industry and look at the success stories. Then look at what their early hiring looks like. If you can find a startup that succeeded by hiring new grads and junior engineering first, I'd love to read about it.


> If you can find a startup that succeeded by hiring new grads and junior engineering first, I'd love to read about it.

Mentoring is not something that's only done for new grads and juniors.

Wherever there are skilled people in the company interested in learning more about the systems around them and how to work with them well, it's generally a good idea to figure out some way to mentor/grow them. Whether officially, nor unofficially.

For non-technical roles it's likely a good idea to do the same in ways that suit there as well.


I used "misalignment" as a kind way to say "because we realized we don't want to work with you." But you're chasing a different thread anyway. We're talking about quick hiring and firing being better than thoroughly vetting a candidate. If we want to talk about how to hire junior engineering talents specifical, we can do that.

I definitely spend less time per person, trying to find juniors. You have to because t What you're looking for is different. My only goal for hiring junior engineers is to find out if they know enough to not drown and if I think they're willing and able to learn fast. That takes less time and the risk is generally less because my expectations are lower and so is the compensation.

It's been a while since I hired junior people though. The roles I take are always in early phase startups and I don't have budget for people who need on-the-job training.


> thoroughly vetting a candidate

Either you work at startups or you thoroughly vet candidates, not both.


I agree that bad hires should be avoided and that filtering early is best for everyone. The question is whether a stretched out interview process is the most effective way to filter out misalignments.

Interviews may be the best tool available while searching for unknown talent, but that does not mean they are a good tool. The process is artificial, no matter how much effort is put into framing it otherwise. Even the most honest interviewee will have difficulty behaving as they would in a normal working environment, while many are more than willing to be actors playing a part. Likewise, interviewers are interacting with the interviewee in an unnatural way and are making judgements about the interviewee in a fashion different from making a judgement of a colleague.

Even if one could somehow get beyond that artificiality, what sort of impression does it leave the candidate with? There is a world of a difference between working for a company that is careful and one that is bureaucratic, one that is focussed upon making sound decisions and one that simply follows process. It can also leave the impression that key decision makers are difficult to access, making it more difficult to get the actual meat of the work done.

As for competing for the best employees, a drawn out process doesn't benefit anyone and is the least detrimental to companies that offer a genuine competitive advantage. Keep in mind, that candidate may already be part way through the interview process at another company (or even offered a position) by the time an they are offered the first interview at your company. While both parties form impressions of the other during the interview, the candidate will gain more insight about the company's functioning in how they handle the hiring process than the other way around.


It's not "best for everyone."

Hired and fired quickly is better because when I have to dedicate weeks or a month of unpaid, uncompensated time to your process then I'm the one losing. You are already getting paid for putting in the work of interviewing me. If your team is stretched so thin that you need to put your time at a premium, that's a problem with your process not having enough throughput.

How many people do you reject to fill one position? How many are "filtered" at later stages to fill one position?


If it's taking months, then they're doing it badly. Our hiring process is five rounds but it never takes more than a couple weeks, including the negotiation phase. Our data shows that we need something like 14 resumes to get one candidate worth interviewing. Of those, it takes 4-6 candidates for one hire. Hiring and firing fast means we also have to invest in onboarding, training and allowing people to settle in. During that time, we've filled the current position and we're no longer interviewing candidates. Once someone is fired, we have to go through the whole mess again. That would be the most wasteful model for everyone involved. By my math, that's a minimum of two months of time on a single person (I think six weeks to fully productive is reasonable) just to go back to searching again. And that's just the US and ignores the two week notice (or more) for each candidate.

I hire in APAC too. Indian engineers are giving 60-90 day notices now and that's contractual. Two candidates, using your model, could easily take up a year. (Hiring in APAC take a long time already.)

I can only assume you've had some bad experiences lately but your personal bias has created a really bad mental model for you that would be a net negative for everyone.


> If it's taking months, then they're doing it badly.

is not responsive to

> I have to dedicate weeks or a month


Sure it is. If a company's hiring process for a single candidate takes multiple months, that's bad. The candidate experience is critically important. We have five stages of our interview process, two of them involve speaking with multiple engineers. The whole process takes less than a month, as long as the candidate has time. In general, it's 2-2.5 weeks and that involves coordinating calls with engineers in the Americas, Europe and APAC.

If it takes longer, it's always an issue with coordinating with the candidate schedule. (this is my experience with my hiring process)


No it sure isn't because I never said months or multiple months.


Fine. I'm mixing replies. A single month is still unreasonable. That's a bad candidate experience. That changes nothing about the number of people who interview you though, just how quickly.


Well due to real world constraints of scheduling even with people who's sole job is to interview candidates the speed at which you interview is most likely going to be a function of how many people need to interview you.


> Filtering early is best for everyone.

This is a lie that everyone tells themselves to make them feel secure and safe.

The best interview is working with the person. Do a few basic interviews for competency, give them a 2 week - month long 1099 contract and put them on guard rails for the contract duration.

Their daily work isn't just about whether they can jump through time-based hoops or answer basic questions. No one is going to know whether it is a mutual match until the person gets into the codebase and start working.

Plenty of great engineers have "performance problems" not because they are bad engineers but because of problems an interview will never expose or detect like a bad teammate or lead match causing disagreements, a bad codebase, poor planning that only builds tech debt, bad business plan, disagreement on business direction, etc.

The idea that an interview can filter good or bad engineers is laughable. The most you can determine from an interview, regardless of how many flaming hoops and balls the candidate bounces off their nose, is whether they know how to code and _probably_ know what you need them to know.


But why would I as a candidate leave my full time job to do a month long 1099 contract?


> The most you can determine from an interview, regardless of how many flaming hoops and balls the candidate bounces off their nose, is whether they know how to code

When I interview I don't even mention code or technical stuff (that is for someone else to ask) and I am able to learn quite a bit about a person and if they would be a good fit. Just because you can't doesn't mean other people can't.


If I could get a job in a week instead of 3 months of interviews? Yeah I'd be fine with that.


A week for a single candidate interviewing with a US only company is entirely reasonable. I don't think two is bad either. I would not stay engaged with a company that took a month, the same way I don't stay engaged with a candidate that can't find time to schedule three or four calls in less than six weeks (I am more forgiving with candidates than I would be with companies).


> How do you know it works?

If the company in question is growing its business and the employees and customers are happy, then whatever they are doing is working, at least for now. I'm not sure there is a much better way to measure it.

When I joined NVidia they had me through two phone screens (although they originally planned for three), followed by an onsite with seven different interviewers back to back on the same day. It wasn't fun, but it wasn't the end of the world either.

When I was a hiring manager at Qualcomm we would typically do a phone screen followed by an onsite with maybe four one-hour interviews back to back and there was rarely any disagreement on whether the candidate made the cut or not, so I would argue that it was sufficient.


> How do you know it works?

Because the hallways aren't empty.


the hallways aren’t empty due to the total compensation and perceived prestige working at a FAANG or similar company offers.


I had a startup give me 2 interviews and a paid coding exercise before making an offer, but the compensation was below market with some long shot equity comp. I had a large consulting company give me one recruiter screen and a series of 3 20 minute interviews, one tech one manager and one in between before making an offer at market rate. Sounds like generally interview time scales with total compensation, which seems fine to me. I’m a data scientist and I’ve never had a live coding interview but I also have no desire to apply to a top tier tech co.


Then there isn’t a problem — at least for FAANG. People are willing to jump through more hoops for more rewards in all aspects of life.

If a less prestigious company with worse compensation tries the same thing, then they will quickly discover they can’t hire anyone. It will be self-correcting.


Sounds like you're agreeing with me in disagreeing tones


due to the total compensation

Yes..it's why people do jobs.


Probably not as much as you would guess from talking to FAANG employees. It’s been fifteen years since my compensation exceeded the amount where it makes any difference to me. Now I want to have interesting problems, a business model I am not ashamed of, good and smart coworkers and decent conditions. I won’t be retiring early, which is fine: my work is almost always a fun and valued way I contribute to the world. One of the big problems with software ethics and the joy of solving problems is the influx of people choosing software not due to intrinsic affinity but just for money. Sometimes I wish more of them still went for law degrees or MBAs or surgery. It’s just a little sad to see someone who can make beautiful and useful software gems be dissatisfied because they didn’t get to be a CTO by the time they are thirty or the like.

In the 90s people getting a big software job where thrilled because they were going to change the world. My mom’s friends used stuff that ran my code. Now it seems like people want FIRE or multiple houses or lambos.


> First: we no longer trust the hiring manager alone, because probably they aren't a strong developer

This is a huge problem IMHO. I topped out at L7 on the FAANG EM track, but that’s dozens of ICs and a few EMs in your org and I still think you need to be able to build the software and review diffs and write serious ones now and again. Clearly this is now only part of your job, not the focus of it, but it’s very difficult to manage a process that you don’t understand with some sophistication.

In everything from law to management consulting to steel fabrication: the person in charge is the most knowledgeable person. Carmack is the best hacker, Mike Krieger wrote code. Hell pg wrote this site and the language it’s written in while building the most successful early-stage investment firm in the world.

Obviously directors and VPs and CEOs are delegating the details at same point, but this idea that an L6 manager shouldn’t need to seriously understand the subject matter seems wrong to me both in principle and based on watching it go to hell countless times.


An L6 manager and an L6 IC do different work though. And it's rarely (read: never) the case that the person in charge is most knowledgeable about all the details.

If an L6 manager could keep all of the details of all of the things all their reports are working on organized, they aren't handling enough scope. Imo that's the difference between 5 and 6. You can no longer track all the details in one person's head.


The most knowledgeable person doesn't always have the title but they are usually the head of the shadow org that actually gets the job done.


> If an L6 manager could keep all of the details of all of the things all their reports are working...

That's not what they said, is it? There is a huge difference between what they said and how you interpreted it. They said "you need to be able to build the software and review diffs and write serious ones now and again" and "it’s very difficult to manage a process that you don’t understand with some sophistication" (emphasis mine). How do you get 'know every little detail about everything' from that?

It seems obviously true to me that any manager who can't "build the software", "review diffs", and "write serious [diffs] from time to time" is useless. Anyone who disagrees with this is probably dead wood, spends their time fighting political wars about issues they don't understand, and their team is more likely than not constantly fire fighting and in serious trouble (in my opinion).

If I had a dollar for every time some clueless manager lectured me about how to write software, and I rolled my eyes and ignored them, and they never found out (because they had no idea what was going on to begin with, and were just posturing based on something someone said) I would have at least $100. I obviously have a chip on my shoulder here, but managers who barely know what is going on still tend to want to 'contribute', which of course they can't do in reality, so they end up playing keyword matching and 'helping' the team avoid 'duplicate effort'. For example, they will see one team building something, and another team building something, and notice some of the words are the same, and then make a big show of 'avoiding duplicate work', but in reality the use cases are extremely different and nothing was being duplicated. Once they have alienated enough of the team, people just start telling them nonsense and they have no way to know it. Productive, smart people start to leave or lose motivation. A fast pace is replaced with constant excuses and a team that is basically no longer showing up for work. The manager can't tell the difference. This is what managers who aren't in the details are like, pretty much without exception.


You seemed to skip their second paragraph, which is what I was replying to.

Someone who can review diffs and even write a serious change every now and again isn't the most knowledgeable person on the team. The person who is writing and reviewing all of the serious diffs is. And for many L6 EMs, you'll have three of those people reporting to you, they're all working on different projects, each of which you have partial but imprecise knowledge of (and sometimes, very little because L5s and FAANG are expected to be able to operate mostly independently). So you spend your time ensuring that everyone on the team has career growth opportunities, and that your less experienced people have mentorship, and hiring and arguing about headcount allocation and prioritization, which all matter, but which are all things that most engineers don't want to touch!

Yes, managers should still have engineering experience (at least up to like director/vp levels, where IDK maybe they don't need it) but having a baseline knowledge of how to do a software is not the same as being the most knowledgeable person on the team.


I made a concrete statement about what I think the minimum technical bar for EMs is up to at least L7. I also remarked that "clearly this isn't your main focus" at that seniority, which you seemed to skip.

The second paragraph, the one you seem to have an issue with, a combination of 2 things:

- a few examples of extremely senior, extremely successful engineering leaders who stayed at or near the top of the game technically, and those are but a few examples from a very long list

- an observation that in other fields, law for example, they call in the highly-knowledgable, highly-expensive, person capable of solving problems few in anyone else in the organization can and that this person carries titles like "partner" and makes the most money.

I know this is a touchy subject and I've been trying to be less flamey on HN so I didn't go hard like the GP, but they're fundamentally right even if the language is a bit intemperate: there is a prestigious and important job track for people who are pretty damned technical/quantitative but not wildly hands-on and generally concerned as much or more with coordination and communication, particularly in cross-functional or externally-facing scenarios than software systems per se: product manager. As a wild oversimplification: when an EM becomes senior enough they end up as a CTO, and when a PM becomes senior enough they end up as a CEO. This is natural and healthy division of labor.

An EM is concerned first and foremost with the health, happiness, and therefore productivity of engineers. On the foundation of the trust and rapport and deep knowledge that comes from that kind of engagement with their team, they are able to also be concerned with how their team fits into the bigger business picture: is this the right team for the needs of the business, what hiring and performance management would be necessary to make it so if not, what is a realistic schedule for the work that needs to be done given the strengths and weakness of the team members both generally and at this moment in time?

When I'm wearing my hacker hat I have no interest in reporting to an EM who couldn't do my job in a pinch, I might respect that person on a lot of levels but I won't be interested in their opinion of how I should do my job. And at no time in my career has it been so easy to identify such managers: they are the "back to the office damn the torpedos" crowd. When the task tool, and the code review tool, and the oncall/incident situation, and the build wiki are not sufficiently comprehensible to an EM to form an opinion of who is doing a good job, the instinct to do "ass-in-seat" performance evaluation is strong, the instinct to be "visible" is strong, and narrative that there's value add looks very threadbare over Zoom.

This bloc is probably too big and too entrenched to dislodge, but WFH for 2 years working out just fine is the best chance we're going to get. IMHO.


> - a few examples of extremely senior, extremely successful engineering leaders who stayed at or near the top of the game technically, and those are but a few examples from a very long list

But all of these are the exception, not the norm. You said you've been in a FAANG style org, so you've been able to view the org-chart. For every Jeff Dean or John Carmack, there's three-dozen directors and VPs who manage large orgs whose names you've never heard of and who haven't checked in code in half a decade. They're still usually very good managers.

(A reasonable opinion I've seen, btw is that if you're managing a team of say 5 or more people, if you have time to make regular code contributions,you probably aren't focusing enough on your other managerial responsibilities and are letting your reports down)

> - an observation that in other fields, law for example, they call in the highly-knowledgable, highly-expensive, person capable of solving problems few in anyone else in the organization can and that this person carries titles like "partner" and makes the most money.

This is pseudo-true. Partners are called partners not because they're capable of solving problems no one else can, but because they carry an ownership stake, and I'm not a lawyer (and presumably neither are you) but the impression I get is that law is far more delegatory than software, where a partner may call in some favors to address a problem, but will also have 20 Jr. associates investigate 20 different possible approaches and write 20 different briefs to then choose between.

> When I'm wearing my hacker hat I have no interest in reporting to an EM who couldn't do my job in a pinch,

Maybe we have different definitions here, but I've never, or perhaps once, had a manager who I felt could do my job in a pinch, and I was a new grad and he was the worst manager I've had at the time (although he very quickly got better as he learned to be more hands off). A manager who could do my job in a pinch is too micromanaging. Maybe you mean something different in that they could, given a week or two to turn-up on the project take over, but that's not really what I'd consider "in a pinch".


> Maybe we have different definitions here, but I've never, or perhaps once, had a manager who I felt could do my job in a pinch,

The chief of Air Force still flies the fighter jets just as well as the junior pilots. The head of surgery in a hospital still operate just as the junior surgeon. Why does tech have to be different?


An air force officer may have to qualify on their aircraft each year, but they're unlikely to be "the most experienced" fighter pilot, and it's common in the military for enlisted people to make fun of officers for being too abstracted away from the life of a soldier.

> The head of surgery in a hospital still operate just as the junior surgeon. Why does tech have to be different?

Because the load we put on medical personal is abusive and we shouldn't copy it in tech?


You've got some reasonable points and I don't just want to completely gang-tackle you here, but there is a part of your argument that I think is sufficiently incorrect in a sufficiently harmful way that I'm going to sort of keep at you about it, in what I hope is an open-minded or at least respectful way.

Some people like the book "Coders at Work" (I do), some do not, but almost anyone would agree that the people interviewed are absolute luminaries [0].

There are 15 chapters comprising 15 interviews. You have to get to #6, arguably #7 before you find someone who at the time of writing wasn't both a world-renowned hacker and currently or at one time a demonstrably successful engineering leader. The first 5 being: jwz, Brad Fitzpatrick, Douglas Crockford, Brendan Eich, Joshua Bloch. It starts to get a little blurry in the second half because it's so thick with CS academics (who in a different way also do engineering management), but you've still got VP-types who still code like Peter Norvig. The ~50% who aren't demonstrated engineering leaders are super hard-core CS researchers like Donald Knuth. The book doesn't even interview Cliff Click, or John Carmack, or talk about the fact that Larry Page and Sergey Brin wrote the first version of Google themselves and continued maintaining parts of it well into hyper-growth. Eric Schmidt wrote `lex`. When Jack Dorsey was recruiting me for Square over lunch he made an incredibly eloquent argument about why he uses OCaml rather than Haskell for his personal hacking.

At the time I was an L7 EM, my L9 boss didn't have much time to write code, but asked probing questions about everything from the merits of various binary classifiers given imbalanced underlying Bernoulli distributions to the algebraic properties of the data structures we were using for distributed systems convergence.

I don't dispute that plenty of successful leaders in technical organizations have become rusty as hackers when they hit the mega-seniority, but the idea that some L6/L7 manager shouldn't be able to lift some of their team's serious code off the ground, let alone some undergraduate dynamic-programming interview question as was the original point of my original post is simply contradicted by a mountain of evidence both generally-available and anecdotal to numerous people in this thread.

You can get ahead as a mid-level EM without knowing the frib-frobs from that whatsits, but God-willing I'll never work for one again. That's a visibility game, it's a popularity game, it's a schedule-too-many-meetings game, it's a post-too-much-on-the-internal thing game. Fuck that game.

[0] https://www.oreilly.com/library/view/coders-at-work/97814302...


> I don't dispute that plenty of successful leaders in technical organizations have become rusty as hackers when they hit the mega-seniority, but the idea that some L6/L7 manager shouldn't be able to lift some of their team's serious code off the ground, let alone some undergraduate dynamic-programming interview question as was the original point of my original post is simply contradicted by a mountain of evidence both generally-available and anecdotal to numerous people in this thread.

I think this is the root of the disagreement. I want my managers to be technically capable with an engineering background. As far as I know, my entire leadership chain, arguably excepting my SVP and CEO (at Google) have such a background. Yes they should be able to pass a tech screening and certainly system design.

They should have enough knowlege to know why you're making certain technical decisions and be able to see that you're justifying them well. That's all true. What I'm saying is that a manager who is staying so deeply aware of the details of all of their reports work that they can drop in and take over in a pinch probably has too much context. I'm not making an argument on abstract technical ability or knowhow.

Like in the same way that my entire management chain has technical knowlege and background, practically none of them have submitted code at work in the last 3-4 years at minimum, for some that's their entire career at Google. I expect that, with enough effort they could all work on the projects I work on and make contributions, but they'd need to learn all of {language and codestyle, libraries and relevant tactical design patterns and norms, various technical constraints to the design that are important but nonobvious}, so in most cases it would be similar to onboarding someone who was a technical contributor from another team or an experienced new hire. I don't really consider some random employee of Facebook to be someone who could "do my job in a pinch" either, even if they're more technically competent than I am.


> and I still think you need to be able to build the software and review diffs and write serious ones now and again.

I've had some good managers that could do that. But the people management skill set is so much more important to their job. And it's a very different skill set to being an IC.

I wouldn't argue in favour of engineering managers with no technical skills at all, but I also don't think it's fair to demand they be masters of both the IC skills and the people management skills too. It's very difficult to be good at both.


Do people call it a diff in the rest of AANG?


I think it's called "changeset" at Google, or at least was, and "PR" is becoming pretty common everywhere because of GitHub. But "diff" seems to be gaining some ground as a general term in the monorepo/unified-build/trunk-only world. Uber uses/used Phabricator and I think there are some other high-profile shops as well.

I don't know that there's like one leading term, but I think everyone knows what "diff" means both literally and as a connotation that it's a rebase rather than merge workflow.


It was "CL".


change list I think


I call it a diff and work at an almost-FAANG, I think it has to do with trunk-based development.


That does sound ideal but it's not really something that scales with enormous companies or a globalized economy. You can always allocate the best people to the top roles in the hierarchy. The reason is not only because you don't have the right people to fill those roles who also have the skills for leadership, the reason is sometimes because you have so many of them you can't allocate them because they're aren't enough spots at the top in the hierarchy.


*you can't always allocate the best people to the top roles in the hierarchy

Omg when a typo or voice typing completely inverts the intended meaning raaa


If we're talking about a one phonecall + one in person session with different teams, lasting 2, 3 hours max, sure. If you expect me to take time off work 4, 5, 6 times and get inteviewed for several hours each time, you're either paying me for the lost time, or I'm not going through the process the moment i find out the length.


It is somewhat easy to cheat through these N+1 interviews by grinding tons of practice problems before. At least that was my strategy. Sure I can implement DFS or a linked list, but I am a pretty suboptimal developer, especially when working with huuge codebases.

Maybe they should ask to implement a feature or fix a bug in some huge OSS project. That would evaluate skills relevant for a job in FAANG more closely imho.


Everyone I've ever met who said this was a better engineer than they thought. They seemed to look at the very best engineers, see a difference between themself and that person, and think they weren't that good.

I think there is also some kind of survivorship bias - you don't hear from the people who tried it and failed.


    but I am a pretty suboptimal developer, especially when 
    working with huuge codebases.
I'm in the same boat when it comes to huge codebases. I see people being effective on them and I often simply do not know how they do it.

But it is for sure, a completely different skill from leetcode style stuff.


I'm convinced that the best interview is to give someone an app (react or node app for example) and do exactly what occurs all the time in the real world. Give vague indication that a feature appears to sometimes not work correctly.

In the app code there should be one or two very obvious bugs and easy optimizations to make, and then put more subtle and challenging to fix issues there as well. And ideally make it something where a really sharp and experienced developer would identify some high-level architectural flaw and they would know how to rearchitect it.

Everyone knows that the leetcode-style questions are contrived and don't usually reflect real world work but we continue to do it anyways.


I've done a variation of this exercise with some folks I helped to interview.

We showed them our website and asked how they'd investigate/troubleshoot a complaint that the site was "slow."

Then we kind of role-played the troubleshooting process. Ideally I wanted them to determine if the site was slow for everybody, vs. just the person that reported the issue. If it was only slow for a single person, was it their account, or many just their internet connection? How would they determine that? If we determined the issue was happening for everybody, how would you determine which part of the stack was slow? Etc.


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.


> these roles are usually high stakes and the cost of a bad hire is too high

Really? High stakes? This fucking site.

Have you ever worked as a software developer at a corporation? Nothing about it is high stakes. You spend most of your time dealing with useless idiots who report to other useless idiots, who report to other useless idiots, about a useless product they think is a great idea that every non-idiot knows is useless garbage.

That's how you get Google not creating a single non garbage product over the past 15 years.

When they did Google Maps, did they have 7 interview processes? I bet you they didn't.

Here is how the real world works - 0.0001% create something, then 99.9999% turn it into what 99.9999% of people are. What that is - I leave to you as an exercise.


> When they did Google Maps, did they have 7 interview processes?

Actually, the original work for Google Maps was done by three companies that Google acquired:

> Google Maps first started as a C++ program designed by two Danish brothers, Lars and Jens Eilstrup Rasmussen, and Noel Gordon and Stephen Ma, at the Sydney-based company Where 2 Technologies. It was first designed to be separately downloaded by users, but the company later pitched the idea for a purely Web-based product to Google management, changing the method of distribution. In October 2004, the company was acquired by Google Inc. where it transformed into the web application Google Maps.

In the same month, Google acquired Keyhole, a geospatial data visualization company (with investment from the CIA), whose marquee application suite, Earth Viewer, emerged as the highly successful Google Earth application in 2005 while other aspects of its core technology were integrated into Google Maps. In September 2004, Google acquired ZipDash, a company that provided realtime traffic analysis.

https://en.wikipedia.org/wiki/Google_Maps#Acquisitions

Android was also acquired:

https://en.wikipedia.org/wiki/Android_(operating_system)#His...

Some of the things that Google is best known for were not invented by Google employees.


Wow, I didn't know that but I am also not surprised.

So Google had one good product in 20+ years. Lol. At least they have 7 interviews to make sure they don't make a 'bad hire'.


Hey stop stepping on fragile egos. We gave out participation trophies to a whole generation.

Hiring one wrong dev will end google!


I have to agree with you. So many people try justify the interview process with their intelligence or "costing the company multi-millions". It's all tied to their ego. I wonder how much of it is stockholm syndrome.


High stakes means high investment. You can’t just hire a dev and have them running in a week, their bad work could cost the company multi-millions in obvious and non obvious ways and proper onboarding takes months at minimum.

On the other hand, a cashier can be replaced in a week, and they don’t effect the entire future of the company as SOP.


> their bad work could cost the company multi-millions

That's such patently absurd bullshit. Google has a code review process. Almost any large tech company has this today. The review process is to ensure that it's a team effort when a major screw-up happens. You don't just let some new employee merge untested and unreviewed code.

You know who I always see harming the company with outages and downtime? Seniors and managers that cut corners. I've had managers before that put in place all these safe guards that go out the window the very second a deadline is threatened. They merge untested code. They route traffic haphazardly. They fuck around with DNS or user accounts on a whim. Because no one is there to tell them not to. They believe they are the exception. The rules are for the minions below them. If you're working late on a weekend cleaning up a huge mess, there is a good chance it's because some manager-turned-arsonist fucked around with the process. They cut corners on the planning, the implementation, or the roll-out.


You don't think those managers are "dealt with"? Lol yes they are, but it shows up in 'reorgs'.

And outages still occur even with code review, unit tests and alerting.


Ok, for the record, I haven't worked at a FAANG company so the stakes weren't as high. Just video game studios, so million dollar companies not billion.

Even on our systems, we had so many redundancies and test servers run, that even when a mistake did run through (which was exceedingly rare, given the testing), the roll back was quick. A single dev, especially a new hire, was unable to make multi-million dollar mistakes. It had to be several systems to fail, in order to be released to the wild. I can't believe any of the FAANG companies got to where they are with such a "cowboy" attitude as to say, "it's your third day, push that untested code straight to prod".

Edit: autocorrect hates me


> we had so many redundancies and test servers run

How did you hire the developers who built those systems? Was the bar higher then?

Lots of companies have institutional memory of how their first few hires were crucial to make the company successful. It's a tough decision whether to keep standards high, or risk losing the skills that got you this far. Eventually the early people leave. Where I work, the stuff they built is viewed as some kind of godlike crystalline shrine that you dare not touch.


It isn't just a one person show, is all I'm saying. The many are more capable than the one. Even if mistakes get made, there are processes (maybe a better word than systems) in place to keep it from turning into a failure in the wild, and if it does sneak through, it's a relatively simple roll back.

When a new hire comes on, that institutional knowledge must get passed on - hopefully there is good documentation, though it's never as good as hoped. No matter how well a new hire does on their knowledge test, TBH, the most important thing I hope someone I get to work with is culture fit and the ability to learn fairly quickly =[ how to interview for that is pretty difficult, though.


Eh I don't believe it is a million dollar hit. If it is then you have bad controls and bad process.

Google is optimizing for the wrong things. The reason Google has hard interviews is to minimize attrition and make everyone who passes the interview feel smart.


Have you worked at GAFAM? I've been on 3 person teams with over a million dollars a year in hardware expenses and we've done some crazy optimizations on our c++/java code.


> their bad work could cost the company multi-millions

They is false and hyperbole to justify your argument. If a single employee can cost a big company like Google multi-millions, then there is a company structure problem. You make it sound like there are no system of checks. The very definition of being 1 in 10,000 employees at big corp is that no one is important enough to cost the company multi-millions.


You can tell when someone hasn't worked at a google sized company when...

Yes, it happens all, the, time. It's just not public information.


Google has has 6+ interviews since at least 2003


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.


I will accept a veto but only if the interviewer can explain it sufficiently. I think it's important to trust but it's also important prevent abuse from bias. (Someone who abuses interview vetoes is likely a poison pill themselves and that's something I have to deal with as a manager.)


Yeah this also is a big issue. It was nice having the "debrief" meeting afterwards. This meant that people had to back up what they had written.

"Why do you think this person 'isnt a good culture fit'? Oh because the team you run are all 20-something male brogrammers and this candidate is a 38 year old woman with kids? Hey cool, that's illegal discrimination."


Keep in mind that the hiring and interview process is bi-directional: if one finds that the company to which one has applied potentially consists of terrible human beings, exit quickly and move on to the next opportunity (unless you are yourself a toxic influence, at which point the culture fit may very well be right).


> usually high stakes

You obviously haven't worked in finance. Google is as far from high stakes as you can get.


Exactly. The Knight Capital incident springs to mind.


> Exactly. The Knight Capital incident springs to mind.

Sure, but was that the engineering team’s fault or the fault of bad management culture? I suspect it was management that failed to adequately support their engineers and ensure they were well staffed, compensated, and didn’t have to work extraordinary hours to meet absurd “deadlines” that resulted in that fiasco.


> To add more: a single person (HM) might have biases for or against certain candidates.

That would be true for all organisations. You could do 6x more interviews if they were all a single round.

> Also these roles are usually high stakes and the cost of a bad hire is too high.

Hiring a brain surgeon is high stakes. I don’t know a lot of software positions where it is true.


> Hiring a brain surgeon is high stakes. I don’t know a lot of software positions where it is true.

Arguably it's not.

But if I think I'm doing a guy a favour by 'giving them a chance' and hiring them when they're marginal, and they quit a stable job and move across the country, then I fire them? In that case I didn't do them a favour by giving them a chance.


If you felt like that after your single interview you wouldn’t hire them?

Especially when you know they’re going to need to move all across the country.


A determined senior engineer could destroy a company in a day. At large companies they could cost the company millions.

While we like to pretend there are technical controls to prevent this, actually effective measures would come at a high cost to productivity.

And at huge FAANG companies replace "department or team" for company above. A bad hire can destroy a team or product or the team's reputation in the company.

Brain surgeons are not high stakes hires because they're not operating on their employer's brain and there are inherent barriers to entry in that field. The "brain surgeon" license actually means a lot.


I mean brain surgeons tend to be board certified. Don't really have that process for SWE, do we?


[flagged]


I’ve worked in tech for decades and I’ve never experienced a process with “7 straight white guys” much less every time.

First, how do you know the sexual orientation of interviewers?

Next, tech is like 50-70% Asian so it would be so weird to only have white guys doing programming interviews.

The guy pet is spot on as programming is way heavy in guys.

But I’m not sure why you would think that 7 interviews = 7 straight white guys.


> Next, tech is like 50-70% Asian

On the west coast. I've had employers where Eastern Europeans were more commonplace. The same employer had an Indian subsidiary but didn't hire H1-Bs and South Asians weren't present in notably large numbers.


I joined a subsidiary of a large company. I was the second non white guy at the company. Never knew a tech company could be so white.


(For a definition of white that is heavily Asian)


Maybe better to look at the definition of asian than white, Asia includes the subcontinent.


That is great signal for the candidate, though. If a company is putting all of their decision-making power into the hands of douchebros, it's best to make that clear in the interview process so that talented candidates can stay away.


At least half of them are Indian, in my experience.


When I interviewed at Google recently, the behavioral interviewer was a white guy. The four algorithmic interviewers were one Indian and three Chinese nationals.


I experienced almost that complete opposite of that, for sure..


Ok well, that makes sense on the other hand I went through a 7 interview round and I ended up taking another job before the last call to tell me you got the job!

That said it was mainly because they said after several interviews oh you just have one more to go but then the next interview said you have one more to go and they would also say you will be hearing from us in a week but it turned out I heard from them in two weeks.

But in the end, actually, both jobs paid the same, but one of them seemed to me to value my time more.


Completely relate to this!


>Second: Is it really fair to have just one or two developers evaluate you? When I first was an interviewer, I liked everybody! I would have hired them all. So getting multiple data points matters. Best to have at least a couple dev interviews.

Except FAANG interviews require excellence on almost all of the interviews, so the extra people only represent further opportunities to be denied.


Exactly. Many of these interviews it only takes one person to feel 'eh' or negative on the person to tank the candidate, so the more people you interview that person, the more likely you're going to have that impression on one of those people (especially if it's an all day series of interviews, you'll probably start to get mentally exhausted near the end of it), and the more likely any given candidate will be rejected.


It's the same principle behind using large numbers of disks in certain RAID configurations. If the pool can't tolerate a disk or two failing, adding more disks increases the chances of one or more failures occurring and tanking the pool.


What I'm reading here is that even as an experienced interviewer you struggle to make the format effective and equitable.

Sounds to me like the format isn't worth keeping; time to hire more, and fire fast?


I never understand answers of this format: "status quo has flaw of some known, finite impact" time to "completely ridiculously overcompensate, overreact, and make arbitrary move?"

I can't even fathom in what ways you think "time to hire more, and fire fast?" is more "effective and equitable"? You just shove even more risk onto individuals who might be getting their footing still.

You're just turning a 8-9 hours commitment to an interview into a 6 month commitment. Sure, you get paid but you also have to deal with churn and burn.

I mean, did you think stack ranking was a good idea?


The response is to the needless growth in complexity of the hiring process; advocating for reducing that complexity is appropriate.

You're tacitly expressing a concern that a fast hiring commitment would be riskier; but that's not necessarily so. A minimal set of filters are meaningfully effective: resume, references, and meet the team. Anything beyond that doesn't have just diminishing returns, it can negatively impact the company by narrowing the field of viable candidates too far.


I guess I don't think 2 phone calls and 5-6 hr onsite is that complex. Maybe the onsite could be 3 instead: 2 code + behavioral, but I can't imagine wanting to do less than that.


5-6 hr onsite is a strong filter against folks who are presently employed; particularly those who cannot spare personal days or unpaid days for every interview.


I don't think that argument is particularly relevant in the tech industry. It's not that hard to find a "sick" day, even if you don't have unlimited PTO. And especially during COVID, where going missing for a day might go unnoticed for a lot of people.


> It's not that hard to find a "sick" day, even if you don't have unlimited PTO.

Yah, no. That's a ridiculous proposal for many people, particularly parents and anyone with any sort of disability.


Are you really advocating people take sick days to interview for other jobs?


That is actually a pretty normal thing to do, yes.


Well... yes. I think that for most HN commenters, who work for a non-hourly salary and provide hard-to-quantify value in a seller's market for labor, it's generally possible to get a day off if you need it.

Many tech companies have gone to "unlimited" PTO, so there's no cost to taking a few days off. But even outside that, almost no managers are following the letter of the law. Last time I changed jobs, my employer at the time had explicit PTO time, but unlimited sick leave, and in practice during COVID (and especially near any holiday) was pretty lax with accounting for "I need to be out on Friday afternoon" as long as work was getting done and you were somewhat responsive to email/pings on the day in question. I wasn't hunting very actively, so it was just the one day of interviews with one potential new employer - I concede that if you needed to do many full-day interviews, it would eventually become conspicuous.


Nor do I. But I'm the cases we seem to be talking about here, normally it's not like that tho. It's multiple rounds: 5-7 interviews. Especially since remote.


eh: in the cases... Not "I'm", heh :) sorry :) ;p


> expressing a concern that a fast hiring commitment would be riskier; but that's not necessarily so.

I think it is necessarily so. Hiring fast is effectively hiring randomly and that is way riskier.

Would you read random books? Watch random movies? Maybe, but probably not.

Would you buy a random car? Of course not. Would you buy a random home? Etc etc

You can logistically reduce the number of days by maybe doing multiple interviews into a single day, but that’s still hours.

I’ve worked back in the dot com days where you were hired on the spot and that was fun until they fired on the spot.

Having a well-designed process that takes a while is not perfect, but is better than the other options. “Slow to hire, slow to fire” is a good maxim.


I'm not advocating for hiring literally anyone. If they pass your credential requirements, reference checks, and team meet then they're already passing through significant filtering.


Resumes aren't really credentials. They're lists of things provided by the individual themselves and are almost always inflated in some way. Reference checks are just "I got someone you don't know (and shouldn't trust) to say good things about me", and meet the team is just "I can talk to people and sound smart for about an hour or two".

There are a very large number of idiots who can do those things. I strongly disagree that this is a significant filter.


Those who lie on their resume in a harmful way are immediately apparent upon hiring, and so are quick to fire. Those who do not, are not, and aren't fired.

It's really not the risk folks seem to think it is.


Why do you think it’s easy to find who has lied on their resume?

It can take weeks for someone to orient, and as mentioned all over this thread it’s hard to fire people.

I’d rather use a system that avoids hiring people that will need to be fired. Blindly trusting resumes is silly since resumes are hard to verify.


It's not easy to find liars. It's easy to find who are underperforming. There's a difference between the two.

Resume, references, and team meeting filters out almost everyone who needs to be fired. Folks who lie on their resume, who arrange dishonest references and who defraud their way through a meet and greet are _exceedingly rare_. It's such a vanishingly small segment of possibility that it's not worth troubling oneself over.

The reality is that companies use complex and obtuse hiring practices to cover for poor internal practices. They recognize an inability to deliver and perform on their teams, and consider it a hiring failure; but the reality, most of the time, is that it's a structural or management failure. Most hires, most of the time, are sufficiently able to deliver on their desired roles; but often, management is unwilling and unable to identify that they are responsible for poor performance. And so they blame the candidates, the new hires, to their teams. Not themselves.


I don't think folks are saying that outright lies are happening very often. What is happening is resumes being written to sound impressive (obviously) and perhaps inflating the difficulty/contribution/impact of past work. Exact same thing with referrals and meet and greets.

Honestly all three of those things test the exact same thing, the person's ability to sell themselves. Which is why I would not work anywhere with such lax interviews. I don't want to work somewhere that only values likability and talking oneself up.


The dirty truth is that if a candidate thinks they can perform well in a role then, most of the time, that's true. It is exceedingly rare that people apply for roles that they know they cannot deliver upon.

It's dirty because we like to believe that our technical proficiency and ability is elite and rare, but the truth is that with a little training, with a little on the ground experience, many people can do what we do.

You don't want to work somewhere where that's proven possible.


I think that's probably right, although not always, and there are other problems associated with firing these people as others have pointed out.

What you said is that those three things, including the resume, are significant filters. I am saying they are not and you seem to not have a rebuttal on my point about the resume.


1. Often, legally, firing people is harder than hiring.

2. Hire more, fire fast sounds good on paper but will destroy morale as the team identity will be constantly influx.

3. Engineers will spend less time onboarding newer engineers to the detriment of everyone because well, they might not just last.


4. I think there's also a potential cost to your future ability to recruit. Once people know you're quick to fire, candidates will view your offer less favorably if they also have an offer from a company with a longer interview process, but who doesn't have the reputation for firing quickly.


Basically everywhere in NA has allowances for probationary periods with at-will employment. Moreover, prospective hires could start on contract.

Morale is improved when team members feel like they have some control over their membership.

It seems like you're assuming that a great many people would be fired; why so? In my experience, having worked for several such companies, firing is rare because even minimal filters are effective.

Resume check, reference check, and meet the team. Done.


I’m not saying you’re categorically wrong, but this doesn’t match with my experience, at all. If you’re an HM and this works for you and your company, great, but the HMs responding here don’t agree.

The processes you are questioning scale to thousands of people with varying backgrounds. It’s not an accident all of these companies do this. Your process places extreme trust in one group of people. It’s just so risky.

Also, resumes are mostly bullshit, IMO. Reference checks are complete bullshit, IMO. I’ve worked with my buddies at startups (who get lofty titles) and just have them give me reference checks. Other references have asked me for call scripts.

Also keep in mind that most of these big tech jobs are highly competitive. Your solution eventually requires a coin toss if you have limited spots. There’s only so much data you can collect from the process you propose. The natural thing is to then assess each candidate a bit more until you’re confident you’ve picked the right one. And then you’re here.


I've hired more than my share, yes.

Truly bullshit credentialing is immediately apparent to teams that receive new hires. In some places, it's fraud and actionable by the company as fraud.

I don't think companies with billions in revenue really have a budget constraint on hiring; it's structural constraints that are holding them back. They can, and do, engage in mass hiring and construction of whole new departments when it suits their strategy.

That said, further constraints can happen at the credentialling level; I'm not advocating hiring literally anyone.


What's practically possible is always a subset of what's legally possible. I think probationary periods/contract-to-hire situations are extremely unlikely to work for anything beyond absolute entry level, for a number of reasons.

For one thing, it's a huge amount of uncertainty to put on the potential hire, which means you'll be strongly biasing your hiring pool towards people who don't have better options. It feels like in an effort to reduce the interview time, you've effectively expanded it to multiple months.

Second, how do you calibrate the "default" option? Is the expectation that everyone on a probation period will be hired unless proven otherwise, or is it that most will be let go unless actively vouched for? Is that expectation clear across the team? If there's a mismatch across team members, you have big problems. People who want to keep a prospect will be annoyed if they're let go, and vice versa. People who need to work with a prospect will have to figure out whether it's safe to actually trust them with anything - on the one hand, you have to give them enough work to prove themselves; on the other hand, you can't give them anything too important or with too long a horizon, because they might be gone before they get to launch.

And finally - how long does that trial period need to go on to be useful? The goal in designing a hiring process is to get a reasonable level of precision/recall (different companies will balance differently between those) with a reasonable level of investment. If you've increased investment without increasing precision, then you've done something wrong. Given how long it takes to ramp up a new hire and have them actually be productive, I don't think you're going to learn much in a ~6 month probationary period that you couldn't already tell in a day of interviews.


The default option is simple: did the hire add meaningful value to the team? Very few people fail that simple test, in my experience; and folks who would have failed technical screenings would have excelled in subsequent performance-enhancing evaluations. Someone who can't balance a binary tree might be the single best technical coordinator you're going to hire, after all.

I've worked at many companies, and those that hire fast, and fire fast, tend to be those that _fire least_. They have _lower expectations_ for performance, and so are more likely to be receptive to _training new hires_, rather than expecting them to hit the ground running as equally effective as their new team mates.


> Basically everywhere in NA has allowances for probationary periods with at-will employment.

Yep. Lots of places with even stricter pro-employee laws, including Europe, also have it.


How many people have you hired? This doesn’t seem like a perspective from experience but a proposed hypothetical in a world that doesn’t exist.


in the US employment is at will or whatever it's called so they can fire you on the spot for no reason at all.


They can legally fire you on the spot, yes, but all that means is that the fired person can't sue their former employer. That doesn't mean it's actually a good strategy for the employer to do so frequently, because the employer's relationship with any given employee doesn't exist in a vacuum, and has effects on the employer's relationship with other employees and potential hires.


This is true but if it's well known that you fire, say, 30% of your hires after 6 months then you'll have a much harder time attracting the kind of candidates you want to be attracting. You can compensate for the devs' opportunity cost with, well, compensation, but you'll be competing with FAANG, whose high-turn reputation isn't even 30% bad (with the possible exception of Netflix)


Hire fast and fire requires even more effort and commitment from a candidate, I’m not sure how that would be an improvement. Firing fast would be like 3 months of interviews!

I’d also like to add that having multiple interviewers, if they have diverse backgrounds, is more likely to be equitable than a single interviewer.


It's not so much effort or commitment if the team is fully remote.


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.


The problem is "skill on paper" is just that, words. There's tons of java developers but not all the same. References too are pretty easy to game. Alternatively if by skills on paper you mean open source projects, that's fair but most developers (and certainly most new grads) won't have anything worthwhile to show.

The tech screens can show a person's skill. Sure, lots of people are gaming that too and memorize solutions, but that's not most candidates.


There's a difference between:

    Foo Corp
      - Wrote Java on Bar project
And:

    Foo Corp
       - Designed and developed infrastructure for Baz for Bar project (Java)
A resume that doesn't give an idea of what someone did, beyond the tech they used to accomplish their goals, isn't likely to pass my interest test.


There's only a very, very small difference between those two things though. I'm not hiring anyone based on either of those bulletpoints or similar ones; no matter how many there are.

It's so easy to inflate your role on a project and what you contributed and the people who are best at it are usually also able to talk, talk, talk.

The first interview question I ask is so easy that I don't think anyone should be paid to write software anywhere if they can't solve it. And yet, I have candidates with plenty of nice bulletpoints like your second one on their resume who can't solve it or take 30-45 minutes to solve it. Good candidates take less than 10 minutes, very good ones take less than 5.


Ah, you've got a gotcha bullet point question that you think is a killer technical ability question. But you're asking it in a completely abnormal situation, an interview. All you're testing for is the candidate's ability to answer your clever question in a scenario where their ability and personal value is actively being judged; which is wholly unlike any day-to-day challenge they are to encounter.


The question is not a gotcha. It is not trivia. It is not even a "killer technical ability" question. It's a question I considered not including because I thought it was too easy. Folks I've interviewed proved me wrong and I've come to realize that when I get any signal from it, it's the best question I ask.

If you know what a hash map or dictionary is then you can solve it. If you can't answer a problem because you're under pressure then that's a no hire signal on its own.


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.


FWIW, I was introduced to this method by others, and have used/been a part of this method at several companies now; and I find that each company where I have seen it employed has had remarkably low turn-over and high team morale. Much lower turn over, and higher morale, than the companies I've been at that have done otherwise. Also anecdotally, the companies that employ this method have been the same companies that seemed most willing to train and aid an under-performing employee, rather than simply let them go.

I think it's because the awareness of the need to ensure performance is baked-in to the process; rather than having an assumption that the hire should have a high level of performance. Employees aren't like other physical assets, like computers and other hardware, they're malleable human beings that are accepting of improvement.

But I don't know of any large studies on the merits of this approach, so perhaps I've simply been lucky to have had positive experiences.


That's what internships are in a way. Do you think that's a bad idea?


In my point of view, most hiring requires a form of internship. No one drops on to an established team with full knowledge and experience with the internal tools, procedures and products.

And yes, I lament that internships are so maligned. It shouldn't be that interns are poorly paid; we should be able to hire someone with decades of experience in a tangentially-related field at a competitive salary, and consider them to be interning on an unfamiliar field.


Internships are probably the best way to hire, but they only work for people at that specific stage of life.

University students already have a three-month gap in their schedule where they aren't doing anything, so they are willing to take a temporary role to fill that gap.

Experienced people who already have a job aren't going to drop that to take on a temporary role unless they have an unusually high risk-tolerance or unless they are desperate.


I assume there is some level of exaggeration here?

If not, it might help to actually try this. Take an aggregate of 15 interviews in the next couple of months and you're bound to learn something. My hypothesis would be some new empathy for interviewees but maybe you find a better role at a better company in the process. If the worst case is that it is a colossal waste of time, then you again have found empathy for the interviewee.

Ultimately, you might be narrowing your pool of applicants to only those willing or unwitting to go through that process.


But with being hired you get paid.

If employers with lengthy interviews want to pay people for their time that would be fair.


Fire fast is a harmful policy to employees in the US due to health insurance being tied to employment.


"Hire more, fire fast" does not sound like a company I'd want to work for.


Have you ever been fired before? It sucks.

I’d much rather not get hired then get fired “fast”.


Amazon follows the hire fast PIP fast strategy.

Look what that did to their reputation and company culture.

Netflix is a little more successful at this, but they have a much smaller eng footprint and much higher compensation in order to attract and retain top performers.


Where I am, in BC, Amazon is recognized as a challenging but rewarding employer; one that compensates better than most and expects consistently strong results.

I wouldn't consider that negative, really. Daunting, perhaps.


To be honest, it sounds like "the format with only 3-4 interviews wasn't effective and equitable, so we adjusted it to make it more so, resulting in the current 5-7 format..."


Yah, and I expect they'll find that insufficient and find themselves considering 8-9 interviews! ;)


I’m not sure that’s feasible. Not sure what the roadblocks are, but every company I’ve ever worked for seems to have real reservations, usually at the HR level, with simply getting rid of bad eggs.


That's probably true, but I think at least part of it is just smaller companies doing what bigger companies do, in a kind of cargo cult ritual.

The last company I worked at had 8 interviews, which I thought was a lot. My current company (about 100 people) had no less than 11 scheduled interviews!

Of those, only the first 2 were with people in my department — my manager first, then my manager and immediate coworkers. There was another group call with people in a related team I might conceivably be expected to liason with eventually. Fair enough.

The remaining 8 calls were with leadership in every other division in the company, most of which I would never work with. People with jobs where I don't even know what they do, and I'm sure they had no idea what I do. I just politely made conversation with them and answered their (very general) questions.

Now that I've worked there a while, I have never spoken with these people again, or worked in any way with the teams they oversee.

I've also participated in a few interviews at this company now, from the other end of the Zoom call, and I know how it works: literally every branch of the org chart gets a meeting for every interviewee, regardless of what they're applying for. Everyone has a chance to say "no", but in practice nobody outside the relevant teams is going to exercise that veto, because they are well aware that they are unqualified to judge the candidate's skills, and will never have to work with them anyway.

It's just a big waste of time for everyone involved.


You’ve already identified several ways to improve this. You don’t want to waste the devs’ time so you screen with low tech questions, which are also the only ones the HM is qualified to ask.

(Also, nothing is as expensive to a dev as a manager with too much free time. Spending a little on HR may be a QoL improvement even if we never hire)

I am also exceptionally fond of being a silent party in an interview.

Nobody wants to walk into a room with four people who are all asking questions, but I can learn a lot about people just by watching their interactions. Indeed I learn more about secondary characteristics than the interviewer because they’re wrapped up in the answer, not side comments the candidate makes about development philosophy.

Additionally, it takes less investment in an interview to ride shotgun like this. So jumping from 1 to 2 is not twice as expensive, and it protects you from hiring decisions being made with only one employee having been privy to the conversation. Especially with all of the EEO concerns that come from he said she said situations like this.

Three is the most I would put in a room, and only if two are asking questions and the third only answers them.

But you can still easily get seven people in front of the candidate with only 3 sessions in this way.


Don't forget the need to filter for bias. Many many moons ago, when Google's ATS was young, they didn't weight scores based on the interviewer. After some incredibly confusing low scores and some obviously bad hires, it was determined that there was a need to account for internal bias. That lead to applying weights to the interviewer's score because you still needed them to interview but you also knew that you couldn't trust them outright. More interviewers, more data points and better selection even with accounting for bias.


> These roles pay a huge sum of money, so there's a lot of worry that someone will be hired who doesn't really meet the bar, you know?

No, I don't. Making the wrong hire is costly not because of the total annual compensation, but because of the upfront cost which is realized the moment the employee signs the offer letter.

All the admin stuff.

By your logic you shouldn't fire someone either (at least not that easily) and maybe that's why so many FAANG engineers end up "cruising" because the company is so scared of hiring new talent.


> 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, so they also need to interview you too and have a say.

We decided to ignore this protocol and hired a senior lever manager from IBM. After the next two years, we had an IBM fiefdom. This person hired his IBM buddies, who hired their own IBM talent.

None of these people accepted our culture. It reflected in the organization’s output. Turns out, when you bring in people from these legacy companies where people seemingly coast by and don’t actually produce out, and you have little oversight on what they actually output, it just turns into an inefficient and ineffective mess.

This went on for a while until the entire org was gutted with over half the people fired.


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.


It's extremely common to have that many +1's required for a PR that touches several parts of the codebase.

And fixing a bad commit doesn't require 6 months of emotionally draining work.


These roles pay a huge sum of money, so there's a lot of worry that someone will be hired who doesn't really meet the bar, you know?

Except that now of course the practice has been by companies offering roles that don't pay huge sums (and at the end of the day are more or less standard CRUD roles). For the reason you cite at the end of your post


> When I first was an interviewer, I liked everybody!

I've been interviewing for a long time and I _still_ really like everybody. I want everyone to join and even if they're not a fit I want them to join and want us to spend time on bringing them up to speed and nurturing them. Of course I'm aware that an org isn't always able to do that.


Interesting. In medicine they tried to solve this issue by having multiple assessors in the Multi Mini Interview (MMI) [1]. Applicants spend 8-12 minutes with different interviewers in short succession and have a couple minutes to prepare between stations. Each station and assessor has a different question or goal (e.g. critical thinking, communication skills) which are unlinked and it is supposed to remove cumulative biases or the risk of the interview panel having deciding a negative outcome in the first five minutes. It ends up being a lot of behavioural interviewing but seems to work out.

[1] https://students-residents.aamc.org/applying-medical-school/...


What do you think about missing on people who are not desperate enough to go through such processes?


I feel like 7+ interviews is selecting for desperation more than any specific skill or fit. That's still likely to yield decent short/mid-term hires, and if the promotion structure keeps those hires around might be a successful strategy (we will leave the candidate's experience out of value judgement entirely) but it will eliminate an entire class of hires who aren't willing to submit to that amount of free time, energy and expertise for the possibility of future opportunities.


> Is it really fair to have just one or two developers evaluate you?

Output of multiple interviewers are combined by AND'ing, so when any one interviewer has even the slightest hesitation, you are out. Because of this, more is not necessarily better


One main issue I see is that it is a huge difference between FAANG and other companies but everyone seems to do the same as FAANG.

I don't live in the US but I think even different US companies has different needs. Our current problem is that it is very hard to find developers. A small or medium sized company may not get many candidates to interview, the problem then changes from finding the best in a large pool of candidates to finding anyone that can do the job. Scaring people off with 7 interviews would probably get us even fewer candidates.


Why not just do 1-2 interviews with all relevant parties.


> When I first was an interviewer, I liked everybody! I would have hired them all

Probably would have worked out just as well as the current system if not better.


All great points - you obviously condense this into a single day, right?


> "Oh shit, Amazon does 6 interviews? We should do that too!"

Therein lies the problem. Doing things because someone bigger and better is doing it is not the right decision making process


> These roles pay a huge sum of money, so there's a lot of worry that someone will be hired who doesn't really meet the bar, you know?

So do roles in medicine, finance etc. Do they also go through 7 interviews grilling them about material from their bachelor's or asking random logic questions? Why don't we test doctors "problem solving" skills by asking them how many cars are in Manhattan, don't doctors need good problem solving skills?


Well if you want me to invest 5-7 hours of my time you'd better give me some assurances as to why I should do that.


What you just outlined should be a poster definition for 'a slippery slope'.


Sounds like an organizational flaw is behind all of this.


> Can one interview really tell if you're good problem solving, coding, algorithms/data structures, and any specialization the role has?

Sorry, but if it can't, aren't you doing the interview wrong?


They all are doing the interview wrong and everyone knows it. Unfortunately there aren’t a lot of great alternatives that don’t take up even more time.


> They all are doing the interview wrong and everyone knows it

Most countries manage to devise the testing for a driving licence based on - at most - one theory test and one practical test. The practical test typically includes many different situations and manoeuvres in order to assess the candidate's suitabilty for being allowed to drive.

You don't sit a practical driving test in which you consider one single aspect of driving. The test attempts to cover everything. In one test.

Why would one not attempt to devise an interview along the same lines?


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

Search: