Sean Hickey

I have not looked at your code but I can say with some experience that it has nothing to do with how you wrote it. There is no way for me to confirm but most likely this is what happens when you turn in a coding test. Someone who is perhaps at a debatable senior level looks at your code and often (I have seen this happening at places where I have worked) gives it to someone else for their feedback. The person your code gets handed over to is often not the person who will make hiring decision. He/she will look at your code and try to discover their own style in your code. If your code does not come close to the way they would have written it then it is bad code.

A lot of things come into play here. Often it is unclear expections. I have done coding tests where the requirement was to pull data from a dataset and cache it in memory. This requirement can be met in many ways. I chose the simplest one but the feedback I got was similar to what you got. It totally depends on where the reader of your code is in the evolutionary stage https://medium.com/@webseanhickey/the-evolution-of-a-software-engineer-db854689243

Reading code is harder than writing.

Maturity (or seniority) is a form of growth and it has stages. I would call this article Stage 2: Do the approved thing.

It's an important stage. But people who stay in this stage too long become intolerable technical architects who yammer away about best practices and high level company goals, produce technical documents no one reads and plan team building events no one wants to attend.

To me stage 3 involves thinking critically about tradeoffs. Applying best practices in relevant contexts and rejecting them in others is a good example.

I always end up linking this silly blog post. https://medium.com/@webseanhickey/the-evolution-of-a-software-engineer-db854689243 It sums up the seniority growth cycle better than I can in words.