Lessons from a take home exercise

The software industry has many opinions on the take home exercise during an interview process. Personally, I have never had a problem with them and have come to actually prefer the experience. I like to see it as a opportunity to learn new technology, showcase my knowledge in specific areas, and otherwise build with some realistic pressure which you don’t have when building simple side projects.

Recently I was given a take home exercise which I found particularly fun. Without giving away the company, because I’m pretty sure there was some kind of privacy clause somewhere, I can describe the kind of skills it tested and the mistakes I made along the way.

Now first, I need to say, I didn’t actually finish the exercise because I was much too busy helping my wife run her business. In some ways, this is a shame because I had a lot of fun with the exercise and they were eager to see it, but I had also chosen some technologies I wasn’t familiar with and this cause me to spend too much time learning and now enough time shipping.

The exercise itself was a frontend application since that has been the majority of my professional experience. It was clear from the requirements that they were reviewing my ability to create dynamic forms. It was requested that my submission be built with React and, luckily for me, I am an expert with React (or so I like to think).

I chose what I thought were appropriate libraries for the dynamic forms requirements (react-hook-form, zod) but where I made the mistake was choosing redux-toolkit. As well as the new react-router (which takes a lot from Remix). Now, at the start, this didn’t look like a mistake. I have years of experience working with redux and felt very comfortable with it’s syntax and API. The problem was that I had chosen it not out of necessity for the project, but because I remember it being mentioned on the job description.

Once I had integrated redux-toolkit and built out the dynamic form, it was clear that I had some conflicting co-location of business logic. The form itself had some fields which needed to be controlled (by react-hook-form) for dynamic validation, but also needed to update the global redux store because that’s where I built in the mock REST api. I also built the form to handle an “edit” flow (this is common). Simply out of habit, I had grown used to fetching within the component itself (think react-query) and providing the fetched data to the form (ex: if a query param is present, etc). This soon made me realize I had coded myself into a strange corner which I would have to explain later to the interviewers.

This realization is which ultimately lead me to throw in the towel. The exercise itself wasn’t difficult at all, and something I was quite familiar with through my years of building with react. It was choosing a global state manager while I had become so accustomed to using a react-query and it’s caching strategy to emulate global state. Needless to say, I withdrew my application mainly because I had too much responsibility to my wife’s business and wouldn’t have the time to correct my own mistakes.

A lesson out of this experience has been something around “beware over-engineering when experimenting with unknown tech”. I have experience designing and building greenfield applications (which I should have embraced) but I let me curiosity get the best of me. I was curious about the new react-router. I was curious about how redux-toolkit has changed over the years (I hadn’t used in a few years at this point). I was also curious how I might integrate shadcn to this project, another tool I hadn’t used in a professional sense. All these curiosities added up to time. Time I did’t have, and ultimately, wouldn’t have if I needed to continue helping my wife’s business.

Luckily now I have the time to pursue a full time job as my responsibilities for my wife’s business are slowing down. I have had some other take home exercises to reflect on, which I might write about in future blogs. I’m not sure yet.