4 ms·

Next blog post: Why I am unemployed These coding tests are actually quite an equalizer in terms of interviews: you may be ace at answering all whiteboard/phone

Next blog post: Why I am unemployed These coding tests are actually quite an equalizer in terms of interviews: you may be ace at answering all whiteboard/phone-screen questions, but when it comes down to actually coding -- something you are being hired to do, you can't crack it. On the other end: it lets people who may not be amazing at whiteboard questions the chance to show that despite that they can get things done. When somebody interviews for a software engineering position, the goal of the company is to as quickly as possible get an objective opinion on the person by seeing how that person compares to other candidates they have seen. This is good for the candidate too, because who wants to be subjected to an arbitrary process? All of the alternatives suggested in the article are fine, but they don't make the interview process very objective. Things you can see during a coding test: - How they tend to structure their code - Do they like to over-engineer problems - Do they dive right in or think things out - How easy is their code to read? - Are they experimental, do things in an interesting way? - Are they prone to making bizarre design decisions etc. etc.

mattlutze 11y ago
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.

mattlutze 11y ago

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.