4 ms·

Clearly the person didn't run the code. The factorial function returns an int. The factorial of 13 is already too big for a 32-bit int. The factorial of 21 is b

Clearly the person didn't run the code. The factorial function returns an int. The factorial of 13 is already too big for a 32-bit int. The factorial of 21 is bigger than a 64-bit int.

kyberias 9y ago
I think the code people have to write in interviews is not supposed to work/scale in the real world. The purpose usually is to test whether the candidate can implement a correct algorithm. Even though this is Java (?), it's used more like pseudo code. A follow up question could be: "Do you see some problems with running this with big numbers? How would you scale it?"
- rafiki6 9y ago
  So why ask people to write "code". What are you testing?
  - kyberias 9y ago
    Personally, I think that asking people to write code in interviews brings very _limited_ data. However, from my experience, it usually is also a very _strong_ signal. Narrow but strong. For example, if a candidate cannot implement a simple algorithm (like the factorial here), he very likely has poor skills. If he can implement it without too much trouble, that's a good sign, but he only proved that he probably has some good skills. Again, the signal is narrow but strong.
    - throw401 9y ago
      And is the signal still strong if candidate has a bad day or for some other reason cannot get the right focus in that specific moment? Moreover, I think it's highly unprofessional to reinvent the wheel by writing most algorithms for production. I always first look for a bullet proof library for that. Won't you use a calculator for 345 x 27?
      - chrisdbaldwin 9y ago
        345 x 27 = 2415 + 6900 = 9315 You don't need a calculator. Use your brain and show your work.
      - Jach 9y ago
        Nothing but "try applying again in 6-12 months" can fix the "candidate is having a bad day" cause for a false negative, don't know why you're bringing that up. Similarly this thread is about code in the context of interviewing, not production code, so the whole side-argument about when libraries are/aren't appropriate doesn't seem relevant... As a candidate I've been asked things like "write code to reverse this string" and I've given "this_str[::-1] is probably what I'd use on the job. Do you really want me to write a str_reverse() function? Does it need to be in-place?" Each time is yes at least for the first question, so I do it, but I wouldn't expect it to go to production. When I'm on the interviewer side and made to ask questions like string reverse or whatever I say "no, you don't have to do the lower level implementation", all I'm trying to verify is that someone can program, not that they can program arbitrary foo the way I want it done, but typically people start with the low level function, even when I say "use whatever language you want" they still go for Java or similar.
      - kyberias 9y ago
        Yes, I think it is fairly _realiable_. It reveals whether the candidate can't really write code. Again, the idea of the coding test in interviews is not to produce production quality code. It is testing that the candidate's brain can write some code. Try to understand that. Is it a perfect measurement? Of course not. Also, the idea is to select an algorithm that doesn't require encyclopedic knowledge of different algorithms. Even (any) sorting algorithms may be too complex for this purpose.
    - rafiki6 9y ago
      I don't mean to be offensive but reading your statement alone shows me your bias. 1) You constantly referred to the developer as he. You may not realize it but the language you use is an indication of the prototypical picture of a developer you have in your head 2) You are making a strong assumption based on one point of data, your "experience". I am not trying to belittle it but here's a counter. Based on my experience, I have hired developers who did great at algorithmic interviews, design and coding. Guess what, they SUCKED as developers. They didn't understand architecture. They weren't willing to learn a new language or framework. They couldn't properly evaluate why a framework would perform poorly. They had terrible communication skills which matter because their team didn't understand them and they couldn't make a strong case for why their point was right. Point is, although there might be place for algorithm coding in developer interviews, I am willing to wager a large chunk of my salary that performing well in algorithm interviews doesn't necessarily correlate strongly to performing well on the job. Why? Performing well on the job needs to be properly defined in it's context first.
      - kyberias 9y ago
        > I don't mean to be offensive but reading your statement alone shows me your bias. 1) You constantly referred to the developer as he. You may not realize it but the language you use is an indication of the prototypical picture of a developer you have in your head Why on earth do you bring this bullshit sexism to this discussion? Of course I have a prototypical picture of a developer in my head. Like everyone. So what? I have interviewed developers and 99% of them have been male. I'm not arguing anything about that percentage here. Let's just assume _male_ developers here then if that makes you feel better. > Point is, although there might be place for algorithm coding in developer interviews, I am willing to wager a large chunk of my salary that performing well in algorithm interviews doesn't necessarily correlate strongly to performing well on the job. You don't have a point. It doesn't matter how well they communicate, or anything, IF THEY CANNOT CODE. It also doesn't matter if they can code it they cannot communicate. I'm _not_ saying that coding skill is THE ONLY skill they must have. Get that to your head already. It's ONE of the many skills that they absolutely must have. Another skill is the ability to express their ideas clearly. There are others of course but we are discussing "programming tests in interviews" here. In addition, I don't believe interviews or any tests during interviews can accurately predict job performance. I think there are a lot of studies that support this. Even though all the tests show green light, the person can fail in the actual job. Nothing guarantees that 100%. We get false positives. But that doesn't mean interview tests are useless!
- logfromblammo 9y ago
  A double only has 52 bits of precision, but in a factorial, every second number in the multiplication has at least one factor of two in it, so you could get to 22! that way without any loss of precision. Beyond that, "it depends" on what you're doing with the results. It's very likely that the developers' time would be better spent removing the factorial from the calculation that uses it, than on making the factorial calculation better at calculating factorials. Besides that, since you can only meaningfully do 22 different factorials within the bounds of a 64-bit architecture anyway, just pre-calculate the results and make it a lookup table. Returns in O(c).
  - nwellinghoff 9y ago
    What do you mean you can "only meaningfully do 22 different factorials within the bounds of a 64-bit architecture anyway"?
    - logfromblammo 9y ago
      The 52-bit mantissa of a 64-bit double is only sufficient to represent all the significant figures of 22! and a 64-bit integer can only represent 20!, so if you want larger factorials with full precision, you need to use more bytes for your numeric representation. Not many real-world applications require precision greater than a double, but pure mathematics can calculate millions of [decimal] digits of an irrational number just for amusement. A cryptography application, for instance, would need full precision, whereas an engineering problem might be perfectly fine with fewer significant digits.
- NTDF9 9y ago
  >> I think the code people have to write in interviews is not supposed to work/scale in the real world. The purpose usually is to test whether the candidate can implement a correct algorithm Do you check for nulls in linked list traversals? Potential stack overflows? How about array out of bounds? If yes, why don't you check their data type? Do you now see why this process is fucked up? The candidate doesn't know what is your definition of "ok"
  - kyberias 9y ago
    I think you have misunderstood the purpose of these tests. No, the process is not fucked up. There is no one right answer. It is CLEAR that the candidate cannot write perfect code in an interview. But it can still provide valuable data. Basically it can answer to this question: "has the candidate got _any clue_ about programming?". Sometimes that has a lot of value. Think about a candidate that cannot even write a function that calculates the length of a null-terminated string, for example. Doesn't that test tell you immediately that something is terribly wrong? I've seen these candidates. When you get over a certain skill threshold, every candidate passes the coding test. After that, it's useless, of course. Then it's probably best to show some code and discuss. NO SINGLE recruitment test can provide absolute certainty. Coding in interview is just one variable.

Clearly the person didn't run the code. The factorial function returns an int. The factorial of 13 is already too big for a 32-bit int. The factorial of 21 is bigger than a 64-bit int.

kyberias 9y ago

I think the code people have to write in interviews is not supposed to work/scale in the real world. The purpose usually is to test whether the candidate can implement a correct algorithm. Even though this is Java (?), it's used more like pseudo code. A follow up question could be: "Do you see some problems with running this with big numbers? How would you scale it?"

rafiki6 9y ago
So why ask people to write "code". What are you testing?
- kyberias 9y ago
  Personally, I think that asking people to write code in interviews brings very _limited_ data. However, from my experience, it usually is also a very _strong_ signal. Narrow but strong. For example, if a candidate cannot implement a simple algorithm (like the factorial here), he very likely has poor skills. If he can implement it without too much trouble, that's a good sign, but he only proved that he probably has some good skills. Again, the signal is narrow but strong.
  - throw401 9y ago
    And is the signal still strong if candidate has a bad day or for some other reason cannot get the right focus in that specific moment? Moreover, I think it's highly unprofessional to reinvent the wheel by writing most algorithms for production. I always first look for a bullet proof library for that. Won't you use a calculator for 345 x 27?
    - chrisdbaldwin 9y ago
      345 x 27 = 2415 + 6900 = 9315 You don't need a calculator. Use your brain and show your work.
    - Jach 9y ago
      Nothing but "try applying again in 6-12 months" can fix the "candidate is having a bad day" cause for a false negative, don't know why you're bringing that up. Similarly this thread is about code in the context of interviewing, not production code, so the whole side-argument about when libraries are/aren't appropriate doesn't seem relevant... As a candidate I've been asked things like "write code to reverse this string" and I've given "this_str[::-1] is probably what I'd use on the job. Do you really want me to write a str_reverse() function? Does it need to be in-place?" Each time is yes at least for the first question, so I do it, but I wouldn't expect it to go to production. When I'm on the interviewer side and made to ask questions like string reverse or whatever I say "no, you don't have to do the lower level implementation", all I'm trying to verify is that someone can program, not that they can program arbitrary foo the way I want it done, but typically people start with the low level function, even when I say "use whatever language you want" they still go for Java or similar.
    - kyberias 9y ago
      Yes, I think it is fairly _realiable_. It reveals whether the candidate can't really write code. Again, the idea of the coding test in interviews is not to produce production quality code. It is testing that the candidate's brain can write some code. Try to understand that. Is it a perfect measurement? Of course not. Also, the idea is to select an algorithm that doesn't require encyclopedic knowledge of different algorithms. Even (any) sorting algorithms may be too complex for this purpose.
  - rafiki6 9y ago
    I don't mean to be offensive but reading your statement alone shows me your bias. 1) You constantly referred to the developer as he. You may not realize it but the language you use is an indication of the prototypical picture of a developer you have in your head 2) You are making a strong assumption based on one point of data, your "experience". I am not trying to belittle it but here's a counter. Based on my experience, I have hired developers who did great at algorithmic interviews, design and coding. Guess what, they SUCKED as developers. They didn't understand architecture. They weren't willing to learn a new language or framework. They couldn't properly evaluate why a framework would perform poorly. They had terrible communication skills which matter because their team didn't understand them and they couldn't make a strong case for why their point was right. Point is, although there might be place for algorithm coding in developer interviews, I am willing to wager a large chunk of my salary that performing well in algorithm interviews doesn't necessarily correlate strongly to performing well on the job. Why? Performing well on the job needs to be properly defined in it's context first.
    - kyberias 9y ago
      > I don't mean to be offensive but reading your statement alone shows me your bias. 1) You constantly referred to the developer as he. You may not realize it but the language you use is an indication of the prototypical picture of a developer you have in your head Why on earth do you bring this bullshit sexism to this discussion? Of course I have a prototypical picture of a developer in my head. Like everyone. So what? I have interviewed developers and 99% of them have been male. I'm not arguing anything about that percentage here. Let's just assume _male_ developers here then if that makes you feel better. > Point is, although there might be place for algorithm coding in developer interviews, I am willing to wager a large chunk of my salary that performing well in algorithm interviews doesn't necessarily correlate strongly to performing well on the job. You don't have a point. It doesn't matter how well they communicate, or anything, IF THEY CANNOT CODE. It also doesn't matter if they can code it they cannot communicate. I'm _not_ saying that coding skill is THE ONLY skill they must have. Get that to your head already. It's ONE of the many skills that they absolutely must have. Another skill is the ability to express their ideas clearly. There are others of course but we are discussing "programming tests in interviews" here. In addition, I don't believe interviews or any tests during interviews can accurately predict job performance. I think there are a lot of studies that support this. Even though all the tests show green light, the person can fail in the actual job. Nothing guarantees that 100%. We get false positives. But that doesn't mean interview tests are useless!
logfromblammo 9y ago
A double only has 52 bits of precision, but in a factorial, every second number in the multiplication has at least one factor of two in it, so you could get to 22! that way without any loss of precision. Beyond that, "it depends" on what you're doing with the results. It's very likely that the developers' time would be better spent removing the factorial from the calculation that uses it, than on making the factorial calculation better at calculating factorials. Besides that, since you can only meaningfully do 22 different factorials within the bounds of a 64-bit architecture anyway, just pre-calculate the results and make it a lookup table. Returns in O(c).
- nwellinghoff 9y ago
  What do you mean you can "only meaningfully do 22 different factorials within the bounds of a 64-bit architecture anyway"?
  - logfromblammo 9y ago
    The 52-bit mantissa of a 64-bit double is only sufficient to represent all the significant figures of 22! and a 64-bit integer can only represent 20!, so if you want larger factorials with full precision, you need to use more bytes for your numeric representation. Not many real-world applications require precision greater than a double, but pure mathematics can calculate millions of [decimal] digits of an irrational number just for amusement. A cryptography application, for instance, would need full precision, whereas an engineering problem might be perfectly fine with fewer significant digits.
NTDF9 9y ago
>> I think the code people have to write in interviews is not supposed to work/scale in the real world. The purpose usually is to test whether the candidate can implement a correct algorithm Do you check for nulls in linked list traversals? Potential stack overflows? How about array out of bounds? If yes, why don't you check their data type? Do you now see why this process is fucked up? The candidate doesn't know what is your definition of "ok"
- kyberias 9y ago
  I think you have misunderstood the purpose of these tests. No, the process is not fucked up. There is no one right answer. It is CLEAR that the candidate cannot write perfect code in an interview. But it can still provide valuable data. Basically it can answer to this question: "has the candidate got _any clue_ about programming?". Sometimes that has a lot of value. Think about a candidate that cannot even write a function that calculates the length of a null-terminated string, for example. Doesn't that test tell you immediately that something is terribly wrong? I've seen these candidates. When you get over a certain skill threshold, every candidate passes the coding test. After that, it's useless, of course. Then it's probably best to show some code and discuss. NO SINGLE recruitment test can provide absolute certainty. Coding in interview is just one variable.