I wouldn't deliver a scathing code review even though it would probably make you feel better, at least for a little bit. Instead, I'd approach the person and s

I wouldn't deliver a scathing code review even though it would probably make you feel better, at least for a little bit. Instead, I'd approach the person and see if they misunderstood the task, were overwhelmed etc. Approach it from a teachable moment first, if a pattern of behavior and bad code continues then address it with increasingly direct feedback. I state this because I have done the opposite and it can backfire in ways you don't initially think. So I have learned it is always best to start of with an inquisitive mind on why he/she wrote it this way and what were their instructions and then use it as a teaching moment to help them be better. I have seen companies where people got rewarded for the most convoluted stupid ass code you can imagine, generally in larger enterprises. As an example, I all but stopped hiring financial services programmers in the late 90's early 2000's in my area because we found we had to get them out of so many bad habits. Not saying all were bad, but our screening of someone anytime I saw financial services (especially big banks) on their resume as a developer was quite a bit tougher. Its not quite the same today, but I still know teams that I wouldn't hire from without really screening someone heavily. Also, I guess one other point. If this person was hired at a senior level vs a junior or mid level, I would still approach it the same but be more critical (and direct) why they would write code that increases the likelihood of defects.