3 ms·

None of the code that we use for this is too difficult. To date we've only hired for generalist engineers, and are not using some obtuse algorithm example. It's

by cepp 6y ago

None of the code that we use for this is too difficult. To date we've only hired for generalist engineers, and are not using some obtuse algorithm example. It's things you'll need to do in a day-to-day like filtering logging outputs, checking HTTP response codes, throwing errors, etc. We want to see how a candidate preforms on an example like this rather than writing something from scratch. Of course there's Q&A and their reasoning/explanation is just as valuable as the code they right. This is just the technical portion of the interview. However, I think we've really hit the sweet spot with this approach.

ordinaryperson 6y ago
Of the 3 you mention "filtering logging outputs, checking HTTP response codes, throwing errors" only the last one seems universal to me. Take logging. Super important - I spend a lot of time evangelizing logging to younger devs and how to do it well. But filtering? How? In what way? For what values? I don't have context but the expectation I should be able to filter for specific things you have secret preferences for strikes me as a signal that's not clear or universal. Checking HTTP codes. In what context? There are plenty of times when it's not helpful -- for example there are many page not founds that DON'T return as 404 (even tho they should). So this a priori belief that all devs should automatically have this built-in preference for checking HTTP codes as some universal signal of quality in programming is, I think, a larger assumption than you might realize. I don't think there is a perfect way to interview, but I do think if you're going to quiz developers it helps to give them some advance warning of what areas you prefer to focus on so it's not such a random, out-of-left field line of questioning. You may not consider your questions abnormal -- but that's the problem, neither do the people who ask obscure algorithm questions! It's very hard to validate your assumptions.

by cepp 6y ago

ordinaryperson 6y ago

Of the 3 you mention "filtering logging outputs, checking HTTP response codes, throwing errors" only the last one seems universal to me. Take logging. Super important - I spend a lot of time evangelizing logging to younger devs and how to do it well. But filtering? How? In what way? For what values? I don't have context but the expectation I should be able to filter for specific things you have secret preferences for strikes me as a signal that's not clear or universal. Checking HTTP codes. In what context? There are plenty of times when it's not helpful -- for example there are many page not founds that DON'T return as 404 (even tho they should). So this a priori belief that all devs should automatically have this built-in preference for checking HTTP codes as some universal signal of quality in programming is, I think, a larger assumption than you might realize. I don't think there is a perfect way to interview, but I do think if you're going to quiz developers it helps to give them some advance warning of what areas you prefer to focus on so it's not such a random, out-of-left field line of questioning. You may not consider your questions abnormal -- but that's the problem, neither do the people who ask obscure algorithm questions! It's very hard to validate your assumptions.