Well, this story is another example that a good rating doesn't mean everything yet.
We had a short HR interview, then a tech interview with the backend lead and one newly hired developer which consisted of a simple talk about my background, my tech stack, my present work.
After that I was given a technical test: an API with several entities and a celery subsystem packaged as a docker image.
The description seemed reasonable at the first glance but whet I got to work it turned out not what it seemed.
First of all, the task scope.
It took me a 100+ hours to complete. Which is a lot for a test. Even if I wouldn't do the UI part it would be still about 30-40 hours for API, celery and tests (which is kind of weird even like that) -- not because of the complexity but because of the whole bunch of unnecessary things that were just a waste of time: they tell nothing about ones development and architecture skills. Will talk about that a bit later in more detail.
Secondly, the requirement reading "any functional frontend will do". If you are a dev you surely know the phrase "simply add this functionality", which indicates a set of assumptions made. Now, I faced a choice: one was to write a UI that won't use the API, which would be much faster and simpler, but then logically the question arose what sense did it make, if at all. The other option was to write a "simple" UI that does.. Which took me miles from the main coarse. E.g I as a backender do not need a UI at all to see how things work.
The third point were the nice-to-haves. There were a lot of them in the task, e.g adding markdown-based comments to records. To me, this looks like another example of loosing the focus: It's a module that only takes place and time and says merely nothing about the development skills. It's a plain stupid module with a many-to-one relation and no design decisions at all. Markdown is just a plain text field and there is usually no strict validation for it. Basically, it is handled by the UI side and a markdown lib. What's the point of putting this into the test? But in the context of "any functional frontend" this took a considerable amount of time.
The most disappointing part, however, was the company's response. After about 3 weeks of radio silence I got a message stating that "the requirements were not understood" (they are still not, to be honest), and "the whole project is convoluted and too hard to follow, also extremely tricky to set-up". In my view, this was an absolutely standard and simple docker deployment scheme. What exactly did you guys find "extremely tricky to set-up"? Running migrations? Collecting the static? Creating docker env files? I mean, come on, are you sure at all you've ever seen something tricky to setup in your life? :) What did the words "hard to follow" and "convoluted" mean remains a secret as well. Certain technical, structural or architectural flaws are easy to designate and describe , you don't usually need a "convoluted" for that.
So, all in all, the way the task was formulated, the amount of time required to accomplish the test, the long periods of radio silence and particularly the response do not contribute to the good image of the company's competence. On a higher level this might indicate a lack of task-setting skills (being able to determine what's important), a lack of management (being able to evaluate the load) or other professional skills. I'm not saying they do, you are the judges of it. But they well could.
Giving such a task (even for one month) doesn't look well in terms of respect for the people you are trying to hire. And even with this task it is still possible to keep things within the normal 8-15 hours limit if you remove whistlers and blowers from it and focus on the important things. It's not the best image if you need 50-60 hours of work to evaluate someone's skills. And honestly, guys, any meaningless HR phrase like "we've opted for someone else" would do so much better than this. You just cannot imagine how bad such meaningless replies look to the outside world.
