Today was conducted by our coach Sam, and was focused entirely on tech tests. Tech tests are used by hiring partners to vet candidates before the interview stages, and today we sat two different tech tests in preparation for the hiring process.
Getting started with tech tests
In the morning we were given a video to watch by world famous agile developer Fred George about OOP best practices, before being given a kata to work on. The kata could be solved in any language of our choice, and I opted to use Ruby as it's very familiar by now. The intention was not to complete the kata, we didn't have enough time for that, it was simply an exercise in learning how to begin solving a tech test. This might sound a bit odd, but knowing exactly where to begin can pose a daunting problem, especially when you're feeling understandably nervous. For much of the Makers Academy course we've either been given a basic repo to work from, or have been using a framework that produces a lot of boilerplate code for us. Conversely when beginning a tech test like this kata we're given nothing but a set of instructions, and have do everything including initialising the Git repo, initialising the testing frameworks, determining the dependencies, and structuring the project directory.
After a couple of hours we were brought into a group video meeting for Sam to critique a select handful of our attempts. As expected none of us had managed to complete the kata in the given time, but it was good to see that we all seemed to know how to get started, and everybody had a well set up project which could be successfully built upon given more time.
In the afternoon we were given a new tech test to attempt, the famous Gilded Rose refactoring kata in Ruby. The idea behind this kata is to provide a huge mess of code that needs to be refactored. At the start we're provided with a huge method containing an absolute mess of nested ‘if' statements, which is functional but almost impossible to understand in its current form. We're also provided with basic instructions as to what this code is supposed to do. The system I used to tackle the problem was to begin by writing Rspec tests for the existing mess of code based upon the requirements given, so that when I came to start refactoring I could be sure that I wasn't breaking any functionality. My plan was then to begin extracting the various ‘if' statements into methods, and then finally to begin extracting those methods into separate classes.
In the time given I didn't get anywhere close to completing the test, but I really enjoyed this kata and intend to complete it several times in the future to improve my refactoring abilities. Once the allotted time was up we once again regrouped for Sam to critique the solutions of anybody brave enough to put theirs forward. It was interesting to see how everybody attempted the same challenge in different ways, and as usual Sam's advice was a goldmine of useful information.
Seeing and attempting these tech tests, both of which have been previously used by some of Makers Academy's hiring partners, has left me with a very good idea of what to expect from the technical side of the hiring process. Today has left me reassured, because during both tests I've felt comfortable, and have been able begin writing my solutions very quickly.