1) The code is structured very differently than how I would have coded.
2) They used some syntax I never used before.
3) No comments.
4) Code is using concepts and techniques I never used before.
5) Magic numbers
Welcome to professional software engineering!
Seriously, if you need to work on a team, this is what most other people's code is going to look like. Ninety percent of code is crap, just like everything else (Sturgeon's law). And, if you're doing something like fixing bugs, or if you tend to redesign features or work on optimizations, there's probably more work to be done in the really poorly designed parts of the game, so you have to read a lot of bad code.
If you can only read well-structured code with concepts you have used before, you are bad at reading code. You can get arrogant about it and maybe even refuse to read badly designed code. Some engineers make a living out of carving their own little software niche and keeping the other engineers out of it. Or, you can try to practice like you're doing - I suggest reading lots of code posted on this forum, even if someone asks a completely unintelligible question about it. Honestly, gamedev.net is a great place to read a lot of really awful code.
If there's syntax you don't understand, or if somebody uses part of a standard library that you do not recognize, that's completely on you. If you've programmed over two years now, I have to ask, have you studied the Java language specification? Have you studied the java docs for the Java API? Part of knowing how to read code is practice. The other part is being very good at breaking down code into exactly what it does, instead of relying upon general pattern recognition. For that, you need to know the standards.
So, my feedback is, really learn all the details of Java. Know the specification, try to learn a majority of the class library - at least enough so that you know, if you come across something new, you've learned so much of the class library that it will be easy to learn more class in a very short amount of time. Maybe even take a peek into the virtual machine specs, once you run out of language details. I wouldn't expect you to retain 100% of all this learning, but after a certain point, you'll be able to go back and reference parts quickly when you don't remember something. Google is ok, but I prefer to be able to go straight to an official document.