3 ms·

> you can pick a ticket and pair program. Have them review an actual PR. Etc. This seems so obvious. If you pick a leetcode question, there’s always the risk t

by bogwog 4y ago

> you can pick a ticket and pair program. Have them review an actual PR. Etc. This seems so obvious. If you pick a leetcode question, there’s always the risk that your candidate has memorized the answer to that particular question. But if you pick an actual bug/PR from your codebase, that problem disappears completely, and you get to see how they would perform on the actual job you’re hiring for. Can anybody think of any negatives here? The only thing that comes to mind is that it might be seen as the employer trying to get free labor if they use a bug report that hasn’t been resolved yet.

bmelton 4y ago
The easy way to get around exploiting free labor is to pay for the labor. Give the project a cost and time budget (e.g., "You've got six hours to try to resolve this issue that our [already trained and familiar with the codebase] engineers think will take ~2 hours to resolve, and we'll pay $100 an hour for the effort whether or not you succeed")
sumeno 4y ago
I've never worked somewhere with a codebase simple enough for a new engineer to find and fix a non-trivial bug on their first day. Especially not with someone looking over their shoulder deciding whether to hire them.
- bogwog 4y ago
  There are always bugs that don't require extensive familiarity with a codebase. Even if it's easier than most day-to-day work, it still shows the candidate's approach to problem solving, how effective they are at reading code, allows them to show off some relevant domain knowledge, etc. And as a bonus, it easily works to weed out those people who don't actually know how to code. > Especially not with someone looking over their shoulder deciding whether to hire them. That would help in this case, since presumably the person looking over their shoulder is familiar with the codebase (or at least as much is relevant to the question), and can answer questions. I think the signal-to-noise ratio on an exercise like that is going to be way better than with leetcode questions.
- TrackerFF 4y ago
  Which makes the idea of having someone solve a "trapping rainwater" problem (with O(n) solution) in 20 mins even more ridiculous. It is so far removed from actual work.

by bogwog 4y ago

bmelton 4y ago

The easy way to get around exploiting free labor is to pay for the labor. Give the project a cost and time budget (e.g., "You've got six hours to try to resolve this issue that our [already trained and familiar with the codebase] engineers think will take ~2 hours to resolve, and we'll pay $100 an hour for the effort whether or not you succeed")

sumeno 4y ago

I've never worked somewhere with a codebase simple enough for a new engineer to find and fix a non-trivial bug on their first day. Especially not with someone looking over their shoulder deciding whether to hire them.

bogwog 4y ago
There are always bugs that don't require extensive familiarity with a codebase. Even if it's easier than most day-to-day work, it still shows the candidate's approach to problem solving, how effective they are at reading code, allows them to show off some relevant domain knowledge, etc. And as a bonus, it easily works to weed out those people who don't actually know how to code. > Especially not with someone looking over their shoulder deciding whether to hire them. That would help in this case, since presumably the person looking over their shoulder is familiar with the codebase (or at least as much is relevant to the question), and can answer questions. I think the signal-to-noise ratio on an exercise like that is going to be way better than with leetcode questions.
TrackerFF 4y ago
Which makes the idea of having someone solve a "trapping rainwater" problem (with O(n) solution) in 20 mins even more ridiculous. It is so far removed from actual work.