I have put myself forward to review a technical task. I am going to just write notes, not be harsh.
But what if I see a nice to have, do I raise it directly. Example the app isn't very accessible, despite this not being such a concern in the scope of what we do (I still push for it), no keyboard usage to me is a tell about UX consideration and my test was accessable. But then again it's not a criteria.
I think I will just stick to the scope, that's fair isn't it?
Have you ever done this before, let me know in the comments what your approach was. What do you care about, and does it even matter what we care about?
Top comments (3)
If you can, categorize your comments. Write "core scope" and "nice to have" sections. Keep it factual, not emotional or opinionated. For accessibility, maybe reference standards. Worst case, they ignore the section.
If you have a deadline, focus on the core scope first, then document nice to haves within the remaining time.
Excellent pointers, I have taken issue with something said in the CV that is not reflected in the technical test and it is not actually critical but it makes me worry. Should I shrug it off, after all the time to do this task is short and meant to be incomplete. Overall the candidate has not used X framework before and prefers Y but has done well, that is enough and we could teach him the rest. However the position is higher than my own, feel as if I should give developer a chance to talk it through.
I think hearing their logic will help you. I can't imagine anyone you'd want to work with getting annoyed by that. It might allow you to feel more confident about their skills.