This answer should be seen as a supplement to Bruce's answer. I wanted to add a few more notes that wouldn't fit well in a comment.
A lot of the tools you already might use for unit testing will likely be useful - NUnit, mocking frameworks, etc.
Books to read: "How we Test Software at Microsoft", "Beautiful Testing", "Lessons Learned in Software Testing", and if you are interested in working with Agile methods, you should also grab "Agile Testing", and maybe even start with that book. I'm not recommending any newbie books for you because I think you already know the basics. Any gaps will probably get filled in while reading the list above.
You should practice manual exploratory testing. This is the most useful skill that you won't already have as a developer. Getting good at manual exploratory testing will make you a better automation tester as well, and I fervently believe it is a skill no tester should be without.
When you are being interviewed, you will generally be asked some form of, "How would you test this?" This will probably be your key interview question. The interviewer is looking for an organized approach. You want to be able to divide the test coverage you need into neat categories, describe a general approach for each (e.g., manual testing; fuzzing; automated regression tests), and then probably pick one group and start writing specific test cases for it.
E.g.: "Well, key things for this product will be functionality, security, usability, and reliability . . ." and so forth. Then you pick a category and go in depth: "Functionality should check the API and the UI, so I'll want some automated tests using fixtures to test the API. For now, we should just test the UI manually . . ." and so forth. Then come back and talk about, say, functionality some more, this time laying out specific test cases, e.g., "Let's start with a 'happy path' test case . . . here are some equivelence class tests we should do. . . some boundary tests . . . some error tests . . . now let's discuss UI manual testing a bit more . . . " etc.
If you are doing this right, your interviewer will have to stop you from listing out ideas for tests, even for a very simple application. This is the tester equivelent of being asked how you would implement [insert well-known software application here]. Just as you couldn't complete your code spec for a software application during the interview, you can't draft your entire test plan during the interview either.