3 ms·

Since it's "quite deep" and you might have spent hours looking for a solution on the Web, why would you ask this question to a candidate in a 45 min interview?

Since it's "quite deep" and you might have spent hours looking for a solution on the Web, why would you ask this question to a candidate in a 45 min interview? Do you think it's fair? And how would you define success since everyone would fail on this question? Just curious...

flavor8 10y ago
You learn a lot more about a candidate by seeing them tackle a reasonably tough problem than you do by pop-quizzing them on language features. Language features and "how do I"s can be googled, and can reasonably be learned in the first weeks on the job; a good understanding of algorithms generally requires study, and takes much longer to do well at. Further, even if the algorithm is completely new to them, you can still learn a lot from their problem solving methods. Finally, it shows that they can code. You would be surprised how many people can interview well but cannot actually code. I learned this the hard (and expensive) way several years ago, and since have made coding a central part of the interview. Sure, I probably lose some candidates who think it's "beneath" them, but in all honesty with that kind of attitude they're probably not the ideal hire either.
- d--b 10y ago
  Once I was interviewed by a very seasoned developer. The only question he asked me was to write a C function that swaps the content of 2 pointers. He told me 90% of the people he saw screwed it up.
  - chaosite 10y ago
    This is, of course, the point of FizzBuzz. http://wiki.c2.com/?FizzBuzzTest http://wiki.c2.com/?FizzBuzzTest
d--b 10y ago
By quite deep, I meant that it's easily understandable, it's hard enough, and there are tons of different solutions. You can also see differences in recursion vs iterative, and talk about ordering and Gray codes, and all sorts of things. Many people I interviewed managed to do it, and I passed many people who didn't. Usually I start the question by saying: "this came up in my day to day job and I found it interesting. It seemed simple, but it took me a solid 2 hours to solve properly. I don't expect you to finish it during the interview, but I'd like to see what are you thoughts about how to solve this." For me it's a good question to assess: 1 If the person enjoys programming 2 If the person can articulate the problem to another person 3 If they are creative 4 To what degree they have a programming culture (how they talk about enumeration etc). If they finish in 5 minutes using recursion, then you can ask how to make it so the enumeration can be enumerated in parallel, which is very useful, and involves ordering/gray codes and what not.
ska 10y ago
I typically wouldn't ask any "implement algorithm x" questions, but I do ask technical questions. The point isn't to see if someone knows the answer (in fact, if they obviously do we'll move on to something else). The point is to see how they problem solve, and what their `toolbox' looks like. To that end I never as "implement algorithm x", but rather "here is a problem [or set of requirements], how would you approach it". The best versions of these are deep in the sense I think you are replying to. This means you can easily fill as much time as you want discussing different approaches or details.

flavor8 10y ago

You learn a lot more about a candidate by seeing them tackle a reasonably tough problem than you do by pop-quizzing them on language features. Language features and "how do I"s can be googled, and can reasonably be learned in the first weeks on the job; a good understanding of algorithms generally requires study, and takes much longer to do well at. Further, even if the algorithm is completely new to them, you can still learn a lot from their problem solving methods. Finally, it shows that they can code. You would be surprised how many people can interview well but cannot actually code. I learned this the hard (and expensive) way several years ago, and since have made coding a central part of the interview. Sure, I probably lose some candidates who think it's "beneath" them, but in all honesty with that kind of attitude they're probably not the ideal hire either.

d--b 10y ago
Once I was interviewed by a very seasoned developer. The only question he asked me was to write a C function that swaps the content of 2 pointers. He told me 90% of the people he saw screwed it up.
- chaosite 10y ago
  This is, of course, the point of FizzBuzz. http://wiki.c2.com/?FizzBuzzTest http://wiki.c2.com/?FizzBuzzTest

d--b 10y ago

By quite deep, I meant that it's easily understandable, it's hard enough, and there are tons of different solutions. You can also see differences in recursion vs iterative, and talk about ordering and Gray codes, and all sorts of things. Many people I interviewed managed to do it, and I passed many people who didn't. Usually I start the question by saying: "this came up in my day to day job and I found it interesting. It seemed simple, but it took me a solid 2 hours to solve properly. I don't expect you to finish it during the interview, but I'd like to see what are you thoughts about how to solve this." For me it's a good question to assess: 1 If the person enjoys programming 2 If the person can articulate the problem to another person 3 If they are creative 4 To what degree they have a programming culture (how they talk about enumeration etc). If they finish in 5 minutes using recursion, then you can ask how to make it so the enumeration can be enumerated in parallel, which is very useful, and involves ordering/gray codes and what not.

ska 10y ago

I typically wouldn't ask any "implement algorithm x" questions, but I do ask technical questions. The point isn't to see if someone knows the answer (in fact, if they obviously do we'll move on to something else). The point is to see how they problem solve, and what their `toolbox' looks like. To that end I never as "implement algorithm x", but rather "here is a problem [or set of requirements], how would you approach it". The best versions of these are deep in the sense I think you are replying to. This means you can easily fill as much time as you want discussing different approaches or details.