Posted: 15/04/2021

Job Search 2021 _ Another Programming Test _ Feedback

I wrote about this programming test recently for a job interview.

Since it has been submitted, I have had some feedback, which I would like to follow up with.
Unfortunately, the company decided that they would not give me the opportunity to talk with them further about the role and programming experience, which I feel is a big loss for both of us. I always enjoy a conversation about code improvements, and it would have given them a view into my approach to the test. That all said, the offer was not available.

So I thought I would work through those issues here:

The remit was:

You have been asked to:

Refactor the code using clean coding principles to make the code maintainable
Add new features
Write tests to prevent functionality from breaking

When reviewing the test, we look for a solution which:

Is clean, easy to understand and maintainable
Shows an understanding of software craftsmanship
Doesn’t break the existing functionality

We recommend you spend 4 hours on your solution.

These are some of the comments I had in return:

Invalid customer input is not handled
If entered partial correct input then it adds a customer rather than showing UNKNOWN INPUT.
Few bugs in the code are not fixed including in the new features
Code is over-engineered in places in a way which makes it harder to follow
“ref” is used in a few places without any need to.
a lot of use of .GetType() == typeof rather than using is or .OfType.
Used Builder pattern instead of Factory pattern

So these break down into a few categories:

Fixing existing bugs
Not testing thoroughly the new feature code
Not using the style of syntax they prefer
Architectural concerns

Taking each in turn:

Fixing existing bugs

With any existing code, there are bugs. We all know this.
This existing code had no unit tests. The remit did not mention trying to improve the code, in fact, you could argue (badly) that you are breaking existing functionality! Either way, with the 4 hour recommended time spent, this was just unfeasible.

Not testing thoroughly the new feature code

You got me here, there are conditions I have not tested. These are simple edge cases they have mentioned, but with the code refactoring I have done, these are simple to add and to test. 10 minutes work!

Not using the style of syntax they prefer

Everyone has there own compiler syntax they prefer, sometimes these are for good reasons, such as performance, other times these are because the are more readable.
The readability is subjective for sure, but not knowing the coding standards of the org (other than the code supplied), then this is a harsh comment to make with no discussion.

Architectural concerns

These are very valid concerns. If I had done this within a company, I would have talked these choices through with a colleague. However this was a test, and unless you count my 5 year old I had no one to discuss these ideas with.
Again not having the chance to discuss these concerns after the fact with the employer is frustrating.

What are your thoughts? Should I go back to them with an updated version??

Thanks for reading this post.

If you want to reach out, catch me on Twitter!

Tweet to @MicbOliver

I am always open to mentoring people, so get in touch.