Unless you are the top company in your bracket, your completion rate will also not be so great for a take-home (people have limited time: they'll sort by how good your company is). Sure they'll do Google's take-home but local business that does local comp/prevailing wages? It's at the bottom of the pile. By the time they get to it, the best candidates will already have an offer from a better company.
That's why I prefer to bring people on-site as soon as possible, and do a little whiteboard (the point being that the candidate must... know how to code!). It's an artificial challenge that's really a pretext to have a technical discussion.
Only time I advise to use take-homes is when you are dealing with a massive number of applicants from institutions that have a poor signal to noise ratio. Bootcamps come to mind. But then you end up with candidates that have the homework done by someone else and it ends up not being a good filter either.
Are the best developer candidates looking for on-site roles? I don’t know any that prefer an office setting.
2. Whiteboards
Yet another way to test developers on stuff that is unrelated to the work. I don’t even like writing with my hands all that much because I’m on a keyboard all day.
I get into a whiteboard and I am being tested on writing skills, how visual my thought process is, how my handwriting is, how comfortable I am in a public speaking position…all great qualities, but all entirely unrelated to programming in a team.
Is whiteboarding even a realistic exercise in typical multi-office or remote companies? If I’m presenting to coworkers I’m probably on zoom in my development tools right? That’s not a whiteboard.
Visualization maybe, but writing by hand? Until recently (when I started working on an art-related project) writing by hand alone took more concentration than solving actual tasks, not to mention writing in a fashion so someone can read it. I simply didn't write by hand for the last 15+ years.
> Apparently we should just review github OSS contributions and how many unit tests they write.
No, but speaking from experience - also don't reach out to senior, employed devs for a role, then waste their time with whiteboard leetcode quizzes to "make sure they aren't fakers or coasting, we have sooo many applicants".
In those cases, a conversation is really more valuable, we aren't interns.
I gladly participate in whiteboard interviews to ensure I will not have senior+ colleagues who are unable to solve them. The fact that intern candidates can solve them is all the more reason to filter out experienced candidates who can't
Completely disagree. I've observed other people run whiteboarding session with candidates and "solving them" usually means, "in the way I want" and if you've only just met then thats only going to happen through hints.
The "context" (hints) they give different candidates can vary massively, perhaps by the end you've realised that your question is ambiguous, or you like the personality of this other candidate.
I've worked with folks who will definitely give attractive women more guidance throughout so they arrive at the "correct" solution and not see what they are doing.
A good whiteboard problem is geared towards understanding how the candidate thinks and how well they can communicate ideas rather than total correctness. I’ve been the interviewer on a few whiteboard problems, all of which I’ve prefaced with something like, “we want to see how you solve problems and communicate ideas, there are no specific answers we’re looking for. You do not need to go into great detail or even know exactly how to build what you’re suggesting, just how it fits in to the system you’re designing.” Also when I’m designing a rubric for these interviews, the technical competency maybe represents 15% of the total score, 25% for problem solving/adaptability, and 65% communication.
The whiteboard is standard across all companies, I know how to prepare, and the company has to be at least invested enough to assign an interviewer to it. So I would choose that.
I got denied three times in the final interview with different FAANG companies for not doing whiteboards fast enough. Not getting them right; I mean not doing them fast enough. I’ve passed some whiteboards too in other interviews so it’s not that I can’t do them. There’s a lot of variation here.
I don't want to hire people who implode with a bit of pressure.
The pressure of whiteboard interviews (mostly negative; of the form "yeah this problem is basically trivial, but I'm not used to coding while talking to a stranger, plus the time requirements just don't smell right and certainly do not reflect real work conditions") are so infinitely removed from ...
The pressure at real jobs (mostly positive: "the problem is somewhat non-trivial, and I know time is kind of tight; but I'm in the flow and in my preferred environment; and at least I know the requirements are legit; so can I triage some good result out of this before the end of the day?").
At least for any job one would want to have.
If this distinction is not intuitively obvious to you - or are quick to characterize any negative reaction to your interview as a matter of the candidate being basically a total limp-wrist at your craft, ready to "implode" at the slightest difficulty -- then really, you have no business constructing interview challenges for people. Not challenges with any kind of a time limit, anyway (these being generally unnecessary, when we think about it).
One simple question I ask is to count the words in a string. It's a warmup question and a way to get the candidate comfortable with the format of the interview and the optimal workflow (discuss requirements, propose an implementation, flesh it out in pseudo-code, translate pseudo-code to something that looks like code).
You certainly don't need rote for that, the algorithm is trivial for anyone who did well in their introduction to programming class.
Either the candidate "gets it" in about 10-15 minutes, or struggles for 60 minutes.
> Not a need that comes up in actual software development.
I'm not sure. Ability to remain calm and code when shit's on fire can be fairly useful skill at some places (the smaller the company, the more valuable it can be). I've did that, coding emergency patches - e.g. to cache some hot paths when we've got unusual traffic that revealed bottlenecks that we've never hit (and noticed) before. Though I'd say it's a fairly different mental experience than coding at an interview.
Also, actually writing code on a whiteboard is a weird skill outside of academic roles. But most places I've seen asked to sketch some crude pseudocode or - better - draw wavy lines and boxes that represent processes and entities, then talk about it (and I think this is fine, whiteboard here is just a convenient tool).
And, of course, requiring to remember some algorithms from memory is a rarely useful skill. I've coded even in quite spartan conditions (right in a server room, with an ancient CRT monitor and keyboard, plain vim running on a 80x25 text console) but even then I had one or two Internet-connected devices that I could've used to look things up. If a candidate is allowed (or, better, even encouraged) to search for anything they want - it's all good, of course.
Outside of education, no one bothers to remember actual algorithms unless they've used them recently - everyone remembers names and key properties, and optionally remember some core principles (and then either just use them because they're already in a library or popular package, or go look for the implementation details).
> Though I'd say it's a fairly different mental experience than coding at an interview.
This is the key. Not all pressure is the same.
Shit on fire at work is not actually personal pressure, it's pressure on the company. And to be clear, shit on fire at work tends to be a metaphorical exaggeration, where an emergency code patch isn't going to save the company from imminent bankruptcy. You're still going to have a job the next day, still going to have a roof over your head and food on the table. And your coworkers already know you and respect your work (if you're competent).
This is vastly different from being unemployed, suffering from profound financial worries about your future, and having complete strangers looking over your shoulder, prematurely judging you in the span of a few minutes, where these few minutes can determine your personal fate.
I've done quite a few emergency fixes over my career, but exactly zero of them were lose-the-job emergencies. Whereas every job interview is a lose-the-job emergency.
I keep myself in the interviewing loop at my company because I actually enjoyed the process when I joined. It was conversations over “executable” solutions. Now, we kick out so many candidates that can’t get a coded, running solution in the 45 minute slot.
I have tried so many times to explain the WILD asymmetry going on. That for us, we just have to interview the next candidate. To them, they have the enormous pressure of “if I can’t do this exercise then I have no income, no health insurance, no security.”
Unless you are the top company in your bracket, your completion rate will also not be so great for a take-home (people have limited time: they'll sort by how good your company is). Sure they'll do Google's take-home but local business that does local comp/prevailing wages? It's at the bottom of the pile. By the time they get to it, the best candidates will already have an offer from a better company.
That's why I prefer to bring people on-site as soon as possible, and do a little whiteboard (the point being that the candidate must... know how to code!). It's an artificial challenge that's really a pretext to have a technical discussion.
Only time I advise to use take-homes is when you are dealing with a massive number of applicants from institutions that have a poor signal to noise ratio. Bootcamps come to mind. But then you end up with candidates that have the homework done by someone else and it ends up not being a good filter either.