Aside from writing good clean code, what are some processes or topics that I should be competent at before trying to join a team?
I'm assuming you have some projects at home since you're self taught. Whenever you find yourself manually checking something works on these projects, consider writing a test. If your compiler/build system doesn't have a test framework built in, you could just write a little command line program that prints pass/fail at the end. Test frameworks are easy to learn later. The skill to develop here is knowing how to write testable code--i.e. if you can't test something without running half your code base, figure out how to decouple the thing you want to test from everything else.
Companies all have their own quirky processes for things like code review, and very few are actually following best practices, so for this you'll learn how to do things when you get there.
More important than anything I've written above though, is have some experience reading other people's code. Writing code does not necessarily make you good at reading it. I'm self taught, and I used to have a pattern of downloading an open source library I wanted to use, trying to do something in it that went past the basic examples, and then giving up because the documentation was awful. When you work for a company, you're usually surrounded by code you didn't write that has little to no documentation, so you're gonna have to learn how to read code to answer your questions in order to be effective. If you don't know how to practice this, consider downloading a little open source game you like, and try making simple changes to it. Navigating a big code base you didn't write is pretty overwhelming at first, but it's an important skill to develop.
That said, the best medicine is practice.
To practice unit tests (or TDD when you feel like you're ready), do some katas. There are plenty of popular ones, and sites like http://www.codewars.com/ offer great challenges.
As you're working through your katas, make sure you check in to source control as you go. Learn the basics well, and pick up the rest as you go. You can always Google the more advanced stuff if you need it (most of the time, the basics are all you'll need).
For code reviews, read code. Read your own, certainly, but also read others. Hit up github. Find a repo you like, and then hit the 'commits' button. Read through the list of changes, and then write down what you think.
In real life, code reviews will be a little more tricky. You'll have to navigate a social structure and determine what is and isn't okay to say in a code review. Some groups are ruthless. Some are academic. Most, however, will be regular developers who are proud of their work, and the ability to criticize constructively will be of great value.
Two other suggestion come to mind for new team members. The first - be an apprentice first. Ask questions and learn. Especially in the beginning, your #1 job is to understand your environment - the people, processes, patterns, and practices that compose the overall work.
The second, take a shower. Nobody likes smelly teammates.
Watch The Office (UK) -- this is for some people uncomfortably close to their real work environment. Office Space -- ditto.
Better off Ted, Corporate, and Silicon Valley are somewhat more light-hearted, but there's a bunch of truth in them.
If you can stomach Dilbert there's a bunch of early Dilbert cartoons that do a good job of describing culture.
But good luck! I hope you enjoy it!