So I get confused pretty easily, and I like that.

Most for the time I get confused because my brain has a hard time storing & sorting the information that I’m provided with. The reason for that (as best I understand) is that my brain tends to store things as expressions rather than data; meaning that it does not remember details outside of the system but remembers the system and exceptions where my expression does not hold true. This means that when I receive contradictory information I get confused pretty fast and identify it as noise; but if I get a more subtle contradiction it creates an annoyance. These annoyances can bug me for days or years (my brain is exceptionally lazy when it comes to storing exceptions).

Yesterday I had one of those experiences;

After listening to a nice recruiter for a while about this amazing customer focused company (I was how they did what they did, rather than what they did) I was told that they wanted me to write a short program for them as part for the interview process. I love those things, coding katas are always fun and I’m always interested in doing them. So that peaked my interest, and I asked for the questions to be send over so I could complete them.

So it was not a coding kata, it was…. something different.

So leaving the 14 word problem statement out, these were these

Response instructions:

· Please provide 2 solutions, one implemented in Java, C# or C++ and the other solution described in paragraph form. One approach should optimize for runtime. The other should optimize for space. It is your choice as to which one is implemented and which one is described.

· For each solution, state the assumptions, the average runtime complexity and space complexity (memory usage) and worst-case runtime complexity and space complexity if they differ from average.

Important Details:

· The response should include 3 files: One README.txt with the explanation of the approaches and runtime and space calculation. One source code file (e.g. .java, .cs or .cpp) with the solution and one source code file with the unit tests demonstrating the solution.

· Code should be production ready – clearly written, runnable and include documentation.

· Unit tests should cover several examples that demonstrate the code working correctly on common use cases and any relevant degenerate cases.

· Code should not include any UI components, any facility for taking input at the console or any extraneous code not relevant to the solution.

Errr… ok. That was not what I expected. I was hoping for something like this [http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue]; If nothing else the problem statements are complete. Just the basic problem statement already had a number of issues that could only be resolved with more information about the exact problem. Or just make assumptions.

Optimizing based on assumptions is something I dislike; a lot.

Creating an optimized solution that is “production ready” is a really bad idea all together. Not to mention that “production ready” means something completely different to every person.

So I wrote up the questions I had from the first reading and send them off.

No response.

During that time I build out a little test harness, and had an even larger set of questions.

No response.

So I send in what I build along with a list of ~10 extra pieces of data that I’d really like to have before committing to any solution.

And I was left with this annoyance in the back of my mind.

So today I worked it out, I was asked by a company that was touted about being all about the customer to write software that required on my making 10 assumptions stacked on top of each other and ready to be slapped into production.

And to do so without talking to the customer. Their selection criteria for candidates actually evaluate the candidate’s ability to work in a manner counter to the stated company goal.

It is days like these where I like that I get confused easily, and it makes me smile when I figure out why statements annoy me.

Writing good questions is very hard to do, it is arguably an order of magnitude harder than answering them; But that is another topic.