Your mentee has reached the take home stage for a job they really want. They send you a link to their repository with a short message. Could you have a quick look before I submit it on Friday? Just tell me if anything is obviously wrong.
It feels like an easy favour. You know what good looks like, and an hour of your time could make the difference. Pause before you open the link.
Start with the instructions, not the code. Many companies now say exactly what help is allowed. Some welcome a friend's review, some ask candidates to confirm the work is entirely their own, and many have rules about AI tools. Ask your mentee to read you that part. If it says the work must be theirs alone, your review stops there, and you can tell them why. That is not you being strict. A take home that passes because of you sets them up for a job pitched at your level rather than theirs, and the first month will show it.
If outside feedback is allowed, keep your help at the level of questions rather than fixes. What would someone reading this for the first time want to know? Where would you add a test if you had one more hour? What happens with an empty file or a missing field? Let them find the answers. A reviewer will often ask about the code in the next interview, and they need to be able to explain every line as their own decision.
Point them at the parts candidates most often skip. A short README that says how to run it, what they chose not to do and why, and what they would do with more time. Interviewers frequently read that before the code, and it is the easiest place to show judgement.
Then help with the part nobody practises, which is talking about it. Ask them to walk you through the code for five minutes as if you were the interviewer, and interrupt with the questions a curious engineer would ask.
After they submit, offer a proper review of everything, as long as they like. Whatever the result, that is when your detailed opinion helps most, because by then it can only teach them.
– Asael Shinder
