Initial chat with a member of the talent team was pretty positive. He was very clear and transparent about everything so credit to him. Pleasant to talk with. However, the engineers who reviewed my take home task have let the company down, in my opinion, because their comments were more like excuses to let somebody down rather than fact based feedbacks. The test was a very basic CRUD RESTful API where you had to consume a third part API and display the response. Just a junior level question, nothing special. Their excuses to fail me are listed below. 1. "Running docker compose up command didn't automatically run the tests" - What can I say! 2. "Integration tests in the main package" - I've put small piece of code for them to just run and see the output, just for their convenience. They were not tests. I think even an intern would know what is code and what is test by just looking at it but interestingly these guys didn't work that out! On top of that, the main package is not meant to be tested because it shouldn't contain business logic, hence the reason. 3. "Do not use the Golang testing package" - I have no clue what this is supposed to mean to be fair! 4. "Not enough coverage for failure scenarios" - How do you describe "not enough"? Explain that in the requirements so that we know what are dealing with here! Less than n% coverage doesn't automatically qualify you to fail someone. 5. "Integration tests are not independent and not repeatable" - Well, is there a rule for this, no! Go visit official Golang documentation and see how they do. You will be surprised! These were the excuses. If you have noticed, there isn't a single comment about the actual implementation so yes the code was perfect! Just not the tests!!! These are the bad things in their code: 1. A production grade RESTful API always have "idempotency" feature enabled but these guys don't have it. Amazingly, they are dealing with money! Not a single POST endpoint realises this at all! 2. If a client send a malformed JSON request, their API panics and returns 500! It is the client who sends a "bad/malformed request" so it should be 400 and not panic the app. You will see panic stacktrace in the docker logs! 3. The 400 response with error list is a flat string cramped up together so you have to parse it to get a list of errors. A normal API would return a well structured error list, just like the official JSON API specifications describes. Given that they failed me purely because of the tests, not because of the code at all, I wonder how bad their own tests are after seeing their dodgy implementations as listed above! I feel like I dodged it to be honest but come on, don't waste peoples' time with such cheap reasons/excuses. Please be realistic with your comments/reasons. I interview/test engineers myself but never treat anyone like you did here. It is unprofessional and unfair. You can be better than that! Anyway, I wish you all best of luck as a company.