Code assessment: they also didn't give a lot of details or expected architecture design, the task description was unclear. It was difficult to understand what exactly they want, it contained some confusing details. They did not provide the task with test data to avoid any ambiguity.
I showed the task to two different experienced developers and they both suggested different explanations about what exactly should be done.
When I asked the recruiter, who can explain me some unclear details, she said something like "task had all the necessary explanation to implement the solution. If you are unsure about things, it is better to make a guess and get prepared to defend your choice during the tech interview".
Okay, I chose a solution. But, actually, I did not have a chance to defend my choise!
Also, the feedback contained next (pretty ridiculous) comments.
For example:
1) "You should not implement the integration test for database". Wait. But how should I develop JPA repository without that? How to check whether data base was configured correctly, mr. Reviewer? Did you ever hear about TDD?
How to understand whether the database doesn't work or whole Spring context is down?
If you spent so much time debugging code as much as I did, you would know why you need special test for repository layer.
2) "Test names are not enough meaningful." Seriously? You want perfection in everything but you even could not provide a good example data and clear task description.
3) "Your service should implement an interface while your controller didn’t have to". Actually, I would need to use interface if I provided several implementations for my component. No more for anything. And, actually, I will not. Later they comment it that "creating an interface to a service is actually a part of the SOLID principles". But, unfortunately, they couldn't explain me which exactly SOLID principle I broke (because I did not broke anything and SOLID is not about interfaces and services at all).
4) "Consider having more specific test cases instead of a big method like ..." Actually, 27 lines is a not big test scenario. And if I split this test, I would get unpredictable behavior of the test environment. Because different test environments could change the order of running tests. And whole test scenario would be broken.
By default, JUnit 4 runs tests using a deterministic, but unpredictable order.
But you did not know that, mr. Reviewer, am I right? You could ask me.
I sum up: you must be able to read their thoughts and guess what they really meant to pass their interviews and assignments.
They do not make objective assessment of your knowledge, their approach is very superficial.
At least in the first two stages.
Yes, I agree that my solution contained some issues related code standards, but their test assignment was not perfect too. And it's strange to expect candidates to know your code standards, especially if you do not tell him where to read it.
It's hard for me to imagine their ideal candidate.
But they were friendly enough and cheered me up with their feedback, thank them for it.
