111–120 of 188 posts
Just fire them if they don't work out. You set expections by telling them up front they are on probation and that they will be fired if they fail to live up to their resume.
Some of the worst programmers I ever worked with could pass hazing interviews like a champ. Whereas some of the best would refuse to step foot in companies with a reputation for hazing their prospects.
Earlier quoted context omitted.
Unless your company was exceptionally unique in some way I'd probably just pass instead. It's awfully one-sided: you're just sending me some code and I'm supposed to invest hours on it. At least with an onsite interview our priorities are aligned: neither of us want to waste more time than we have to.
Yeah we all have different taste in interviews, I'd much rather spend 2h working for free than writing som tree traversal or fib function on a whiteboard for ten minutes. Interviewing is hard.
Earlier quoted context omitted.
> I completely understand the need for these technical interviews and weed out obvious bad programmers and get experts on board but sometimes from a business point of view it just doesn't make sense. The thing is that the main goal of the technical interview is not to hire all good candidates. The main goal is to avoid hiring bad candidates. A large high paying company like Facebook has plenty of candidates to choose…
> Someone who is capable of learning what's needed to do well on a technical interview has demonstrated a fairly high level of competence, and is (relatively) unlikely to be a really bad hire. Sure, as long as their only role is repetitive coding tasks that require limited amounts of broadening their experience beyond the DS&A trivia places like Facebook require. However then Facebook ends up with stuff like their iO…
The only way this would be true is if being good at textbook CS makes you bad at solving other problems. I'm assuming you don't actually think that, 'cause it's kind of crazy.
Even giving the benefit of the doubt and assuming you mean that the filter makes the pool less likely to contain good problem solvers, it's hard to see where this idea is coming from. In my experience, being good at one sort of problem solving makes someone more likely to be good at other sorts of problem solving. The correlation between skill in problem solving across domains is weak sometimes, but it's definitely not negative!
It's good to think carefully about how you interview candidates. Most of the ideas in this post are good. You should definitely let candidates type answers on computers. You should definitely work to put them at ease, in an environment that approximates their actual working environment. But really, this is window dressing. The problem is that technical interviews just don't work reliably. We have better ways to quali…
>>Rather than trying to read subjective, noisy signals from in-person interviews, give candidates a small battery of work-sample tests. I tell people the same thing, but the typical response is "that just discriminates against people who have families and other obligations and can't set aside 10-20 hours on evenings and weekends".
Earlier quoted context omitted.
> I completely understand the need for these technical interviews and weed out obvious bad programmers and get experts on board but sometimes from a business point of view it just doesn't make sense. The thing is that the main goal of the technical interview is not to hire all good candidates. The main goal is to avoid hiring bad candidates. A large high paying company like Facebook has plenty of candidates to choose…
> Someone who is capable of learning what's needed to do well on a technical interview has demonstrated a fairly high level of competence, and is (relatively) unlikely to be a really bad hire. Sure, as long as their only role is repetitive coding tasks that require limited amounts of broadening their experience beyond the DS&A trivia places like Facebook require. However then Facebook ends up with stuff like their iO…
Amount of code is a function of the number of engineers. It's a social organization issue & a big company issue more than anything else. If facebook removed the algorithms part of their interview through a time machine, the same issues would of still cropped up.
Also in backend & foundational infrastructure stuff where you go make compilers and base foundational libraries, you do tend to use those algorithmic things once in a while. You use stats in analytics & data science and you math in ML and other initiatives. FB isn't just CRUD construction workers after all :p
Earlier quoted context omitted.
>>Rather than trying to read subjective, noisy signals from in-person interviews, give candidates a small battery of work-sample tests. I tell people the same thing, but the typical response is "that just discriminates against people who have families and other obligations and can't set aside 10-20 hours on evenings and weekends".
A home test must be doable in 1-2 hours. Not 2 days.
Phone screens are particularly useless and a good place to scavenge hours from.
Here's another disadvantage of whiteboard coding: it's inaccessible to blind people, and impractical (even more than usual) for people with only a little vision (like me). Such candidates will need to do the coding on a computer, so one might as well make that the default, as the OP recommends, and eliminate one variable and a possible source of bias. Of course, once a blind or low-vision programmer stays at a given…
I even give people the option to use the computer if they are more comfortable with that or a whiteboard. It can be 50:50 in who choses what.
In my opinion, if you bring a candidate on-site for a 4+ hour interview and you ask them to write code, you've failed to properly vet the top of your recruitment funnel. As a software engineer, writing code is the BARE MINIMUM of your job. Imagine hiring a construction worker by merely asking them to hammer a nail for 4 hours.
You should have a thorough understanding, through various means such as phone screens, code samples, portfolio work, and simple tech challenge, to determine whether they can write code before you even bring them on-site. Once they're on-site, you should quickly verify that they can actually do what you previously learned that they can do. I'm talking 15-20 minutes worth of time. The remaining time should be 100% on the "soft skills" and other things mentioned, including but not limited to my big criteria: "Can you quickly get up to speed and learn the things you don't already know?" and "Do I want to sit next to you for the next 6 months of my work-life?"
If your on-site interview includes 45 minutes of coding (much less multiple sets of 45 minutes of coding!), you're doing it wrong. Very wrong.
Keep in mind you've asked your candidate to effectively take a day off work from their current job. They're calling in sick, taking a vacation day, or somehow lying to their boss and taking a risk of not being in their office when they're in yours for the interview. If they're smart, they've lined up multiple interviews with multiple companies, because putting all their eggs in your basket is just a terrible idea. Imagine having to take four days off to interview with four companies. And they probably aren't four days in a row, so you can't just pretend to have the bubonic plague or something.
You're asking them for a huge commitment of their time. And if you're willing to kick out a candidate because they didn't know how to invert a binary tree, then you should have found that out before they even walked in the door and saved everyone a whole bunch of time.
IMO, an interview should be a max of 4 hours. Any more than that and the candidate is simply repeating themselves over and over to different people, potentially solving the same tech problems (that should have been evaluated beforehand), and generally making it a huge waste of time.
My two cents. Happy to debate these ideas with anyone interested.
Earlier quoted context omitted.
After I proposed the idea, they said they liked it and were willing to give it a try. They offered 1.) slight changes to the UX, 2.) add a payments feature, or 3.) some back-end bugs that need to be resolved. They asked which of them sounds most appealing as a test. This was perfect from my perspective, and after I signed the NDA I told them all of those sounded fine. I mentioned that fixing a bug is one of the best…
> One of my recent rejections came after being asked "A hammer and a nail cost $1.10, and the hammer costs a dollar more than the nail. How much does the nail cost?" this just got me to see if i can still work through a basic high school algebra problem (yes, slowly, guess and check would've been quicker but less fun).
Earlier quoted context omitted.
> I completely understand the need for these technical interviews and weed out obvious bad programmers and get experts on board but sometimes from a business point of view it just doesn't make sense. The thing is that the main goal of the technical interview is not to hire all good candidates. The main goal is to avoid hiring bad candidates. A large high paying company like Facebook has plenty of candidates to choose…
> Someone who is capable of learning what's needed to do well on a technical interview has demonstrated a fairly high level of competence, and is (relatively) unlikely to be a really bad hire. Sure, as long as their only role is repetitive coding tasks that require limited amounts of broadening their experience beyond the DS&A trivia places like Facebook require. However then Facebook ends up with stuff like their iO…
While those "trivia" problems are part of the process for big companies, they are far from the entirety of it. Especially for industry candidates, plenty of other aspects of the interview process focus on broad experience and engineering principles.
I have no reason to believe that CS abilities anti-correlates with broader ability/experience. In fact, I'd posit that performance on algorithm problems correlates well with general intelligence, which correlates well with performance across the job.