Stumbling Through

Join me as I stumble, bumble and fumble my way through some new developer technologies. We'll laugh, we'll cry, there may be a mouse tossed through a monitor, but in the end we will all hopefully learn something.
in

Stumbling Through - Coding Challenges

While this is a bit of a departure from the theme of my blog, the Coding Challenge recently held by Clarity Consulting for its employees is an event that I feel is worth blogging about.  The reason it is of particular interest to me is that behind my calm, mild-mannered demeanor I am a fiercely competitive person - not from the standpoint that I must win everything I compete in but in that I simply love the thrill of the competition itself.  There is also the fact that on any given work day, I could go home thinking I must be the greatest developer in the world or go home thinking that I must have chosen the wrong profession; outside of my grades in college (which mean absolutely nothing in the real world) I have no way to judge or rank my developer skills.  Thusly, I was very excited to hear about an opportunity to test my abilities against a number of other Clarity consultants, and proceeded to completely ignore preparing in any way, preferring to 'stumble through' it as I do everything in my life (not that there was much to prepare for, really, as you'll see).

Come time for the challenge, I learned that there were going to be just three questions - an 'easy' one, a 'medium' one and a 'hard' one and we would gain points according to how quickly we submitted a working solution to the problem.  Nobody knew what the questions would be until the challenge started, and the timer for the question would begin right when you read it.  The solution would consist of only one class file (either VB or C#) with a pre-determined public method signature that can accept a number of different parameters and return results in a pre-determined format for testing.  After submission, the class would be subjected to a number of tests consisting of various parameter values and the results would be validated (I am assuming an exception would count as failing the test as well).  If any one test failed, you would score a big fat zero for that solution.  This brings me to my one gripe with the challenge:  you could have written the greatest algorithm in the world faster than anybody else but forgot to handle one outside test case (such as null parameter) and you'd get no credit at all!  I had hoped you'd get points per test case that succeeded, but such was not the case.  Turns out, though, that the test cases weren't as hard-core as I thought, as I built my method without any error handling, bounds checking or null handling and manage to score full points so I guess I shouldn't gripe too much.  I would, however, still submit that the test cases should've been tougher as a 'good' developer wouldn't have forgotten to check for null parameter values like I forgot to do.

While I won't post my results here, I will say that I was both humbled by what the other Clarity consultants were capable of and emboldened by my own moderate success.  My experience was somewhat tainted by the fact that I had a specific time I needed to leave by and since we started the challenge very late I was severely handicapped by time.  Not that I am making excuses here, mind you, I have no confidence that I would've done any more had I another 50 hours much less another 50 minutes, but I was very disappointed to leave the challenge in progress.  I am very much looking forward to stumbling through the next tech challenge, I'll make sure I have no responsibilities afterwards this time and therefore, no more pathetic excuses!

All in all, it was a very fun event and is a good example of one of the many things Clarity does to keep a level of excitement and interest in the workplace.

Posted: Feb 15 2008, 12:39 PM by tbyrne | with 3 comment(s)
Filed under:

Comments

Jon Schuster said:

Just my opinion, but I would argue that the purpose of these sorts of challenges isn't to see if you're a "good" developer who knows to check for every single boundary case and stupid thing the user does. The point is simply to see if you can write an alogrithm that solves what I would call the "meat" of the problem - in other words, the part that doesn't involve all sorts of boundary cases - and, to an extent, how fast you can write it.

It's tricky in general to say what defines a good programmer/consultant/software developer/computer scientist, partially because these all mean different things, partially because people have different ideas of what they think they mean, and also because everyone has different opinions on what makes a person "good" in that role. I think it would be safe to say, though, that you can entirely judge someone's skills from their performance in a competition like this. Everyone has a blend of talents that they use in different ways.

I'm starting to get off-topic, and a little too "everyone is special" for my own taste, so I'll stop here before writing a full blog post of my own in the comments. I also just wanted to mention that I believe the test cases/conditions were explicitly mentioned in the problem statements. I'd have to double-check that to confirm, but usually these sorts of things will say what exactly the input will look like - empty strings, null, and otherwise.

I will say, I'm definitely looking forward to the next Clarity Top Coder Challenge.

# February 15, 2008 7:13 PM

David Hacker said:

If my memory serves (and it often fails), I think there were additional test cases outside of the one's given in the problem statements.  Not sure if they were boundary tests though, or maybe just tests to make sure people aren't hardcoding soutions.

# February 18, 2008 9:58 AM

Jon Schuster said:

It was just pointed out to me I had a typo in the above comment. That should have read that people's skills can NOT be judged entirely from a contest like this. Just wanted to make sure that was clarified.

# February 20, 2008 3:04 PM
Leave a Comment

(required) 

(required) 

(optional)

(required)