Advertisement

Codility - Is it reasonable?

Started by September 17, 2010 01:33 PM
54 comments, last by way2lazy2care 12 years, 9 months ago
I admit that Codility is a tad harsh, but overall, it is a great tool. You should have good programming habits all the time, not just when asked. Expect the worst case scenario unless instructed otherwise. You being upset over lack of instruction over how big the numbers become is like a prospective musician whining, "Well, you didn't tell me to play my best! You just told me to play a scale, so I did!"
Amateurs practice until they do it right.Professionals practice until they never do it wrong.
Quote: Original post by Antheus
You can't ask during automated interview.


I missed that it was automated.


Quote: Original post by Antheus
Fibonacci is *never* coded using recursion. The only exception is writing an introduction to algorithms and data structures, where it's used to demonstrate why recursion fails miserably. This is litmus test.


In interviews, if we ask people about fibonacci we will usually accept recursion as a first "naive" attempt. We will then follow up asking about its limitations and perhaps ask them to code it in constant memory space.

Obviously, you would never use a recursive solution in an actual piece of software, but in the context of the interview we usually don't mind an interviewee putting out a naive or trivial solution as long as he recognizes its not optimal, why its not, and can explain how to do it optimally.
Advertisement
Quote: Original post by TheBuzzSaw

"Well, you didn't tell me to play my best! You just told me to play a scale, so I did!"


Two explorers are sleeping in a tent. They hear a lion outside. First one tries to run away but sees the other one putting on sneakers.
- Why are you putting on sneakers? You can't outrun a lion even with them
- I don't need to outrun a lion - just you

Being best is about being just slightly better than the competition.
Testing candidates using really simple problems is a good idea in general. One problem that I see with this approach though is that this only tests coding ability but not debugging ability - even though debugging ability is probably much, much more important in the long run.

It's possible that a company that relies only on this test might miss out on an awesome debugger, just because she forgot to check for a stupid boundary case in one of the tests (it is my understanding that once you submitted your solution, you cannot go back when you see that a test fails, even though you might immediately realize what your mistake was).
Widelands - laid back, free software strategy
Quote: Original post by mkuz
In description Codility did not mention that they score not only correctness, but also program performance.

Of course. Employers are looking for staff who will do their best work all the time, not just when they are explicitly asked. You're interviewing/testing for a job; it should be obvious that you need to do the most efficient solution, not just he minimum work necessary to solve the problem.
Dan Marchant - Business Development Consultant
www.obscure.co.uk
I tried their sample tests and used this code:

int equi ( const std::vector<int> &a){  if (a.size() == 0) return -1;  for( long long i = 0; i < a.size(); i++ )  {    long long sum_left = 0;    long long sum_right = 0;    for( long long j = 0; j < i; j++ ) sum_left += (long long) a[j];    for( long long j = i + 1; j < a.size(); j++ ) sum_right += (long long) a[j];    if( sum_left == sum_right ) return i;  }  return -1;}


It only got 75 out of 100 how would you score higher?
Advertisement
Here is a thread on codility where people discuss the sample problem.
int equi ( const vector<int> &A ){    if (!A.size()) return -1;    long long left = 0;    long long right = 0;    size_t index = 0;    for (size_t i = 1; i < A.size(); ++i) right += A;    size_t top = A.size() - 1;    while (left != right && index < top)    {        left += A[index];        ++index;        right -= A[index];    }        if (index >= A.size() || left != right) return -1;    return index;}
Amateurs practice until they do it right.Professionals practice until they never do it wrong.
I'm candidate #1 xD lololol

Never knew about Codility. Pretty cool stuff. Prolly could have written it in less time, but I wanted to make sure it had every optimization I could imagine.
Two things are infinite: the universe and human stupidity; and Im not sure about the universe. -- Albert Einstein
Machine-scored coding tests might prevent the company from wasting time on bad candidates, but it'll also (at least) occasionally prevent the company from getting the best of the best. Judging efficiency without listing it as a grading point sounds like a bad idea to me - you'll end up paying more per unit work due to premature optimization, associated debugging, etc.

IME, it is far better to use open-ended pre-screen questions that are judged by humans. For example, "Describe what happens when you open a URL in your browser." This works very, very well for my employer.
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk

This topic is closed to new replies.

Advertisement