Course projects are usually solo. A real job almost never is. Code review specifically — someone else reading and critiquing your code before it ships — happens constantly, and how a new junior handles it is one of the most closely watched signals on a team, often more closely watched than raw coding ability itself.
Code review is not personal criticism, whatever it might feel like the first few times. Its actual purpose is catching bugs before they reach real users, keeping a shared codebase consistent enough that anyone can work in any part of it, and spreading knowledge across a team rather than leaving it locked in one person's head. Comments on your code are about the code, not a judgment of you as a person or a developer.
How you react is watched closely
The single most damaging reaction to a review comment is visible defensiveness — arguing, getting quiet and sullen, or making the same mistake again to prove a point. This is watched far more closely than any individual coding mistake, because it directly predicts what working with you day to day will actually feel like.
As a junior you will likely review someone else's code at some point too, even early on. Be specific rather than vague, explain the reasoning behind a suggestion rather than issuing a bare correction, and separate genuine problems from matters of pure personal style — not every difference from how you'd have written it is actually wrong.
Communicate proactively when you're stuck, rather than silently struggling for hours before anyone else even knows there's a problem. Update the team on progress without being asked. Ask before making a large or unexpected change to something shared. None of this is about being unusually social — it is about making yourself easy to work alongside, which is a specific, learnable, practical skill in its own right, not a personality trait you either have or don't.