5 ms·

The point of these tests is not to see who remembers their CS. The point of these tests is to have an opportunity to see how candidates go through the process

The point of these tests is not to see who remembers their CS. The point of these tests is to have an opportunity to see how candidates go through the process of solving problems by approaching a problem that is well-understood by the interviewer. Good interviewers pair with the candidate and help to coach him/her towards a solution. This is a carefully crafted simulation of two people working together in which certain variables can be controlled. It's also time-limited because most interviewers have to go through dozens of candidates to find someone who is a good fit for a particular team and culture. It's economically infeasible to hire a bunch of people on a per-trial basis. It's also hurtful to bring someone in for a few days, and then tell them that they aren't working out. Normally, when I heard this whole "I don't do coding tests" attitude, it comes from a candidate who thinks that he/she is so amazing that the rules don't apply. If such candidates flounce out of my tech screening because I dared to give them a problem, then my tech screening has worked. In my experience, most good engineers have tempered their egos with a dose of humility. They have hit the wall of their abilities, and they understand that they aren't nearly as amazing as they thought they were when they were younger. They are more careful, and they are open minded. I won't dismiss a candidate for lacking humility if I believe that he or she can grow, but if given the choice between a good candidate with humility and a stellar candidate who is too good for a test, I'll pick the good candidate every day. I'll let that stellar candidate be someone else's management nightmare.

yetihehe 11y ago
> The point of these tests is not to see who remembers their CS. The point of these tests is exactly to see who knows how to program. I've seen too many candidates who couldn't program, which I understand as finding code which solves a stated problem. FizzBuzz is only used as a first pass filter. After they solve it and are deemed normal enough to work, they are hired for limited time to really see if they are worth working with. If candidates can't solve fizzbuzz with a language they're most comfortable with (yep, we don't require you know any of our technology), they won't solve other problems they will be given. All my current coworkers can solve those kinds of tests in reasonable time without any help, even if it's in a language they don't know, I've also solved tests prepared by them.
- nanolith 11y ago
  Being able to reason about a problem and then work towards a solution in code is a more general skill than just programming or CS. I'm assuming that here, "FizzBuzz" is more of an allegorical example than a literal test question, as it would be rather useless in a test. I'd be more likely to ask someone to write and then optimize an algorithm or implement a simple data structure, and then build on this example with additional constraints or requirements. That has merit. A pure coding test is no better than a typing test. Without the problem, it's a meaningless exercise.
  - yetihehe 11y ago
    You would be surprised how many people which call themselves programmers can't even solve fizzbuzz. This is good test to weed out really bad candidates. As I've said, it's good firstpass filter, not a good hiring test.
geebee 11y ago
"Normally, when I heard this whole "I don't do coding tests" attitude, it comes from a candidate who thinks that he/she is so amazing that the rules don't apply." You know, I really don't think that's it for a lot of people who don't like technical "interviews". You're seeing this as an ego issue, when there really are problems with the technical exam/interview, especially when it is abused. Personally, I think the problems start with the fact that we're calling what is actually an exam an "interview", and it's an exam taken under very stressful circumstances. Think of it this way - I read a blog post about someone who studied for the california bar for 100 hours and passed. The exam itself was 3 days long. Now, 100 hours is notably low, and part of the point of the post was to suggest that you don't actually need to study as long as people often do. But think about this think about what it takes to prepare for a technical interview. Have you read "cracking the coding interview"? Those are difficult problems, and you need to be able to solve them at a white board within 45 minutes (or at least get close enough that you can do it with some, but not too much, coaching). It's not at all over the top that a rusty person would need to spend 50+ hours to get fluid with this. If your data structures, bit manipulation, tree traversal, dynamic programming, threading, or other topics are very rusty, you will need to study before beginning your study. It's not at all uncommon to spend an amount of time that starts to approach bar exam preparation levels. One interview typically lasts all day. So preparing for and completing three interviews is actually roughly on a par with taking the bar exam. Unfortunately, you rarely get feedback on your performance (for legal reasons, I understand). You have no idea if your exam was graded fairly or consistently, and you have no idea if your examiners have the credentials and expertise to actually understand a novel solution. Sometimes you get advance warning about what might be tested but other times you are completely blindsided by the questions. Once you pass the bar, you've passed. Software interviews, on the other hand, you have to do over and over. And even worse, we often present these tests as sniffing out frauds rather than looking for exceptional talent (ie., an exceptional performance on these exams rarely get you much above the job offered, so it's more about not losing than winning). Really, there's a tremendous amount to object to here. You don't have to think you're amazing or above it all to start thinking this is a serious problem that may be driving talented people away from our industry. I've read various blog posts about potentially promising candidates who aren't interviewing anymore simply because they're too intimidated, or because they just can't afford to put 50+ hours of study into something that may be completely capricious and depend purely on what some overworked programmer thinks is important that day. I can't imagine my graduate program's MS exit exam, or the bar, or the state nursing license board, or any respectable exam committee getting away with being so capricious and opaque. Now, I've hired before, and I'd be afraid to hire without a technical exam. So I hear you, I really do. And I've been on technical interviews, even tough ones, that I actually kind of enjoyed (I so rarely do real dynamic programming or tree traversal, and it is actually kind of fun, under the right circumstances). But we spend so much time talking about a desperate shortage of software engineers, and so little time actually recognizing some of the things that make our industry really exceptionally unpleasant. I think we should recognize that tech exam/interviews, while perhaps necessary, are also a potential problem, enough of a problem that some people are starting to boycott them altogether (I will do them, though I won't do an unpaid take-home ever again). It may in fact be an ego problem some of the time, but since there's clearly a more legitimate reason to object to this practice, let's start there, rather than dismissing this as an ego problem.

yetihehe 11y ago

> The point of these tests is not to see who remembers their CS. The point of these tests is exactly to see who knows how to program. I've seen too many candidates who couldn't program, which I understand as finding code which solves a stated problem. FizzBuzz is only used as a first pass filter. After they solve it and are deemed normal enough to work, they are hired for limited time to really see if they are worth working with. If candidates can't solve fizzbuzz with a language they're most comfortable with (yep, we don't require you know any of our technology), they won't solve other problems they will be given. All my current coworkers can solve those kinds of tests in reasonable time without any help, even if it's in a language they don't know, I've also solved tests prepared by them.

nanolith 11y ago
Being able to reason about a problem and then work towards a solution in code is a more general skill than just programming or CS. I'm assuming that here, "FizzBuzz" is more of an allegorical example than a literal test question, as it would be rather useless in a test. I'd be more likely to ask someone to write and then optimize an algorithm or implement a simple data structure, and then build on this example with additional constraints or requirements. That has merit. A pure coding test is no better than a typing test. Without the problem, it's a meaningless exercise.
- yetihehe 11y ago
  You would be surprised how many people which call themselves programmers can't even solve fizzbuzz. This is good test to weed out really bad candidates. As I've said, it's good firstpass filter, not a good hiring test.

geebee 11y ago

"Normally, when I heard this whole "I don't do coding tests" attitude, it comes from a candidate who thinks that he/she is so amazing that the rules don't apply." You know, I really don't think that's it for a lot of people who don't like technical "interviews". You're seeing this as an ego issue, when there really are problems with the technical exam/interview, especially when it is abused. Personally, I think the problems start with the fact that we're calling what is actually an exam an "interview", and it's an exam taken under very stressful circumstances. Think of it this way - I read a blog post about someone who studied for the california bar for 100 hours and passed. The exam itself was 3 days long. Now, 100 hours is notably low, and part of the point of the post was to suggest that you don't actually need to study as long as people often do. But think about this think about what it takes to prepare for a technical interview. Have you read "cracking the coding interview"? Those are difficult problems, and you need to be able to solve them at a white board within 45 minutes (or at least get close enough that you can do it with some, but not too much, coaching). It's not at all over the top that a rusty person would need to spend 50+ hours to get fluid with this. If your data structures, bit manipulation, tree traversal, dynamic programming, threading, or other topics are very rusty, you will need to study before beginning your study. It's not at all uncommon to spend an amount of time that starts to approach bar exam preparation levels. One interview typically lasts all day. So preparing for and completing three interviews is actually roughly on a par with taking the bar exam. Unfortunately, you rarely get feedback on your performance (for legal reasons, I understand). You have no idea if your exam was graded fairly or consistently, and you have no idea if your examiners have the credentials and expertise to actually understand a novel solution. Sometimes you get advance warning about what might be tested but other times you are completely blindsided by the questions. Once you pass the bar, you've passed. Software interviews, on the other hand, you have to do over and over. And even worse, we often present these tests as sniffing out frauds rather than looking for exceptional talent (ie., an exceptional performance on these exams rarely get you much above the job offered, so it's more about not losing than winning). Really, there's a tremendous amount to object to here. You don't have to think you're amazing or above it all to start thinking this is a serious problem that may be driving talented people away from our industry. I've read various blog posts about potentially promising candidates who aren't interviewing anymore simply because they're too intimidated, or because they just can't afford to put 50+ hours of study into something that may be completely capricious and depend purely on what some overworked programmer thinks is important that day. I can't imagine my graduate program's MS exit exam, or the bar, or the state nursing license board, or any respectable exam committee getting away with being so capricious and opaque. Now, I've hired before, and I'd be afraid to hire without a technical exam. So I hear you, I really do. And I've been on technical interviews, even tough ones, that I actually kind of enjoyed (I so rarely do real dynamic programming or tree traversal, and it is actually kind of fun, under the right circumstances). But we spend so much time talking about a desperate shortage of software engineers, and so little time actually recognizing some of the things that make our industry really exceptionally unpleasant. I think we should recognize that tech exam/interviews, while perhaps necessary, are also a potential problem, enough of a problem that some people are starting to boycott them altogether (I will do them, though I won't do an unpaid take-home ever again). It may in fact be an ego problem some of the time, but since there's clearly a more legitimate reason to object to this practice, let's start there, rather than dismissing this as an ego problem.