3 ms·
I like how the performance evaluation seems to be fairly realistic - I used Ruby and my algorithm could have been more efficient (O(n) space, and O(n) time but
by samstokes 17y ago
I like how the performance evaluation seems to be fairly realistic - I used Ruby and my algorithm could have been more efficient (O(n) space, and O(n) time but with more traversals than necessary), but I scored 100 because I met all the stated constraints. (http://codility.com/demo/results/?id=demo8XKE77-H8G http://codility.com/demo/results/?id=demo8XKE77-H8G if anyone wants to refer to and/or mock my code.) It seems to me "ability to solve problems well enough under time pressure" is exactly what you want a simple hands-off test like this to screen for.
In face-to-face interviews you'd probably follow up by adding constraints: "your algorithm uses O(n) space in addition to the input, can you do it in constant space?". It would be cool if Codility supported that kind of workflow - following up the submitted solution with refinements on the original question. (Relatedly - do you support the workflow where you get a second try if you didn't get 100, maybe because the evalution revealed a constraint that wasn't clearly stated in the problem outline?)
- samstokes 17y ago(If you are looking at my solution and wondering what that monkeypatched Array#sum is doing there - it's a red herring, abandoned early on.)
- marcin 17y agoYou can assign up to 6 tasks per each test, to minimize the 'constraint omission' risk. Does it solve the issue you raised?
- jakacki 17y agoWith paid account it is possible to reopen a task after one solution has been submitted, so the recruiter can "give another chance" to the candidate (although we generally suggest not to), which supports the workflow you describe.