3 ms·

I'm not convinced that questions like these work effectively at all. They might give you some insight into a developer's ability to research and implement some

I'm not convinced that questions like these work effectively at all. They might give you some insight into a developer's ability to research and implement some specific algorithms (because you're not making them do it on a whiteboard, are you?) but there's a lot more to being an effective engineer than that. We've had success with a two-hour pairing exercise, in which the goal is "build a miniature version of one of the core parts of our product" with one of our engineers. That's followed by explaining the goals, technology, general approach etc. to another engineer, then a discussion about what would happen next, some of the specific domain problems, that sort of thing. There's no expectation that the project is completed in the time available, and it's more about understanding the process. This has been pretty effective, and is great for getting a more rounded understanding of the skills of a particular engineer. In my experience, rather softer skills like the ability to clearly articulate the problem, to understand the broader impact on a bigger system, and to be able to identify future issues and challenges are more important than the ability to solve specific technical challenges. Lackluster technical ability is usually pretty immediately obvious when pairing with a developer, in any case.

sfbushstreet 12y ago
This is how companies like google, facebook, and linkedin interview candidates. It's not effective, but it's the common practice
- Kurtz79 12y ago
  It's not very effective, but I don't think it's that bad. In the end as a developer your job is to solve problems, and getting hired is simply another problem (solving which has self-evident benefits, so you shouldn't lack motivation). It's not like the hiring process for technical jobs is shrouded in mystery: there are tons of resources on the internet about it. You know what kind of questions will be asked, you know how you are expected to answer, the rest is just study and practice: a successful interview should be at least proof for the employer that you are able to grasp that process and carry out the work necessary to see it through.
  - general_failure 12y ago
    Solving world peace and curing cancer are also problems. I don't think engineers are best suited to solve them.
    - collyw 12y ago
      We leave world peace to politicians. I think engineers would probably do q better job.
pnt12 12y ago
I think the point of some of these tests is to quickly distinguish from people who can and can't code solutions for simple problem. The latter has obviously lied in their application and can be dismissed right away, creating time for other interviews.
jghn 12y ago
We're starting to do something similar, although without the pairing (we don't do pairing) but with some engineers in the room playing the role of coworkers who are available to discuss the problem, bounce ideas off of, etc. The issue that immediately came up is that within the 2 hour time frame it's just not going to be possible to have a truly realistic block of code from our daily work, there's just way too much domain specific knowledge that one would need to bone up on. So then what happened is that we're back to looking at problems that are in the mold of a whiteboard problem but a bit more complex and with a higher expectation in terms of what their output is. I think this sort of thing works better when a company in the webdev space where companies are using well known frameworks (e.g. RoR) that candidates are going to know how to spin up a reasonable application complete with DB, etc without much effort.

sfbushstreet 12y ago

This is how companies like google, facebook, and linkedin interview candidates. It's not effective, but it's the common practice

Kurtz79 12y ago
It's not very effective, but I don't think it's that bad. In the end as a developer your job is to solve problems, and getting hired is simply another problem (solving which has self-evident benefits, so you shouldn't lack motivation). It's not like the hiring process for technical jobs is shrouded in mystery: there are tons of resources on the internet about it. You know what kind of questions will be asked, you know how you are expected to answer, the rest is just study and practice: a successful interview should be at least proof for the employer that you are able to grasp that process and carry out the work necessary to see it through.
- general_failure 12y ago
  Solving world peace and curing cancer are also problems. I don't think engineers are best suited to solve them.
  - collyw 12y ago
    We leave world peace to politicians. I think engineers would probably do q better job.

pnt12 12y ago

I think the point of some of these tests is to quickly distinguish from people who can and can't code solutions for simple problem. The latter has obviously lied in their application and can be dismissed right away, creating time for other interviews.

jghn 12y ago

We're starting to do something similar, although without the pairing (we don't do pairing) but with some engineers in the room playing the role of coworkers who are available to discuss the problem, bounce ideas off of, etc. The issue that immediately came up is that within the 2 hour time frame it's just not going to be possible to have a truly realistic block of code from our daily work, there's just way too much domain specific knowledge that one would need to bone up on. So then what happened is that we're back to looking at problems that are in the mold of a whiteboard problem but a bit more complex and with a higher expectation in terms of what their output is. I think this sort of thing works better when a company in the webdev space where companies are using well known frameworks (e.g. RoR) that candidates are going to know how to spin up a reasonable application complete with DB, etc without much effort.