6 things we learned from Julian Ghionoiu about putting your coding techniques to the test and becoming a better developer
As part of our Aspiring Principal Engineers series of events, and in partnership with my company RecWorks, we held a Q&A with Julian Ghionoiu, CTO and Founder of Accelerate.io, a company that creates scenario-based challenges that mimic what developers do as part of their job, and that employers can use to assess candidates.
We invited a panel of developers to ask Julian just what he has learned from seeing so many candidates use these tests, and what lessons can be taken from them in order to become a better developer.
Don’t have time to watch the whole thing? You don’t have to.
Here are 6 practical ways you can put your coding techniques to the test and give yourself the edge.
1. Repetition is key to getting better
The Accelerate.io model uses ‘Katas’, a term from martial arts in which you repeat the same exercise making small improvements each time. A code Kata could be an exercise in any technical area, such as a vending machine or score card programme. The key, as Julian says, is consistency. So set yourself a coding challenge, and once you have completed it, try it again and again and again in the same conditions and reflect afterwards on how it went and how you (hopefully!) improved.
2. Take any design project through a 5 rounds exercise
Again, this mirrors the way that Accelerate.io assesses developers’ skill to take an initial abstraction through successive integrations without running into errors or running out of time.
it’s also common sense to ensure that any initial piece of code can withstand additional requirements, and accommodate changes. So test your work using this same benchmarking process and see how you perform!
3. The simplest solution will always win in the end
The more complex the initial design, the harder it will be to change in the long run and this will slow you down as a developer. And as we know, time, as well as accuracy, is a measure of success when it comes to writing elegant code. Julian recommends that you focus on simplicity to avoid the timely cost of a bad abstraction. “The more you can defer design decisions the better” he recommends.
4. Know your tooling
If you are completely confident with your tools, for instance “with your ID, with your language, this then frees you up to think about abstractions.” Not only will this help you work faster, but it will also allow you to make certain technical decisions, such as refactoring, when things are not working at an earlier stage. This brings us to…
5. Don’t be afraid to refactor!
It is very tempting, when experiencing problems, to attempt to resolve these and save time by building on your existing code. But, as Julian cautions, if this approach does not work, it can cause a lot of pain later on and severely extend the testing phase; you risk simply moving that time you saved further down the line. If, however, you are secure in your tooling skills you will feel confident to restructure you code, and get it absolutely right.
6. Carry out whiteboarding or pairing sessions to discuss your experiences
In any given recruitment process the technical assessment is only half of the story. Employers will also expect you to be able to discuss your successes and challenges in any given project and may pair you up with members of their teams. So start modelling your work right now on this approach, and set up times to reflect on a piece of work; what went well and what you could have done better. This will help build your confidence for interviews, and ultimately make you a better developer.
This Q&A event was organised by RecWorks, a community-driven recruitment agency focussing on tech placements in London. RecWorks are the creators of many groups and communities including Meet-a-Mentor, a free slack group that introduces aspiring CTOs to experienced CTOs, as well as more junior developers 2000 introductions made and counting! They also founded one of the largest Java User Groups in Europe, the 7000 strong London Java Community.
