601–610 of 833 posts
Have things changed that wildly in a couple years? If a company dragged me through 6 interviews I’d automatically assume they weren’t serious / were incredibly unorganized or unprofessional - and I would obviously take it as a red flag.
Earlier quoted context omitted.
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 t…
> 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.
I know multiple FAANG companies that track this data.
Earlier quoted context omitted.
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…
It was "CL".
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
> Amazon literally has a research team focused in hiring, and they run A/B experiments to continually improve the process. The current interview format is not a cargo cult, is a high refine process through the years. The median time an employee stays there is now under 2 years. Clearly Amazon isn't hiring the calibre of people they need.
Alternative hypothesis: they did hire the correct people, but working there is so unpleasant that very few people decide to stick around.
Earlier quoted context omitted.
Hopefully it would correlate with programming ability and not general IQ.
IQ tests tend to cluster around a pretty specific kind of thinking. Pattern matching. Logic. Math. Sometimes vocabulary. This doesn't correlate with programming ability: it is indistinguishable from programming ability.
Earlier quoted context omitted.
This sounds very forward thinking and I like it. Would you be willing to share a bit more on the process? What does it entail? In the past I was hired on just 2 interviews, and all we did was talk as peers. It felt comfortable and honest. It's the reason I said yes to switching positions.
Thanks! So, I'll say that we are still tweaking and trying to get things just right but, as of the time of me writing this, here is the process: - HR call 30 min. - Talk to hiring manager (me) 30 min. Get to know each other and feel out if there is a mutual fit. - Technical panel 1hr. Speak with several engineers on the team who share your discipline (front end or back end for example). Again no live coding. We just…
Earlier quoted context omitted.
> 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 i…
> 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 th…
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'.
Earlier quoted context omitted.
> Hiring managers are timid about letting people go and it can take an extraordinary amount of time to part ways with unproductive people. With respect, it sounds like you had a bad manager. Underperforming teammates are your managers responsibility. They should be working to address that issue with said teammate or part ways. Sucks. Not fun. It's the job though.
Sorry but your response is a No True Scotsman argument. It is understandable why irrational behavior applies here - sunk cost, nobody wants to have the bad news of letting a new hire go, explicit objective setting may require there to be new hires. These will generally apply to any manager. Unless the new hire is clearly stepping out of bounds or extremely negligent, it is going to be a slow process.
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,…
I’m a HM at a big tech company with this format as well. Honestly, I really like it. I don’t want to hire the wrong person, it’s expensive and it makes my job awful for a while. It’s great getting data points on several programming interviews, system design, etc. That makes my sell interview so much easier because I can trust the process to assess their technical skills. You need multiple people because you’re consta…
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.