2 ms·

The author's position is sound for the hypothetical he discussed, where, if a company starts the conversation pursuing a candidate, it's reasonable for the cand

The author's position is sound for the hypothetical he discussed, where, if a company starts the conversation pursuing a candidate, it's reasonable for the candidate to expect that the company has done their homework (why else would the company try to hire you in the first place?). So I'd suppose, if the company already knows you can solve problems with software, what they don't know is how well you'll fit in with the staff they envision you working alongside of. Skipping right to the coming-in-and-collaborating step makes sense here for both sides. The tests definitely make sense for the other main case here, where the developer starts the conversation. Then no one should expect the company staff to go out on their own and search out Random Developer #45's blog posts. I'm curious, how do you/coworkers supervise the coding tests you have candidates perform? You can tell some things about approach and tactics from a final draft of a solution, but I would imagine most of your listed desired goals would come from watching and interacting with the candidate while the test is being performed. And in that case, it'd still seem to be a big effort for the engineers and such who need to support?

danielrhodes 11y ago
There is barely any supervision: they are given a problem, and asked for a solution which matches certain criteria. You can't find the solution on Github. What's important is that it isn't a test of someone's intelligence or personality, but rather their pragmatism and ability to actually produce code. It really depends on what values you are looking for, though. An example problem is: parse this non-standard log file and report back some numbers/answer these questions (e.g. show a visitor funnel, based on uniques, etc.). The more encapsulated and defined the problem, the better. It's not a theory type question, such as build a btree search of this data: it's something which you could face while working at the company and you can solve it however you want. Just like in real life, there are a range of solutions and edge cases. There is a soft time limit of a few hours, but nobody is counting. However, that time limit is what changes the difficulty. They can either use their own machine or a company machine, and any language they want (with some recommendations). They can of course ask questions anytime they want, but other than that they are left on their own. At the end, they are asked to walk through the solution and tell us why they chose to do what they did, what issues they had, if they see alternative ways to do something, how they might change it if various conditions changed, etc. It's the opening to a conversation. Afterwards we rarely try to actually run the program, but different people on the team are asked what they think of the solution (kind of like a code review). Since everybody has seen it many times before, there is general consensus on red flags and everybody more or less has an idea of how a particular solution fits in with other ones we've seen, but sometimes there is debate on merit or style. So it isn't that time consuming from our point of view.

danielrhodes 11y ago

There is barely any supervision: they are given a problem, and asked for a solution which matches certain criteria. You can't find the solution on Github. What's important is that it isn't a test of someone's intelligence or personality, but rather their pragmatism and ability to actually produce code. It really depends on what values you are looking for, though. An example problem is: parse this non-standard log file and report back some numbers/answer these questions (e.g. show a visitor funnel, based on uniques, etc.). The more encapsulated and defined the problem, the better. It's not a theory type question, such as build a btree search of this data: it's something which you could face while working at the company and you can solve it however you want. Just like in real life, there are a range of solutions and edge cases. There is a soft time limit of a few hours, but nobody is counting. However, that time limit is what changes the difficulty. They can either use their own machine or a company machine, and any language they want (with some recommendations). They can of course ask questions anytime they want, but other than that they are left on their own. At the end, they are asked to walk through the solution and tell us why they chose to do what they did, what issues they had, if they see alternative ways to do something, how they might change it if various conditions changed, etc. It's the opening to a conversation. Afterwards we rarely try to actually run the program, but different people on the team are asked what they think of the solution (kind of like a code review). Since everybody has seen it many times before, there is general consensus on red flags and everybody more or less has an idea of how a particular solution fits in with other ones we've seen, but sometimes there is debate on merit or style. So it isn't that time consuming from our point of view.