I just applied for a staff level position at a large company and for the first time in my career failed a coding challenge. The feedback given was absolutely baffling and just goes to show it's really a crapshoot applying at these larger companies. If you get someone reviewing your code who clearly doesn't want to be there, doesn't know the language, and is too lazy to learn the absolute basics, then you're screwed. I've held numerous Head of Engineering and CTO roles, as well as several team lead roles prior to this. This is the same coding challenge that is given for junior roles, and is not leetcode. I'm just staring at the written response in disbelief. There's no path forward from here, bad luck, move on:

> Thank you for your submission. Your README was clear and concise, and included instructions on how to run the tests along with your assumptions and design decisions. You were able to analyse the requirements to produce a working solution, however the design was confusing, with components that interacted with each other in strange ways.

> There was a lack of test coverage on a domain model level. At a technical design level, the interface was not clear and confusing. This was due to not knowing where the main entry point for the provided solution was.

> We liked that you included an integration test for the scenario outlined in the exercise, however, we also found gaps in the testing, for example depositing or withdrawing with non-existent accounts.

I can't reveal the company or coding challenge details without giving away too much information. But needless to say the coding challenge specifically states not to implement a CLI or user interface of any kind. So when the reviewer couldn't find the entry point, what they really meant was they weren't familiar with JUnit! They also didn't take the time to fully read the "clear and concise" README which stated:

> We're building a JVM library, and executing some tests. There's no application and therefore no explicitly defined main entry point — just the tests.

There was of course also the precise CLI command (`./gradlew test`) required to execute the tests, a short explanation of the build system and why it was chosen. Additionally included was an explanation of how to run and debug the tests in an IDE. Plus all the standard stuff like documentation for the domain model and functional behavior of the APIs.

The feedback about "depositing or withdrawing with non-existent accounts" also makes no sense and demonstrate the reviewer is totally unfamiliar with Kotlin. There's no input (no CLI or GUI), so there's no way to provide a "non-existent" account. The APIs are strongly typed and non-nullable. (There's also explicitly no account deletion or multi-threading to worry about).

Sigh!

Don't get me wrong. I'm sure the code was far from perfect. I don't believe in such a thing and LOVE learning new things in code reviews. But my gosh, this is a company that has a truly brilliant Kotlin engineering department at their disposal. Unfortunately, with organizations of this size, all it takes is some part of your application to randomly land in the hands of the wrong person and it's game over.