I'll actually go one step further on that: make personal connections. Think about anyone you know reasonably well who is in the field. Use them as resources. I got my first programming job via a friend of mine; you may say "nepotism", but think about it this way: if you're gonna hire someone, would you rather have one of your employees vouch for them, or have to rely solely on the impression you've gotten by chatting for an hour or two?
I've recently found myself job-hunting again, for the first time in ten years. While I am indeed going on an interview today, after having been called by a recruiter when he saw my resumé on Dice, I have four strong leads - one of which is for my "dream job" - and all of those came by contacting people I know.
Things I can mention that have worked very well for me:
- Participate in open-source projects - even just at the bug-fixing level. If you search Google for my name in quotes (and prospective employers will!), nearly every hit on the first four pages is me, despite sharing a name with a NASCAR driver and a judge in a prominent civil-rights case. The majority of those hits are mailing list posts I have made.
- Go to trade shows, if you can possibly manage it. Some of them offer a reduced rate if you're paying your own way, and obviously some of them (i.e., LinuxTag) are quite affordable (possibly excepting travel!) If you have any idea what you would like to specialize in, this gives you the opportunity to meet the "people behind the code", which - let me tell you - is one of the strongest "ins" that you can hope for.
- Spend some wetware cycles on software design! I can't tell you how many people I've worked with who are sharp, smart coders... and can't write a clean API to save their life. Hiring managers really, really like this. My recommendation there is - at the risk of "drinking the cool-aid" - going and studying the Qt or KDE source code and design guidelines. Even if you're not intending to be a C++ programmer. I've not looked hard at KDE, but Qt is some of the cleanest code from the standpoint of API design and modularity that I've ever seen. (I'm not necessarily talking about the code inside a module - some of that is pretty grody, but that happens on a project that big.)
- Lastly, I suggest striking a balance between specialization and still being very flexible. As an example, I worked at Maxtor for many years. When things started getting ugly from the work-environment perspective, I kept talking about leaving. Most people - particularly, say, servo engineers - generally responded with, "Where are you gonna go? Seagate's not hiring." My response was, "Hey, I'm an applications programmer. I don't care what's at the other end of the cable - I don't even care if there is a cable!" Basically, the servo engineers got paid a fair bit more... but I have a much, much easier time finding a job - and have never been laid off, short of the company going under.