I would like to emphasize, that these kind of assessments only take a snapshot of your current development and problem-solving skills. A more valid approach also requires to monitor how your skills improve over time.
In the long run you want to hire someone who is good in self-improvement of skills and adapting to changes. Ans maybe this person has just not build the skills yet.
Failing this limited small puzzle makes me think in the end:
a) I just not solved it yet but in the future I would be able to do so
b) This would not be the place where I like to work at because the only thing they care is my current performance and not the performance I could deliver after x time-units of further improvement.
Hope this is not perceived as rude but rather a critical approach on code assessments we all should be aware of (and communicate in job interviews, too).
Still much thanks for sharing the test, it was fun to solve it <3
not even a snapshot of your current skills but those that you can think of immediately under pressure. Any company that wants someone who can solve puzzles is a bad company, I want to work somewhere where real engineering solutions to problems are considered, analysed and thoughfully developed. Not stupid puzzles.
I see the biggest conflict in long term creating quality software vs. short term KPI, where one qualitative measure is compared with a quantitative measure.
And HR, as well as MGMT, are totally in love with quantitative measures, which is why (I assume) they still do these coding or fact-based-recall-skills assessments.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.