Getting Hired As an Entry-Level Programmer? 540
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?"
Try Harder (Score:2, Interesting)
Don't ask me,my career never started because of it (Score:3, Interesting)
Re:Get involved in an Open Source project (Score:3, Interesting)
Agree completely. Find a FOSS project that uses the same technologies as you'd like to use in your 9-5 job, and get stuck in. It (generally) costs nothing more than your own time.
Given a choice between 2 programmers with similar skillsets and experience, I'd be inclined to go with the guy who's got FOSS coding experience in his background. The implication is that you're prepared to put your code out there for peer review (which takes some guts), and you're prepared to write code to scratch your own personal itches. Both of those demonstrate qualities in the people I'd want to work for me.
Re:You should have asked this a year before. (Score:5, Interesting)
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).
If you have to pay a phalanx of QA engineers to find bugs post-facto ("just as important as our development department"), you're doing it wrong. The bugs shouldn't have been there to begin with.
I assure you that I work with some of the best devs that are in the market right now. They are really good, but when you have to deal with millions of lines of code across a extremely complex system, bugs happen!!! :)
Unit testing, code coverage tools, continuous build systems can just mitigate the effect not eliminate bugs.
Even QAs just make sure that the quality is within acceptable parameters they can't eliminate them completely.
Work for free (Score:2, Interesting)
You need to get some real experience that you can use as a reference. Put an ad on Craigslist or the like to program for free in exchange for a reference. You'll have skip the $ for a while, but it takes money to make money. You still have your QA job, right?
I've had to low-ball when changing languages in the past in order to get that experience for reference. It goes with the profession (unless you are a good liar with a lots of liar friends).
Re:Sounds eerily familiar (Score:2, Interesting)
I was in the same situation when I graduated in 1991. In hindsight, I probably would have been better off if I had decreased my academic workload and gotten a part-time coding job like a lot of my classmates did. Instead, I took all the classes I could to finish college in 3 years (with AP credits + a summer term), and ended up with a degree but no work experience. It took me years to find each of my programming jobs, due to both my lack of experience and also market trends.
Two of the jobs I did eventually get were because I had relatively rare niche skills that the companies were looking for (MC680x0 assembly language programming). I developed that on my own for personal projects, and was able to demonstrate the programs I wrote to the employers, which in that case counted as experience even though it wasn't "paid" experience.
The last job I got, I started out doing system administration and later moved into a programming position when an opening came up. In this case I already had several years of paid tech support experience plus Red Hat administration both on the job and at home, so that got my foot in the door.
So my advice is to focus on the type of programming you want to do in your spare time, whether it's for your own projects or a community open-source project, to keep your skills up to date. Then keep an eye on job openings, and when an opportunity arises in the direction you want your career to go, grab it.
Re:You should have asked this a year before. (Score:5, Interesting)
How can code analysis ever verify:
* YUV->RGB color conversion (there isn't even a single right answer to this, it's subjective)
* A/V Sync
* Audio language selection (how do you write code to tell if the guy is speaking in french as opposed to spanish?)
* GUI Widget alignment
* Subtitle Placement
The list goes on and on. Some of these things do have unit tests, but bugs pop up anyway, bugs which never could have been caught by any unit test. Some parts of our code lend themselves to unit tests (file parsers) and those sections are heavily tested. Other sections simply don't offer the opportunity for analyzing the results via code. All-in-all, a major update to the player can require over two months of QA by a team of 8 testers. This is in addition to the thorough unit tests you claim _should_ take care of all that.
How I got into the game industry (Score:5, Interesting)
Right after graduating I managed to get into the game industry as a programmer. The trick?
Internships!
If you look on craigslist (I'm in the SF bay area so your mileage my vary) there are tons and tons of postings looking for cheap/free programmers in the form of internships. You gota put in your time there instead of putting in your time in QA.
Since you have been in QA a few years, you should talk to your manager about moving on to a jr level programmer position in your company. If they are willing to work with ya, problem solved. If not, time to move on ASAP.
Re:You should have asked this a year before. (Score:3, Interesting)
Depends on the job.
We're currently hiring (if you trawl through much older posts of mine, you'll probably find details, but I won't repeat them since we already had enough applicants from Slashdot! (and may well take one...)), and I really don't expect the potential hire to know everything they need to for the job. One of the reasons for this is that the main thing they need to know is our own proprietary API, so what we're looking for is a person that is going to be able to pick it up quickly, and can demonstrate this from their background. One guy who applied (from Slashdot) sent me some sample code he wrote for example (in the language we're looking for), and explained the various concepts involved in his program. That's much more valuable from our side.
Now, if someone were to come along who magically already knew our API, of course we'd have to pretty seriously consider them, but really, an API is just an API - anyone can learn it if they're even half decent coders. Knowing how to write good (as in, working, bug-free, fast, flexible and extensible) code in general is still the most important thing.
Re:You should have asked this a year before. (Score:4, Interesting)
For the "default" skin, just keep it DEAD simple
And yet, even that needs to be tested.
I work on firmware and one of our biggest challenges is that there are soooo many seperate systems that have to come together that even though the devs unit test their code to death (and for the most part it works), once you start integrating stuff, things break. You have the kernal, then apps running on it, then the end user interface software. All this simply must work. The only way to get there is to test it. :(
5000 hours of tests, and yet we still had escapes
As to the submitter:
Ask how you can get involved with writing software to help your group. Even if it's "programming" a smarter excel sheet to collect data, or a perl parser with GD to plot results automatically from logfiles, just find an unfilled itch in your group and scratch it. If it's hardware QA, see if you can work on programming your instrumentation drivers/data collection/etc.
While I genuinely realize what I'm going to say is not true everywhere, many bosses are open to employee development, especially if it helps their group out. Tell your boss you'd like to grow your skills and want to stay in the group. Ask where you could pick up a small extra project. Be proactive and *look* proactive. Most managers want smart employees, just not smart asses. Single most important advice: be humble. A close second? Don;t piss in anyone's cornflakes/eat from their ricebowl (especially if they are territorial).
Finally: Good luck.
-nB
"Need" isn't the right criteria. (Score:5, Interesting)
The question is, what is the most efficient way to produce bug-free code?
Sure, you can take your top-quality programmer, and have him do everything. But that's the least efficient way to do things. Your top-quality programmer can churn out 80% perfect code with 20% of his time. The other 20% is the hard part.
It is FAR more efficient to pay one programmer and two to three QA folks to debug that code than it is to pay one programmer to make his code perfect and one QA guy to debug it.
And that's setting aside entirely that on any significant project, you have 5, 10, 20, 100 programmers, and you need the QA guys just to make sure that it all works together right. Programmer A writing perfect code and Programmer B writing perfect code doesn't mean their code combined works at all.
Re:You should have asked this a year before. (Score:4, Interesting)
I think you hit on one point right there. Companies are only interested in what you do for them right now... if you are "good enough" then why move you someplace else? Of course you'll never be good enough to move up, because you were only good enough for the position you have right now. It's a catch 22 and HR loves it.... You're good enough to do the work, but not good enough to demand the position and pay... that's just right for the company interest and very hard to break.
agreed (Score:1, Interesting)
Re:You should have asked this a year before. (Score:3, Interesting)
Not necessarily true.
At a previous job (that I worked at for a year and a half before mergers and so forth required me to take myself elsewhere), I was hired to work on an ASP.net application. I had no ASP experience, and barebones JavaScript knowledge: I was hired as an interface designer. Within six months they were paying for me to take an ASP C# class at the local university. Within a year my JavaScript skills were some of the best on the team.
The interview tested not only my known skills - probing to find out what I did and did not know - it also tested my problem solving skills and my ability to absorb new knowledge and utilize it quickly.
I'm glad they hired me. Not only because it was a fantastic job, but the team I worked with is still one of the best I've worked with. Ever. I learned a lot, and I contributed a lot, and eventually I came around and taught them a few new tricks in a language that doesn't quite work like a lot of other ones. Sometimes it pays to not just test technical skills in an interview - and many times, admitting you don't know something is much less of a kiss of death than attempting to bullshit your way through.
Re:You should have asked this a year before. (Score:2, Interesting)
Re:You should have asked this a year before. (Score:2, Interesting)
This comment has already gotten nailed, but I'll just add: show me a company that only has "top flight" developers. In my experience, 10% are "top flight", 20% are fine and 70% should go do something else. You may have the good fortune to work for a company with better numbers, but the last number is never zero...
Re:You should have asked this a year before. (Score:3, Interesting)
He is, the existence of a QA department is an admission of weakness. As others have said, there's nothing "easy" about QA, it's as hard as design, if you are doing it right. To a large degree, because you should be doing the same job.
I get nervous when there's a dedicated QA role in a company. It tells me that every pigeon has his hole.
Re:Build something (Score:3, Interesting)
Pick a technology you find interesting and build an application in it.
Amen to that. When I'm interviewing people, my main concern is that they can do the work. If that's job experience, that's great. But as long as you have to maintain code in production, then that's the main thing.
Personally, I have a mild bias toward hiring people with hobby projects. It shows that they're doing the work because they like it, and it lets me see what they can do themselves. With a resume item, it's always hard to tell who did what, but with a solo or open-source project, it's much clearer.