Revisiting your job pre-interview tasks is good for you

I have a somewhat weird tradition if it can be called like that - I’m revisiting job pre-interview tasks after a certain amount of time I’ve spent working in the company that gave the task. It’s an interesting thing to do, and I think more people should do it on a more regular basis. Let me try to convince you why.

I got my first job as a programmer almost ten years ago, and I still remember my first-ever pre-interview task. The task was, given a data sheet write a small program that will start the watchdog timer, and check if it counts in the right direction, e.g towards zero. There was a small emulator I could use to test things, and basically, it was a task to find needed registers in the data sheet, write some specific values to them and see the results. The thing is, even a such simple¹ task can be written in a lot of different ways.

For example, the timer device is represented as an address in the memory, and you can simply calculate register addresses by a known offset. Writing some #define directives for each register is the one approach. Another approach would be to write a timer as a struct and define registers as fields of a specific size, allowing the compiler to calculate offsets for you, and providing a more object-like interface. Or, you can just write everything without any defines or structures completely contained in the main function without any kind of error handling, like I did the first time.

I wasn’t familiar with bare-metal programming, it was my first-ever job, so I did my best to get it to work at the very least. And I consider myself very lucky that this solution was accepted, and I am forever grateful that I was allowed to work there, and to all the wonderful people I met there, who taught me a lot. This really kick-started my love for programming, and what made me where I am today. If you’re reading this, thank you.

So, after some years but during the time I still worked there, I found this timer task lying in my documents, and thought to myself that the code is so horrible, that I would never hire someone who could produce such an abomination. At first, I was so disgusted with my own code that I thought that I’d just delete it and forget what I saw. But then, later that day I calmed down and decided that I can’t go home without rewriting it. I rewrote the code and went home with a lot of satisfaction because I literally saw all of my past mistakes, and applied all of my knowledge during the rewrite, producing clean and robust code.

So I’ve started doing it with all my pre-interview tasks from that moment on. And I suggest you to do the same.

However, recently I’ve expanded the idea a bit. The last task was done in Clojure, and I wanted to try out new things I had no chance of using at work before. So I sat down and picked a few libraries I thought were interesting to try and re-implemented the task from scratch under the same time constraints I had when I applied to the job. This also brought up interesting emotions, because I know myself - I can tell for sure that back then, when I first wrote code for this pre-interview task, I couldn’t do the same thing, especially with unfamiliar tech. But now I can, and it feels great.

Today, I occasionally have to review this kind of tasks from candidates. And every time I see some strange decisions, weird solutions, or silly mistakes, I remember my first iterations for such tasks and think to myself that this is fine, what matters the most is the people’s will to grow and learn.

So, never stop learning, and try to reflect more often on how you’ve grown in the last few years!