A combination of anxiety and nervousness followed by a sense that you might not have any idea what code is once the whole thing is said and done. At least from my personal experience in the past. And while it has been a good long while since I've last sat on the programmer side of a code review, the haunting memories still live on.
Having said that, however, every company is different. Some companies don't even perform code reviews at all. In fact, in my personal work history, only 2 companies actually dedicated the time each week to review my code (and every junior developers code) for issues. And that's because time is money, and unless you're working for a very large organization with 100's of developers, you probably won't need to show your work to anyone that often.
Here's a rundown on what to expect if you are on the receiving end however.
Prepare to answer questions
One of the biggest benefits of having code reviews is in the fact that more senior developers who have been there and have done that can assist the younger developers in how they write code. For that reason, you will probably be asked to explain why you made certain choices in your code.
And if you're anything like me, your typical answer will be something along the lines of "um..I'm not really sure". Fair enough, as often times I have no idea why I write code the way that I do. But if you really give it some thought, the real answer might be something like:
"I saw it online and copy/pasted it"
"The code was already there and I just tweaked it"
"It's how my teacher taught it to me"
You get the idea. There's probably a real answer to why you made those choices. And that's kind of what a senior developer wants to hear. At the end of the day, you're not really there to get praise on your work. And most senior developers performing these reviews will ensure that you walk away with at least one tidbit of information.
That tidbit of knowledge might be simply that your teacher probably didn't work much in corporate, and that you shouldn't follow their teachings 1 to 1. Or it might just be to stop randomly copy/pasting from the internet. In either case, there's something that can be done.
Prepare to change your code
Production code is still production code, and that means that it needs to be up to par in order for it to go live. If you're working on your own projects at home, there's definitely alot more room for varied quality. But if you're working for a multi-million dollar website that has teams of people working on it, quality is king.
And that probably means that you should be taking notes during your assessment as you will need to go back and adjust accordingly.
Often times, this can be challenging as the changes required might not be the most straightforward to you at your current skillset. I can still recall early on in my career hearing about various design patterns and why changing to those might be the most beneficial, only to have to go back to my cubicle to Google what that pattern meant.
But this is really how you get better at anything in life. You evaluate, you find issues and you course correct. Each subsequent code review after should be smoother and less tense than the one before it. At least ideally. I've personally also sat in group code reviews where the same person made the same mistakes time and time again, and those people tend to stand out. But usually not for the right reasons.
Prepare to learn from others
Code reviews at my old company were typically done in a group setting in which all the younger developers would crowd into a conference room once a week in order to get all their work evaluated at once by 1-2 senior developers.
Each persons commits (at least 1) would be put up on the screen and broken down line by line. And overall, this is a great way to see how others are solving problems and how they are also improving their work. You're typically just one small part of a larger system when you work for a big corporate entity and it can become pretty easy to forget that often times. Especially when you're up next on the screen and all of sudden JavaScript all sounds like gibberish.
So take notes and pay close attention because the learning never really does seem to slow down or stop in life. There's a good chance that you'll find yourself working with another developer who's code seems light years ahead of yours and who's reviews are flawless. It's good to know who those people are at a company and to learn from them as much as possible.
Prepare to ask questions
It's pretty nerve racking being up center stage in anything in life. But code reviews are a part of the job and you're on the clock so it's best to make the most out of them. Prepare and bring questions to the table because I can assure you that most people won't. They'll just sit there patiently waiting for their turn to end.
This is a good time to ask if your code is overall pretty good, or is it hopeless. Or probably somewhere in the middle. It's also good to ask senior developers how they would approach certain problems, because I can assure you, senior developers do like talking about their code. Alot.
Often times, junior/intern developers at a company don't interact too frequently with the senior folks, outside of actual working tasks and meetings. And fair enough, as deadlines are always looming and production code is always broken.
The code review is a kind of break for everyone involved really. A time to stop everything going on around you and to just focus on what the code is doing and how it's doing it.
Much of my corporate learning early on was based on shadowing senior developers for weeks at a time and getting to ask them exactly why they coded things the way that they did.
Prepare to feel bad about your code
And lastly, prepare to walk back to your cubicle feeling like a career change is in order. Except it might be good to take a look around at all of the other developers walking out with you with the same expressions. In the beginning of my career, the sense that my code was perfect was prevalent. Up until I had a code review or two. And then reality set in that there was alot that I still didn't know and that there were people who could do what I did in a fraction of the time.
20 years later, I don't feel like my code is ever perfect. In fact, I'm constantly changing it because it isn't. There is always something that can be done to improve the quality. Whether in terms of performance or readability or reusability, there is something that needs work.