That Mediocre quip caught my attention. Like, "who would really call themselves mediocre that can actually code?" so I read on with interest. I read through the entire commit history and I read through the full story in the comments. I've also hired with "take home assignments" So....
First, the project is unrealistic for under 5 hours for sure for most developers. For whatever it's worth, probably about three hours for me and if it were a Ruby on Rails task instead of Django.
But I fully recognize that the only way to do this project in under 5 hours is because you're already pretty darn good at all areas it called for from Docker to Django. If you do not happen to be in that camp, this will be a challenging project from time-perspective. But I can also say this is a company that knows what they want to hire and they know what they don't want to have to train the new hires on.
First mistake here, is if you already thought this task was well more than their estimated time to do, then you have to think a) opportunity to grow and learn from this interviewing process or b) move on to put energy into other job opportunities that really could use your energy and focus and likely to lead to positive outcome. I suspect the ultra-casual commentary to the CTO was also a bit off-putting to this firm. So at least use proper English in your initial communications and relax to casualness after the hiring event. Aside from that, I'd say this company at least is clearly aware of what they're looking to hire. They are very obviously (to me) seeking the top 1% of developers and that's "Ok". They'll of course pay for it, but that's not our problem! We must seek right-fit for us as much as they do.
The feedback the code reviewer provided was on point and yes, it's the kind of feedback you could expect in a code review if you were employed there. So you have to ask yourself if you can handle that kind of critique and rise to the occasion. In this case, if I were on the receiving end and I recognized many more hours to complete the requested changes, I would likely have written back and added ETA on every line item and tell them, "I can only do 2 more hours on this project, here's my estimates for each. Which would you like to see me do?" You'll earn respect for pushing back, for providing clear estimate and demonstrate you can negotiate and discuss expectations rather than just accept the work/tasks being pushed down in your direction.
Besides, here's also the opportunity for you to have real interaction to learn about this team more in-depth and decide for yourself if this is the team you want to work for. It's probably uncommon for most job seekers to push back in an interviewing process, but I actually valued those that did more than those that never spoke up and just did the tasks assigned. Sometimes tasks are ill-defined and added in purposely to find out how you communicate to clarify issues. When you don't reach out for clarification and just assume, it becomes another clear signal of who you are as a developer to the hiring managers.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That Mediocre quip caught my attention. Like, "who would really call themselves mediocre that can actually code?" so I read on with interest. I read through the entire commit history and I read through the full story in the comments. I've also hired with "take home assignments" So....
First, the project is unrealistic for under 5 hours for sure for most developers. For whatever it's worth, probably about three hours for me and if it were a Ruby on Rails task instead of Django.
But I fully recognize that the only way to do this project in under 5 hours is because you're already pretty darn good at all areas it called for from Docker to Django. If you do not happen to be in that camp, this will be a challenging project from time-perspective. But I can also say this is a company that knows what they want to hire and they know what they don't want to have to train the new hires on.
First mistake here, is if you already thought this task was well more than their estimated time to do, then you have to think a) opportunity to grow and learn from this interviewing process or b) move on to put energy into other job opportunities that really could use your energy and focus and likely to lead to positive outcome. I suspect the ultra-casual commentary to the CTO was also a bit off-putting to this firm. So at least use proper English in your initial communications and relax to casualness after the hiring event. Aside from that, I'd say this company at least is clearly aware of what they're looking to hire. They are very obviously (to me) seeking the top 1% of developers and that's "Ok". They'll of course pay for it, but that's not our problem! We must seek right-fit for us as much as they do.
The feedback the code reviewer provided was on point and yes, it's the kind of feedback you could expect in a code review if you were employed there. So you have to ask yourself if you can handle that kind of critique and rise to the occasion. In this case, if I were on the receiving end and I recognized many more hours to complete the requested changes, I would likely have written back and added ETA on every line item and tell them, "I can only do 2 more hours on this project, here's my estimates for each. Which would you like to see me do?" You'll earn respect for pushing back, for providing clear estimate and demonstrate you can negotiate and discuss expectations rather than just accept the work/tasks being pushed down in your direction.
Besides, here's also the opportunity for you to have real interaction to learn about this team more in-depth and decide for yourself if this is the team you want to work for. It's probably uncommon for most job seekers to push back in an interviewing process, but I actually valued those that did more than those that never spoke up and just did the tasks assigned. Sometimes tasks are ill-defined and added in purposely to find out how you communicate to clarify issues. When you don't reach out for clarification and just assume, it becomes another clear signal of who you are as a developer to the hiring managers.