My answer appears to fly in the face of the other answers so far. I think code reviews are a very valuable way to keep QA informed, and to understand what they are testing at a much lower level. Primarily for the same reason I think having code coverage results on manual and automated test passes are important, I think code reviews are also important.
It is not so much getting into the weeds with code reviews (although it can be as you become a more experienced developer), but more about pointing out differences at a high level in your understanding of acceptance criteria vs implementation, and also understanding how things work. You may find that 4 or 5 of your test scenarios are all handled under the hood by the same method in the code, which can help you determine if your tests are equivalent and even necessary. You may also find out that the way something was implemented was completely different than what you expected, and that can help direct your testing efforts to the right areas. You also get a chance to communicate with the developer directly and ask questions about risky areas, or discover code complexity that could lead to heavier testing of certain features.
In addition, there are plenty of things you can point out even with a very novice understanding of code, such as missing comments, extremely large functions that may need to be broken down into smaller digestible pieces, or duplicated or copied code that could be consolidated. You also may find that additional features or special handling of certain scenarios were added that were not outlined in the acceptance criteria and can then ask whether those things are acceptable.
Even without having a formal code review process for QA engineers, I have found it helpful to monitor check-ins just so I can keep up on what is being done, which can vary dramatically from what is actually spec'd out or part of user stories. It is amazing how often I find that developers have re-factored or modified something completely outside of the scope of changes for an iteration that I would have had no idea about except that I watch their check-ins. Sometimes, those re-factors have had defects. This is one way that many defects slip through to production without even being considered as a risk.
Finally, especially if a QA engineer is writing automation or other tools, code reviews of code from more senior developers is a great way to learn new things and increase your own understanding. I have re-used many many things in my own code over the years that I have discovered through code reviews of other's code.