3 ms·

That's exactly why you shouldn't employ "good enough" programmers - always try to recruit the best possible. It takes time, but tools like http://codility.com h

That's exactly why you shouldn't employ "good enough" programmers - always try to recruit the best possible. It takes time, but tools like http://codility.com http://codility.com might help with the elimination of wrong candidates.

jrockway 17y ago
You should employ good programmers, but even good programmers make mistakes. It's even better when you give good programmers good tools. Computers don't make mistakes, so it's nice when one will catch yours.
Silhouette 17y ago
Are you connected with Codility in any way?
- decode 17y ago
  He's only the CEO: http://uk.linkedin.com/in/krzysztofkowalczyk http://uk.linkedin.com/in/krzysztofkowalczyk
- sshumaker 17y ago
  He's the CEO of Codility, according to his linkedin.
- Silhouette 17y ago
  I just took their sample test to see what it was like. I was disappointed that they disallow the use of external libraries, but then criticise C++ code that is vulnerable to the obvious integer overflow. In a real interview, I would expect a good candidate to indicate that they would pull in a bignum library to avoid this, but there is no way to say that in this sort of test. Likewise, depending on the exact specifications, you might consider using a 64-bit integer type to hold the sum, but that's not portable yet. Presumably, if you're limited to standard C++ (which has no bignum library) and required to pass the overflow test to get a top score, the only way to do this is to reimplement the relevant parts of a bignum type. Of course, that is exactly the wrong thing to do if you have to solve this sort of problem in reality. It is particularly unfortunate that they would criticise a candidate's code for this, while at the same time making a basic mistake themselves in the specification for the equi function. (If, as the problem states, there may be many elements in the input, then the correct return type for an index into a std::vector<int> would be a std::vector<int>::size_type, not an int. A size_type is always unsigned, so returning -1 in the event of finding no match is a bad idea.)
- csmeder 17y ago
  Hmmm it doesn't seem to understand the < symbol? Compiler output: wrapper.java:23: not a statement for(int i =0; i++; i<A.length()) ^

jrockway 17y ago

You should employ good programmers, but even good programmers make mistakes. It's even better when you give good programmers good tools. Computers don't make mistakes, so it's nice when one will catch yours.

Silhouette 17y ago

Are you connected with Codility in any way?

decode 17y ago
He's only the CEO: http://uk.linkedin.com/in/krzysztofkowalczyk http://uk.linkedin.com/in/krzysztofkowalczyk
sshumaker 17y ago
He's the CEO of Codility, according to his linkedin.
Silhouette 17y ago
I just took their sample test to see what it was like. I was disappointed that they disallow the use of external libraries, but then criticise C++ code that is vulnerable to the obvious integer overflow. In a real interview, I would expect a good candidate to indicate that they would pull in a bignum library to avoid this, but there is no way to say that in this sort of test. Likewise, depending on the exact specifications, you might consider using a 64-bit integer type to hold the sum, but that's not portable yet. Presumably, if you're limited to standard C++ (which has no bignum library) and required to pass the overflow test to get a top score, the only way to do this is to reimplement the relevant parts of a bignum type. Of course, that is exactly the wrong thing to do if you have to solve this sort of problem in reality. It is particularly unfortunate that they would criticise a candidate's code for this, while at the same time making a basic mistake themselves in the specification for the equi function. (If, as the problem states, there may be many elements in the input, then the correct return type for an index into a std::vector<int> would be a std::vector<int>::size_type, not an int. A size_type is always unsigned, so returning -1 in the event of finding no match is a bad idea.)
csmeder 17y ago
Hmmm it doesn't seem to understand the < symbol? Compiler output: wrapper.java:23: not a statement for(int i =0; i++; i<A.length()) ^