4 ms·

Why is it hard? Because Google ruined technical interviews with irrelevant trivia and excessively long interview loops. For some reason a lot of the industry

Why is it hard? Because Google ruined technical interviews with irrelevant trivia and excessively long interview loops. For some reason a lot of the industry said "hey, if Google does that it must be right!" and they also started asking pointless trivia questions in very long loops. But why stop there? Let's build out pointless trivia as a service, and assign a numerical score to represent your ability to perform pointless trivia outside the context of an interview. I really think it's that simple. Tech interviews are broken and need to be drastically simplified. Candidates should be evaluated conversationally as humans and given the opportunity to learn on the job. It's a risky proposition in both directions, there's really no need for trivia, it doesn't prove anything (except act as a red flag for candidates).

nickff 5y ago
I agree with most of what you say, especially about simplifying and shortening the process, but I'm not sure about: >"It's a risky proposition in both directions" It seems like the worst case for the developer is that they get paid for doing nothing useful for a while, then have to find another job. The worst case for the company is that they pay out a bunch of money, and dedicate a variety of resources, to someone who delays a (hopefully non-vital) project. This is not a symmetrical proposition.
- deeblering4 5y ago
  > they get paid for doing nothing useful for a while, then have to find another job. That's true, but if they took advantage and get fired then they would have poor references and a spotty employment history, which will negatively affect getting another job (and would have been a factor in the hiring of the current role). So in that way there is an incentive for the candidate to perform well in order to maintain their career, and they do risk that track record to some extent when taking on a new role. It sucks for both sides if things don't work out.

nickff 5y ago

I agree with most of what you say, especially about simplifying and shortening the process, but I'm not sure about: >"It's a risky proposition in both directions" It seems like the worst case for the developer is that they get paid for doing nothing useful for a while, then have to find another job. The worst case for the company is that they pay out a bunch of money, and dedicate a variety of resources, to someone who delays a (hopefully non-vital) project. This is not a symmetrical proposition.

deeblering4 5y ago
> they get paid for doing nothing useful for a while, then have to find another job. That's true, but if they took advantage and get fired then they would have poor references and a spotty employment history, which will negatively affect getting another job (and would have been a factor in the hiring of the current role). So in that way there is an incentive for the candidate to perform well in order to maintain their career, and they do risk that track record to some extent when taking on a new role. It sucks for both sides if things don't work out.