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?"
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.
Are you a professor? or do you work in theoretical software practices? Have you EVER worked on commercial software? I work for a certain media co., on a certain well known video player. There are so many things that simply cannot be tested except by a human. Management is always begging QA and engineering to try and come up with ways to automate testing of these things, but no one ever gets anywhere.
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.
"The GPL is viral by design, like any good religion."
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.
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
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
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.
paintball
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.