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

I agree with your general approach to a more holistic interview process. I haven't thought too much about the weights so can't comment there.

I'm pretty sure the weights vary depending on roles: interviewing a tech lead for ML requires deep experience in That field and will have more of those questions than basic CS algs. Or at least a higher weight than it would in a fresh graduate.

It's not my place to judge the average ability of Google engineers. I'd guess it's a normal curve somewhat skewed to the right since the bar is really high. In my limited experience they're on par with top silicon valley engineers but have a different profile than startup ones due to self-selection.

The point of many interviews is to reduce false positives, both for skill and professionalism. It works amazingly well. Every single person I talk to has something interesting to say and is at the very least competent at what they are doing. Not everyone feels brilliant but everyone does seem bright. And I'm not drinking the cool aid.

Hiring good people is easy if you just test for skills. It's much harder to make sure someone is a genuine person, or at least not an asshole. Google does a tremendous job here and I worked at enough startups and a few large companies to know how incredibly difficult that is.

That other companies failed trying to do this can be because of many reasons, from bad engineers to start with, lack of resources, mistakes in assessing ability or rush to get devs on the team asap. Again, not my place to comment.

Every company asking its employees to interview prospects implicitly assumed they are good, or at least competent. If they don't, they have a bigger problem to start with.

If they hired someone they already think they are good, right? And if they ask them to interview someone else they think they are able to judge, or don't understand that logic (In which case they have even bigger problems).

How does a mediocre engineer fail a stellar one? If the candidate is really better than the interviewer, won't they be able to solve anything they ask them to?

I think the reason multiple interviewers ask CS questions is to avoid the issue you mentioned earlier: asking one question the candidate just so happens to know really well. Random sampling should solve it.

I interviewed at Palantir a long time ago and was asked super hard CS questions over the phone and in the first rounds and I killed it. The last round I was tired because I hadn't slept well and tanked one problem. Just one, everything else I had solved really well. Yes I thought it was silly to reject me and wish they had given me another shot. If you are at Palantir and are asked to interview someone, think they are bad, and they get hired, it's demoralizing - you just wasted your time and the company doesn't value your opinion. Sure, you could have a score and average things but again, firing is way way worse than saying no to a good candidate who just had one bad question. And everyone I interviewed with was legit. (I had another series with them later, for a different role and got an offer :-) )

I agree that weights could be adjusted but 1. How do you know that would yield better results? (Show me the data - I don't think anyone has it) and 2. It can also be a cultural choice to bias more towards CS skills vs design or whatever else. Perhaps the company has great design patterns and can teach those skills v effectively. I'm not saying it's true, just an example. If you had a company and ran the interview process your way, I promise there will be someone just like you who vehemently disagrees with your weights :-). But if you could prove that process A vs B yields better outcomes, most companies would definitely follow suit (if they pay attention, are good at adjusting their processes etc).

I don't actually know how they read packets, I just know they work really hard to avoid false positives, and I wholeheartedly agree.

Btw I was rejected by Google twice before - resilience is part of the game ;-)



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

Search: