I've recently started doing the monthly coding challenge from Codility. I'm doing them mostly for fun, to learn, and to keep my programming skills sharp, but I'm also doing them to certify myself a little and prove I can actually code.
Each challenge is a single programming problem with a two hour time limit. If candidates submit and fail, or run out of time, they can try again, so the time limit is more of a nice-to-have than a hard requirement. The solution can be written in the simple web-based IDE provided, or it can be written elsewhere and pasted in. Candidates can choose from a number of languages, including (but not limited to) C, C#, C++, Java, JavaScript, Perl, Python, Ruby or Scala. If C# is chosen, Mono is used to compile and run the solution. There is a comment asking solutions be limited to .NET 2.0, but the site will compile and evaluate .NET 3.5 code, so I've been ignoring that possibly outdated instruction.
In a nutshell, the Codility challenges test the candidate's knowledge of algorithms and data structures and their ability to adapt them to the problem at hand. Each challenge has an expected time and space complexity which usually precludes a naive solution from passing the large input tests. For example, for a string/substring problem with an expected complexity of O(N), it may be difficult to get full marks without some prior knowledge of KMP or related algorithm. To bone up beforehand, candidates can read one of the many catalog texts on algorithms, or they can do some of Codility's older challenges, some of which have posted solutions.
What isn't tested is the candidate's ability to communicate effectively with product owners, whether they can write DRY, readable, and fully tested code, or any of the other 101 things that make a programmer "good". In fact, in almost two decades of programming, I've rarely had to write code that resembles what I've written for the Codility challenges. It's the sort of code that could be covered by a decent library, or is perhaps written for low powered devices or very high traffic web applications where CPU/battery and RAM/storage are at a premium. I don't believe in premature optimisation. If a naive algorithm gets the job done, is easy for everyone to understand, and doesn't impact the rest of the application adversely, shouldn't it be preferred? The most expensive resource in the majority of projects is usually developer time.
That said, as a developer my job has always involved solving hard problems, and that is one ability I think the Codility challenges manage to test very well. I'm getting a massive kick from doing them.
There are 0 comments.
Older
Priority Queue
Newer
HACT '13
Older
Priority Queue
Newer
HACT '13
browse with Pivot
Codility Nitrogenium Challenge
OS X Lock
HACT '13
Codility Challenges
Priority Queue
Architecture (13)
ASP.NET (2)
ASP.NET MVC (13)
Brisbane Flood (1)
Building Neno (38)
C# (4)
Challenges (3)
Collections (1)
Communicator (1)
Concurrency Control (2)
Configuration (1)
CSS (5)
DataAnnotations (2)
Database (1)
DotNetOpenAuth (2)
Entity Framework (1)
FluentNHibernate (2)
Inversion of Control (5)
JavaScript (1)
jQuery (4)
Kata (2)
Linq (7)
Markdown (4)
Mercurial (5)
NHibernate (20)
Ninject (2)
OpenID (3)
OS X (1)
Pivot (6)
PowerShell (8)
Prettify (2)
RSS (1)
Spring (3)
SQL Server (5)
T-SQL (2)
Validation (2)
Vim (1)
Visual Studio (2)
Windows Forms (3)
Windows Service (1)
Comments
Leave a Comment
Please register or login to leave a comment.