I graduated in the heart of the recession and had lots of people telling me that I wouldn't find a job. But I viewed it as a numbers game, and refused to believe that if I didn't buckle down and dig, that I wouldn't find a job. As the other commenter said, I made it my full-time job to find a full-time job, and I did. I received my first offer after multiple interviews, and 84 customized application packets had been submitted. It was a ton of work. But within six months of graduation I was making $51,000 and working as a Credit Risk Analyst at a large bank. The work sucked, but the lesson stuck. Don't let any kind of bad economy be an excuse. If you're landing interviews, you're doing something right, but if you're not getting the job, you're doing something wrong. The thing to recognize is that the technical stuff is only half the equation--if that. Much of the time what they're looking for at least as much is "fit" and an analytic mindset which demonstrates an aptitude for solving problems. They're looking to see how you handle it when you don't know the answer. How do you think your way through it? Or do you just give up? Or do you make stuff up?

Most importantly, there are ALWAYS jobs out there. So get out there and make it happen. Go to Meetup groups, network, and be as intelligent about your job hunt as you will be on the job.

Basically, there is no excuse for your lack of success in getting the job you want. If you need more technical chops, figure out what you need to know and learn it. Make some projects on your own time, build a Github repository. And eventually all these things will combine to get you the job you want. There's a ton of demand out there, you just have to find it.

I would say start looking for contract gigs. The interview process tends to be quicker and dirtier. Can you do a,b,c? Have you used tools a.b.c that we use? How fast can you get up and running on our project?

Since most contracts are 3-6 month gigs, these companies need to hire someone fast and get a butt in the seat and start building what they need. It's also a sort of trial on both of your parts. You want to see if you like working there and the stuff they have you doing, and the company will see if what you're doing is good and you interact with the project managers well and hit their deadlines.

I've had 3 month contracts go on for years, others you might want to just get out as soon as the projects done - which I've also had. Either way, you get some really valuable time in doing what you want - which is to program. It also gives you some decent references you can use to leverage to get a full-time gig somewhere. The weight of a good recommendation can never be underestimated.

Also, the only way to get better at interviewing is to keep interviewing. If you have a recruiter, always ask them what to expect. Do I need to dust off my edition of "Pro Javascript Design Patterns" or can I go in cold knowing that the questions will be limited to tools and experience? Is the company looking for a hardcore MVC Spring guy, or do they just need someone who knows Struts? Just knowing what to expect in the interview is half the battle.

Here's a couple of possibilities, put some time into all of them, but gravitate towards the activities that you enjoy/tolerate the most.

* Take some time to learn how to interview. Learn the logic puzzles, how to chit chat about linked lists and binary trees. Learn how to white board, how to handle the 30ish standard programming questions in short time on a white board. Typically, if you're looking for a high-level language job (Ruby and Javascript in my experience), a lot of the time people will ask you to solve low level problems ignoring the abstractions such languages provide, so learn how to write C++ solutions in Python. Reading books like Cracking The Interview Code will get you most of the way through this, but I'd also advise to read up on internet fundamentals (http, etc.)

* Apply to a bunch of places. Embrace being repeatedly told that you don't seem good enough for the people you want to associate with, for a variety of unfair seeming reasons. Look forward to the day when that feeling is transformed to a dull sense of belonging based on your economic utility.

* Put yourself into experiences that come closer to typical software work experience. Work with other people, work under a time pressure, work to meet existing customer needs, work for payment. You could try hackathons, freelance work, contributing to open source, working with other people on their projects.

* Meet more developers. Ask for their opinions on how to best develop themselves, inside scoop on jobs available, etc.

* If possible, broaden your search beyond a single city. I'm assuming you're in SF. SF may have a lot of software jobs, but it has a lot of developers too, and the fact that they have to pay people a large enough salary to offset the costs of living there make it a bit more competitive than somewhere without absurdly high costs of living.

Programming interviewing process can be hacked, and a quick Amazon search uncovers a bunch of titles doing just that.

I can tell you what the bias might be - people with other backgrounds might treat software engineering and programming as equals, and thus have very vague idea of things like system reliability, scalability, failover tactics, deployments, etc., jumping at the quickest dirtiest obvious solution. Steer the conversation in a way where people become cognizant of your knowledge of application architecture and system-level design.

> I can tell you what the bias might be - people with other backgrounds might treat software engineering and programming as equals, and thus have very vague idea of things like system reliability, scalability, failover tactics, deployments, etc., jumping at the quickest dirtiest obvious solution. Steer the conversation in a way where people become cognizant of your knowledge of application architecture and system-level design.

Is that really true? If anything in my experience it's most programmers who look at jumping at the quickest dirtiest obvious solution. We have to fight as sysadmins to get them to do things right. But that's just my experience where I work. Things could certainly be very different at a tech company or something.

I am the programmer / software engineer arguing to not do the quickest dirtiest obvious solution that my management suggest.I dislike having to debug something I wrote a few weeks ago (once I have forgotten the details), so I try to get stuff working as reliably as possible.

Make getting a job your full-time job. Full on, no dabbling. Persistently.