The big lesson here is to offer help earlier rather than later so that you have the time to do the things you feel you don't right now

"now I'd like to go back & do a 1:1 post-mortem "code review" kudos for following up, make sure he knows you're doing this as mentoring, not to tear him down but to build him up.

If you care about this person and their career, you'll need to mentor them in some way. Mentoring is more involved than just pointing out all the mistakes. One the most important roles of a mentor is to "model" skills to the mentee. This means sitting down together and doing a task "the right way": show him how you do things, how you frame the problem and evaluate solutions. Compare and contrast with less effective solutions. If you can have the mentee perform half/most the work as you coach, that's optimal.

WRT taking notes, some people (I'm one of them) can either take notes or pay attention to what's being said, not both.

I think you're asking the wrong question. Why was a developer fresh out of college tasked with a project like this with no support or supervision? Review your processes to avoid people being responsible for projects beyond their ability and increase collaboration to spot problems earlier.

Do it as a guided exercise; make it clear that this is not about judging him or his ability/worth, and that it's a learning experience (you can literally say that). Then ask him to look for ways in which he can improve the code - by simplifying, by DRYing it up, by finding abstractions - with some input from you (suggest what could be done, why certain things aren't ideal, when not to DRY up, when to persevere in refactoring/restructuring even though it seems like going backwards). You don't have to end up with the same kind of code you wrote; rather, help him have a few "aha!" moments.

I would make a very deliberate effort to tackle only 1, maybe two broad topics like those you listed. The most important should be first, and others can be done later. Too much change at once might overload him, or at least water down your effectiveness.

Sounds like this poor junior developer was set up to fail. Who gives someone fresh out of school so much responsibility? Maybe your boss is the one that needs to be “ripped apart”.

I suggest edit of title to a) remove inflammatory language and b) add detail into title

@aaaaasaysreinstateMonica Not sure if you were the one who edited the title of my question, but I feel the title doesn't represent the full gist of the question anymore. I do hear your point about removing the phrase "ripped apart", though. I have changed it back, but with more neutral language.

@FrankModica This company has a college hiring program with significant training the first few months. Most of the college hires are able to successfully handle this type of task independently by the time they are 6 months in. It also was not an overly complex task. Please do not jump to conclusions so fast.

Show them this question?

Traditionally the approach is to toughen their character by making fun of them, their intellect, and feel free to throw in other areas of their life. Softening the blow is beside the point. The best programmers, like Linus Torvalds and Richard Stallman have all done this. So obviously if you want your project to be as successful as Linux, git, and gcc, you know what to do... Oh, you can also sexually harrass them, that's an advanced technique ;-) Bonus points if you do that to a gender you aren't interested in, just for the artistry of it.

These issues should have been dealt with by frequent and regular code reviews throughout the project.

@c36 That’s fair but does it not sound like something went wrong at the management or even team level if it was allowed to get this far? Even senior level developers have their progress and code reviewed regularly to prevent issues popping up all at once near a deadline.

You could tell him that in more conservative countries code like that could result in public flogging or worse. Thankfully today we'll be doing a private code review in a modern democracy so the pain and embarrassment will be far less than it could be.

Maybe send him a email with a summary of the things that you talked about. I'm also a not so confident junior dev in my first job, and having something to go back and look at is quite helpful for me. You can also refer him back to it so you know have to repeat yourself. It will also give him more time to process the information and do more research after you have finished your talk.

Would you like us to rip your question apart? If no, then consider which words you choose to use.