I recently had the opportunity to complete an online coding challenge as part of the interview process for a company that I’m really excited about. After I had finished it, I found myself pondering what I was taking away from the experience, and what I had learned about myself as a programmer, and wanted to write a blog post to reflect upon that.
The coding challenge was done through Codility, and featured three sections: writing a SQL query to match a certain request; creating a basic algorithm; and designing a class that met a given set of expectations and had certain class methods. All sections were to be completed within 95 minutes. I chose to complete the latter two in javascript.
The SQL query was simple enough and I completed it quickly with pretty good confidence. The second section also proved to be rather easy, and I had a working solution created after a few minutes. One feature of the Codility platform is that while they will provide one example test case for testing your solutions, once submitted your solution will be tested with numerous other test cases, which might be edge cases or larger/smaller cases. Therefore, you are given the ability to insert your own test cases to check for all possibilities. I was worried about not having enough time to complete each section, so given that I felt good about my current solution for the second section, I chose to return to testing it more rigoriously once I had a working solution for the final section.
The last section proved to be by far the most challenging, and truth be told was something I hadn’t entirely expected. I had assumed the final section would be another classic algorithm, asking me to deal with a list of items or something of that nature. Instead, the problem posed was much more specific and centered around building functionality out for a class that could actually come up in real life. I love practicing algorithms and coding problems for the puzzles they offer, but sometimes what you’re asked to do can seem a little trivial. Instead, this challenge seemed much more like something that I could be asked to build in the future to provide needed resources to a user.
I have to admit, in my opinion I made several mistakes when approaching this challenge, though I ultimately think it was a fantastic learning experience. The largest mistake I made was not taking the time to look at the big picture of what this project needed. One of the reasons why this was such an awesome opportunity to improve my skills is because this was one of the first times I truly considered the concept of ‘software architecture’. I let the time constraints of the assignment stress me out, and I immediately rushed into meeting the expectations of the first function that was listed, rather than examining each component to decide how functions would need to work together, or how they could even help each other. By the time I got to the second function, I was starting to see the failings of how I had setup handling of the data I was dealing with. Towards the end I started to come up with an idea that I liked a whole lot more, but it seemed too late to implement it with any success.
I believe another way I can improve in the future, specifically when it comes to coding challenges, is taking my time to make something I’m proud of. Ultimately I (mostly) got a fully working solution created. However, truthfully I wasn’t particularly proud of what I had built. It might have gotten the job done and met most of the expectations, but it was messy, and time and space complexity issues weren’t addressed. In hindsight, I would have preferred to build something that was cleaner and smarter, even if it wasn’t complete. I would have rather had a well-crafted engine even if the rest of the parts weren’t there yet, than a clunker that can technically still drive, as I think that speaks more to my understanding of the concepts I have learned over the past year.
All that being said, one of the largest ideas I am taking away from this experience is how much it has confirmed how much I love programming. I spent hours after the assignment pondering the problem and how I would have preferred to solve it, and I found myself unable to let it go until I had sat down and written what I would have liked to have done. And to be honest, it was fun. As nerdy as that may sound, taking the time to work through the issues, I found myself enjoying the process as well as the opportunity to continue to hone my skills. I am that much more confident about my knowledge moving forward, and it makes me even more excited to begin not simply a job where I write code, but a career as a software engineer.