Another solution to this problem is contract to hire. I realize this is kicking the can down the road to the contracting firm but hear me out: that's the business the contracting firm is in. They can get really good at their hiring practice since that's their core business. That's not our core business. We've been doing this for the past two years and it's worked out great. Now you can see how well people do the actual job and if you're not satisfied, which happens from time to time, just get someone else.
Harder programming questions do a worse job of predicting outcomes
31–40 of 540 posts
Re: Harder programming questions do a worse job of predicting outcomes
#32This is an interesting post given that up until recently TripleByte's facebook/Twitter ads were asking very nonrealworld programming questions: https://twitter.com/minimaxir/status/1054596563585052673
Now, the ads ask simpler things like floating point precision and function variable scoping (https://www.facebook.com/triplebyte/ads/?ref=page_internal ); legit problems, but not sure if they are an indicator of how good a developer they'd be in the real world working on a CRUD app.
Re: Harder programming questions do a worse job of predicting outcomes
#33On the interview its build a tic tac toe but when you get to the real job they give you a week to fix a line of code. This industry is fucked up.
Re: Harder programming questions do a worse job of predicting outcomes
#34Because they're designed that way. It all comes down to: * Rejecting far more candidates than you need to -- so you can feel like you're hiring "the top 1 percent" * Giving yourself the feeling that you have an objective hiring process (when really you don't) * Making your own team members feel like they're super brilliant and special when really they're not That's what the modern hiring process is designed to do. An…
> Rejecting far more candidates than you need to What do you mean by "than you need to"? I'm guessing for many companies (especially the ones with this kinds of interviews), the limit is the number of hires they can do, not the number of candidates that apply... So by definition, you need to reject all but n (the number of open jobs)... Why wouldn't you reject them based on performance on interviews (as opposed to, b…
In many cases companies don't interview all the candidates before making a decision, it's more on a rolling basis. You consider each candidate separately - you interview a candidate and then decide whether to hire him/her or not.
In plenty of cases companies reject candidates who later perform successfully at similar roles, and this is the point of the parent comment. However this is kind of a desired effect, because not hiring a right candidate has lower cost than hiring a wrong candidate:
- if you skip good candidate, because you're not sure whether they'll perform well, you just wait for more candidates to apply, it just slows down the process - if you hire wrong candidate, the candidate joins the team, underperforms and eventually is let go, but during the time that person works for you, you don't look for the right candidate for that role, which costs you more money and time
Re: Harder programming questions do a worse job of predicting outcomes
#35Because they're designed that way. It all comes down to: * Rejecting far more candidates than you need to -- so you can feel like you're hiring "the top 1 percent" * Giving yourself the feeling that you have an objective hiring process (when really you don't) * Making your own team members feel like they're super brilliant and special when really they're not That's what the modern hiring process is designed to do. An…
> Rejecting far more candidates than you need to What do you mean by "than you need to"? I'm guessing for many companies (especially the ones with this kinds of interviews), the limit is the number of hires they can do, not the number of candidates that apply... So by definition, you need to reject all but n (the number of open jobs)... Why wouldn't you reject them based on performance on interviews (as opposed to, b…
This might be true at Amazon, Google, or Netflix. But many companies have openings that sit vacant for months, even though perfectly great candidates applied for the job.
Re: Harder programming questions do a worse job of predicting outcomes
#36The less talked about absurdity is that successfully passing programming interviews is a skill itself. It's especially absurd because the time I spend developing that skill is less time spent developing skills and knowledge more directly relevant to my job. Yet, programming interview skill is more relevant to progressing my career. edit: now if you'll excuse me, I need to do some dynamic programming problems.
This is kind off strange for a non US resident to grasp. I've been employed as a programmer three times and noone tested my coding abilites what so ever on the interviews. No samples, nothing. Never heard of any collegue doing that either.
The massive FAANG-types of companies receive so many millions of job applications, they championed these types of interviews to have a more objective way to filter through all the applicants. That practice has waned somewhat at the larger companies (not totally, but it's changing), but has trickled down to smaller companies.
Re: Harder programming questions do a worse job of predicting outcomes
#37The bigger problem is the inconsistency amongst interviewers when judging candidates. All these articles from TripleByte and Gayle (who've built business on the flaws of interviewing) focus on the questions instead. Doesn't matter how hard the question is if the interviewer knows what they're looking for, are experienced enough, show no nepotism and have good communication skills.
My worst interview ever was with Facebook when a non-native, new college grad gave me a Leetcode hard problem in half-broken english and went back to his work without even looking up or walking with me through the problem.
Re: Harder programming questions do a worse job of predicting outcomes
#38What alternative would you suggest?
Re: Harder programming questions do a worse job of predicting outcomes
#39Because they're designed that way. It all comes down to: * Rejecting far more candidates than you need to -- so you can feel like you're hiring "the top 1 percent" * Giving yourself the feeling that you have an objective hiring process (when really you don't) * Making your own team members feel like they're super brilliant and special when really they're not That's what the modern hiring process is designed to do. An…
Don't forget that they introduce market friction to reduce developer turnover and reduce salaries. I suspect one of the reasons Google is so open about their process and the need to study is so that everyone follows suit. Thereby forcing people to take days off and do homework for even the most mediocre of positions, causing the switching costs of interviewing anywhere to become higher.
Interesting idea. I got an email from Facebook with invitations for the interview. Replied: “I can do it but i’m Letting you know, I will not spend a minute preparing for it. So, we can do it today”.
I never heard from this person again, which brings a question - is probability of passing it without putting personal time is so low it makes no point in even trying?
Re: Harder programming questions do a worse job of predicting outcomes
#40The less talked about absurdity is that successfully passing programming interviews is a skill itself. It's especially absurd because the time I spend developing that skill is less time spent developing skills and knowledge more directly relevant to my job. Yet, programming interview skill is more relevant to progressing my career. edit: now if you'll excuse me, I need to do some dynamic programming problems.
This is kind off strange for a non US resident to grasp. I've been employed as a programmer three times and noone tested my coding abilites what so ever on the interviews. No samples, nothing. Never heard of any collegue doing that either.
It's actually not as common as it sounds from reading HN. There is definitely a bias based on the fact that the big tech companies do it and startups tend to do it. Which many commenters here have experience with.
A lot of more traditional software development roles do not have much testing. Sometimes they will have a quick online timed test or a simple question on an intitial phone screen. That isn't to say that all companies do not have testing. But it's definitely the startup and big tech worlds that have the majority of it.