Slashdot Mirror
Getting Hired As an Entry-Level Programmer?
An anonymous reader writes "I received a state university degree in Computer Science. After graduation, I immediately took jobs in QA to pay the bills while waiting for other opportunities, which of course turned out to be as naive as it sounds. I've been working QA for several years now and my resume does not show the right kind of work experience for programming. On the whole I'm probably no better as a a candidate than a CS graduate fresh out of college. But all of the job postings out in the real world are looking for people with 2-5 years of programming work experience. How do you build up those first 2 years of experience? What kinds of companies hire programmers with no prior experience?"
Don't undervalue your QA experience either. QA experience means that you know how to test and debug, which is a rather large percentage of development. If you don't meet the requirements exactly, apply anyway, or look for jobs that mix QA and development, but make it clear that you want to move into a development role as soon as you are ready. Good luck!
unzip ; strip ; touch ; grep ; find ; finger ; mount ; fsck ; more ; yes ; fsck ; umount ; sleep
Unless you had a very good program in school, odds are you haven't actually written many real world programs. The stuff in school usually isn't finished programs, just enough to demonstrate the concepts being discussed.
So join an open source project and do some real world programming. Learn how to finish the job, catch those return codes, use a version control system, track down bugs in non-trivial programs, work on getting the documentation to actually match the program, etc. Learn how to work in a real team. Be a big enough contributer that you can rightfully claim to be a major contributer so when a prospective employer follows up by looking at the credits, commit logs and mailing list traffic you aren't seen as inflating the record.
Democrat delenda est
I hire programmers.
I hire entry-level programmers. For what it's worth, the last couple I've hired have been from India.
I look for a couple of things when I'm hiring entry-level. The first is experience. I'm not talking about professional experience, you won't have any of that yet. But what have you done? Have you done an internship? What have you done in your spare time? What have you done on your own? Can you demonstrate useful skills? Can you debug a program?
The first thing I'm going to throw you into if I do hire you is maintenance. Find a bug, fix a bug.
It's about attitude. Technical competency will be low at your level... but do you know how to find out what you don't know? Do you know how to research a problem? Do you know how to find an answer off the internet? Do you know how long to work on a problem on your own, and when to ask for help? When I show you how a certain thing is done, can you watch me once, and then pick it up?
Most programmers are bad at interviews. Most stink at writing resumes. So it's mostly going to be about other things. If you can make friends in the right circles. If you can get a recommendation from someone I've heard of. If you can show me that you have hunger and drive to get ahead... then I'll hire you in a heartbeat.
I'll keep you on if you don't mess around, but dig deep into the problems you're given. I'll be delighted if you bug me for answers when you need them. I will gladly explain concepts if you'll gladly listen and run with what you've been taught.
I only get so many openings per year. I've turned down folks for the wrong attitude most of all. I've turned down folks with professional experience if they kept a narrow focus and never ventured out of their comfort zones. I've passed on people who believe that programming is something like FrontPage, and that they shouldn't have to work hard, or understand much, to make a cool application.
I guess, mostly, I look for people who would be programming something even if they weren't getting paid.
Is that you?
Top flight developers producing quality code don't need large QA departments. They've already written well-designed, bug-resistent code, unit tests, integration tests, and performance tests, all in the course of producing something that works (the first time).
This is one of the funniest things I have ever read. You're not being serious, right?
Three years is the limit. If after three years you haven't managed to get raise or promotion apply for another job. Especially if your professional expertise is falling behind or soon you won't be able to get a job at all...
Now if you manage to get a better job with better salary ... well, that's great for you! But remember that expectations rise and you need to show that you are worth it. It can be stressful compared to your old job.
But if you can't get another job then there's some serious consideration to do. Maybe you are not that great worker after all?
You don't know what you don't know.
There's a world of difference between a guy who's been doing help desk and a guy who's been doing QA. The responses to these two questions aren't going to be the same.
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
And it's worth noting that many internships can turn permanent once you get out of school. "Oh, so, your internship is over. It's been nice having you. Hey, Steve, could you go put a new posting up for an intern on the website. Oh, by the way, also put up a listing for that second-rank programmer that needs a year's experience and preferably knows something about the kind of systems we use. Gee, where are we gonna find someone like that-- Oh, hey!"
Libertarians somehow believe that private businesses should be stronger than governments but weaker than individuals.
I've been a QA person in the past and now I do some amount of development in addition to some research work, so I have some idea of what you're facing.
My suggestions:
Find a sympathetic programmer that writes code that you are testing for. Ask him/her to show you how to set up a development and debugging environment that you can test against.
In particular, if you discover an intermittent bug, then find out how to set up a debug version of the environment to trap the bug as it is occurring. (That saves the programmer a lot of time trying to reproduce the bug.) Learning an IDE and/or how to debug and/or how to use a source code control system is a big step.
Also, approach somebody about writing test code against the production code, i.e. "unit tests", "white box" testing. That helps you learn the API.
Try to sit in on "Code Reviews" if your group does such things.
Start reading as much source code as you can. You learn a lot from reading other people's code. In addition, you can sometimes spot errors in the source. The sooner a bug is found and fixed, the better off you are.
Once you can start suggesting fixes to the errors you find, then you've demonstrated that you have developer skills in addition to being a good QA person. That combination is great, because you could become a developer who makes fewer mistakes than average.
Doing all this shows initiative which is also a big plus.