4 ms·

I was an engineering hiring manager for several small startups. I never asked for coding on a whiteboard. I asked some work style questions and then concentrate

by Sloppy 5y ago

I was an engineering hiring manager for several small startups. I never asked for coding on a whiteboard. I asked some work style questions and then concentrated on a collaborative exercise where I laid out a problem and important applicable technology. Then I'd answer any Google-ish questions in realtime. This technique found good collaborators and also which people were good problem solvers. Never made a bad hire from this method. I only wish I had discouraged others from "code on the whiteboard" type bs. Great article.

Mezzie 5y ago
Am I weird for thinking that sounds fun to do?
- vietthan 5y ago
  You are not weird. Definitely feels like two nerds nerding it out to see if they grokk each other. But then again, it wouldn't scale well.
  - gumby 5y ago
    Why wouldn't it scale? (I posted a reply to the GP comment about how I've done in the past, admittedly always at startups).
gumby 5y ago
Used a similar process: ask an open ended problem with no "correct" solution that the interviewers (us) might be looking for, and also weren't domain specific. The same question could be asked of MEs, EEs, software developers, you name it -- they could just talk about the part of the problem that mattered to them. An example: one we used a few times was "we decided we want to build a drone for the police. So if a bank is being robbed the cop who arrived first could take it out and it will help solve the crime." Some people would ask a bunch of constraints up front; others would just dive in and ask questions as they went. And they'd think about the problem "so we want to chase the getaway car long enough until a regular copter can get airborne, so let's assume X MPH for Y minutes minimum". Someone else thought "small is probably better because perhaps it can look into the bank when it would be dangerous for a person to try, and we have to assume a lot of them will be destroyed, so cost matters." etc etc. Another great one is "Jucero (this is just after they collapsed) has inspired us to make a bluetooth-only coffee machine". My favorite candidate started with "even with BT you'll really need a control panel for reasons XXX and YYY. And BT generally won't add much, if anything, but if product management insists, let's think up some halfway plausible use cases..." and then ended up in a discussion of the protocol and how to think about making it robust against failure." These were always fun, and told us a bit about how the candidate thinks, without the pressure of doing it "right". Often the solutions were excessively elaborate, or missed elements a real product would need, but so what? They were "first drafts" in a situation with some pressure. And who cares about remembering the precise arguments to a function or anything that needed looking up. And the length of these things helped strain out bullshitters. One candidate immediately said "the best way to solve this is to use an XXX. The other interviewer and I looked at each other excitedly. That was the best way and nobody else had suggested it. The candidate went on to ignore XXX, even when we asked questions in the hope of sending the discussion back that way. It's as if they had said "oh, well for this you'll need an adjustable wing" and then drew a wheeled vehicle that could not fly.
wildrhythms 5y ago
This is how it's done. An engineer just walking through a problem 1-on-1 with a candidate can reveal more information about a candidate's skill in just 15 minutes than any number of leetcode or annoying, useless take home exercises.
- zozbot234 5y ago
  True, but that's expensive. Leetcode-style quizzes make the most sense if you just want to pick a bunch of promising candidates out of a large amount of applicants, all with minimal effort.

by Sloppy 5y ago

Mezzie 5y ago

Am I weird for thinking that sounds fun to do?

vietthan 5y ago
You are not weird. Definitely feels like two nerds nerding it out to see if they grokk each other. But then again, it wouldn't scale well.
- gumby 5y ago
  Why wouldn't it scale? (I posted a reply to the GP comment about how I've done in the past, admittedly always at startups).

gumby 5y ago

Used a similar process: ask an open ended problem with no "correct" solution that the interviewers (us) might be looking for, and also weren't domain specific. The same question could be asked of MEs, EEs, software developers, you name it -- they could just talk about the part of the problem that mattered to them. An example: one we used a few times was "we decided we want to build a drone for the police. So if a bank is being robbed the cop who arrived first could take it out and it will help solve the crime." Some people would ask a bunch of constraints up front; others would just dive in and ask questions as they went. And they'd think about the problem "so we want to chase the getaway car long enough until a regular copter can get airborne, so let's assume X MPH for Y minutes minimum". Someone else thought "small is probably better because perhaps it can look into the bank when it would be dangerous for a person to try, and we have to assume a lot of them will be destroyed, so cost matters." etc etc. Another great one is "Jucero (this is just after they collapsed) has inspired us to make a bluetooth-only coffee machine". My favorite candidate started with "even with BT you'll really need a control panel for reasons XXX and YYY. And BT generally won't add much, if anything, but if product management insists, let's think up some halfway plausible use cases..." and then ended up in a discussion of the protocol and how to think about making it robust against failure." These were always fun, and told us a bit about how the candidate thinks, without the pressure of doing it "right". Often the solutions were excessively elaborate, or missed elements a real product would need, but so what? They were "first drafts" in a situation with some pressure. And who cares about remembering the precise arguments to a function or anything that needed looking up. And the length of these things helped strain out bullshitters. One candidate immediately said "the best way to solve this is to use an XXX. The other interviewer and I looked at each other excitedly. That was the best way and nobody else had suggested it. The candidate went on to ignore XXX, even when we asked questions in the hope of sending the discussion back that way. It's as if they had said "oh, well for this you'll need an adjustable wing" and then drew a wheeled vehicle that could not fly.

wildrhythms 5y ago

This is how it's done. An engineer just walking through a problem 1-on-1 with a candidate can reveal more information about a candidate's skill in just 15 minutes than any number of leetcode or annoying, useless take home exercises.

zozbot234 5y ago
True, but that's expensive. Leetcode-style quizzes make the most sense if you just want to pick a bunch of promising candidates out of a large amount of applicants, all with minimal effort.