||We get a few stories posted back here of what it's like to apply at Microsoft or Google or something. I thought perhaps I'd describe what it's like being on the other side of the table at a smaller business.
We just got through hiring a couple programmers for junior level development positions. While the resumes came in a little slower than in previous hiring runs (it's a strong job market here), we got a good mix of people and a lot of resumes that looked strong. We got people with CS degrees, people with diplomas from technical schools, people with a fair bit of experience, new grads, referrals from current employees.
A big hint for this stage: make sure you know what the job is; then when you're asked what you want to do you can say things related to the job you're applying for. When you say you want to be doing "sales and management or something" in 5 years, it's hard to take you on as a junior developer. Being honest is great, but when you come to an interview for a coding position it's sort of catastrophic to say you don't like coding. It's hard to overstate how important this is.
Honestly, if you came into an interview with us fresh out of high school with no experience but said "I like programming and I want to be a programmer and here is some things I programmed" you probably would have made it to the final group (and if you could program, you'd be hired).
Speaking of which: develop something that can be shown to someone. We typically ask people for sample code or something - and mostly we get back garbage. Rudimentary school projects. Web sites that are long dead (and now just a parked page at GoDaddy or something). Vague "I helped with this part of this website" things. Applications that can't be run (or comprehended) without a certain database set up. Your code sample doesn't have to be spectacular; it just needs to be something that compiles and runs and does something and actually has some code that can be looked at by a human (and preferably one without a thousand frameworks installed). Not all job interviews are going to ask for something like this - but for ones that do you have a real leg up if you have something demonstrable (even if it's a game or trivial utility - by the time you get this far it'll be a technical person looking at you, and we like games).
Last hint: know how to program (and this part is probably wasted here). For our final cut, we had people do a coding exercise. Now you may be thinking - ooh, this is the part I'm interested in. Well... you'll probably be disappointed by the following story.
Here's what I had people do: Given an array of 1000 integers (values from 0 to 99), return the one that is the most common. In the case of a tie, return the smallest tied number. Before the exercise started, I demonstrated this on paper and made sure people understood the problem by giving them some samples and making sure they picked out the right one. I had people sit at a computer and code up the solution (in VB.net/VS 2005) while I watched and helped.
Some people didn't know VB syntax at all. This was kind of disappointing, given that the position was clearly a VB.net position, and we made sure during the interviews that people were familiar with VB (or at least claimed to be). And the people knew they were coming it to do a coding exercise. Anyways, this wasn't a big issue - when I saw people struggling to declare an array, I just told them how to do it. I wasn't really trying to test people's VB knowledge; a new syntax is easy to pick up if you're a competent programmer. I'm just saying that if you are applying for a Java job, you should get some basics of Java sorted out. Makes a better impression.
I was much more concerned with the problems people had coming up with an appropriate algorithm. I'm not talking about an efficient algorithm or the best algorithm or a bug-free one or something - I'm talking about anything. We had allotted an hour for the exercise, and by the end of the hour many applicants (including some with CS degrees(!!) or years of experience) hadn't made a real stab at the problem - and this is with some verbose help from me. At about the 20 minute mark I would talk to them about the general plan of going through the numbers and counting how many of each number they encounter. If they were stuck again by the 45 minute mark, I'd go over the plan of looping through the array of counts and remembering the largest count that had been encountered. Very few people got to the point where we were worrying about resolving ties. Lots of people went out on tangents trying to use SQL or sorting or something. While I guess some of that could have worked, it didn't help anyone who tried it.
In the end, the coding exercise was decisive. We had a couple people who walked through it fairly easily and we hired them.
Anyways, I come out of this with some reservations about the educational system and a renewed respect for TopCoder competitors. Some people may think I'm exaggerating something in the above - but I suspect those involved at hiring for smaller companies will hear the ring of truth.
Anyways, hopefully you found something in that useful, encouraging, or at least entertaining.
EDITS: minor, for clarity.