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?"

Comments

You should have asked this a year before.

[Lord Kano]

Internships are the way to go. A nice internship will give you some job experience. If you've been thinking about going back for your Master's degree, do that. And get an internship.

LK

Re:You should have asked this a year before.

[Ethanol-fueled]

First, try to move up in your current job while your foot's in the door. Make your ambition known to your co-workers and elbow into other aspects of the job with the blessing of the other departments - this could be something simple like reviewing code on your own time and then offering friendly suggestions at work - but don't step on others' toes and don't come off as a prima donna unless you're VERY good at what you want to do.

Do not ask your boss up front because s/he may be naive and order you not to try anything else(in which case you look for another job). After you schmooze around a bit while keeping your standard affairs in order, approach your supervisor(preferably with "attaboys" and testimonials from other department heads) and tell him/her you want to move up, then you provide evidence of your qualification. They LOVE to see how much money you can save them. If they're skeptical then offer to negotiate(i.e. work half of your day in QA, half in development or alternately ask for a 1-month "contract" to work for another department for the chance to prove your mettle). If the PHB says no and dosent offer you a raise to stay(heh, you may be so valuable in QA that they wouldnt move you no matter what your skills are) then look for another job.

If you interview for another job then emphasize the reason why you're leaving - you're capable of more, tell 'em why, and you want to move up. Stress that you have the skillsets to be capable of learning what you do not know. Ambition looks good and even though QA isnt the greatest job, it shows that you're stable and humble enough to stick to a shit job as long as it pays the bills.

Best of luck.

Re:You should have asked this a year before.

[plover]

A master's degree will certainly help, as will an internship, but those will take time and money to complete.

Is it possible the development team you're working QA for is hiring? Do you have contact with the developers? Have you built a reputation as someone who catches the hard-to-find bugs and documents them well? I know I value a competent tester, and if one of the good ones came to me looking for a way up, I'd be putting in a good word for him with management. Social networking is a good place to find hidden opportunities, and if it's people you've impressed with your skills at work, so much the better.

Re:You should have asked this a year before.

[Ethanol-fueled]

I personally don't feel QA is a shit job, I was just using strong words to improve contrast.

There's nothing wrong with having a stable job which has something to do with your degree.

I blame our parents :) for telling us that a college degree will land us a badass job and a big-ass house right out of college when the unfortunate reality is that the fresh mechanical engineering graduate will take their first job as a hinge or pipe designer or that a CS grad will have to code lazy kids' homework assignments for hire!

Re:You should have asked this a year before.

[bishiraver]

A good QA developer is just as necessary as a good developer. We all like writing original code, and it takes a special kind of person to write smoke tests, et al, for someone else's code. At my previous job, our product's QA department was just as important as our development department to get the monthly releases out on time.

Re:You should have asked this a year before.

[Anonymous Coward]

A good QA developer is just as necessary as a good developer. We all like writing original code, and it takes a special kind of person to write smoke tests, et al, for someone else's code. At my previous job, our product's QA department was just as important as our development department to get the monthly releases out on time.

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.

Re:You should have asked this a year before.

[Anonymous Coward]

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?

Re:You should have asked this a year before.

[Mad Merlin]

Interships are probably a good option. I did a CS degree with Co-op (four 4 month work terms integrated with regular classes, but the degree only takes 1 extra semester, as you don't get summers off), and I had no trouble at all finding a job after graduating (above entry level even, or at least well above entry level pay scale). For me, the already existing relevant job experience was pretty valuable.

Though, job experience isn't the end of the story, if you don't have job experience, you can still work on related stuff in your spare time. When I was applying for my one of my Co-op positions, I was able to show off Game! as something substantial that'd I'd already done, and that pretty much clinched the job offer. Game! wasn't something I created with the intention of putting on my resume, I just wanted to make a game, but it certainly turned out pretty well.

So, code something you like in your spare time. If there's nothing that interests you that you want to develop, perhaps a programming job isn't actually what you want to be doing.

Re:You should have asked this a year before.

[wild_fire1979]

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.

Re:You should have asked this a year before.

[weicco]

First, try to move up in your current job while your foot's in the door.

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?

Re:You should have asked this a year before.

[Cynonamous Anoward]

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.

Re:You should have asked this a year before.

[twoallbeefpatties]

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!"

Re:You should have asked this a year before.

[rfc1394]

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.

If you really believe this, please tell me what company you work for, I want to short their stock for when the company's poor quality and shlock coded applications cause it to go bankrupt!
(Only partially kidding)
And you spelled "bug resistant" worng. :) (Yes, I know that's 'wrong' but one of the rules of the Internet is that spelling flames must invariably have a mistake in them!)

Re:You should have asked this a year before.

[Anonymous Coward]

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.

Repeat

[HornWumpus]

http://ask.slashdot.org/article.pl?sid=08/09/29/1926216

Re:Repeat

[mooingyak]

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.

Contact your Universities Placement office

[dubious_1]

Even though you have graduated, most Universities will help you find a job if you graduated from there. The jobs for entry level ( new graduate ) positions are not typically going to be posted on Monster, Hot Jobs, etc. since we look for those people at University Job fairs.
I have been to many of these as a prospective employer, and there are always several Alumni who are there looking.

Simple

[FooGoo]

Lie on your resume...but you better be able to keep the job once you have it.

Re:Simple

[sjames]

At one time I would have been against that, but then I realized that most job postings are primarily a bunch of random bullet points HR tossed in that have little or nothing to do with the actual opening. That is, when they're not just wasting your time to inflate their folder of resumes 'just in case'. Then, of course, there's the postings demanding 5 years of experience in a 3 year old technology...

When it comes down to it, if you can't quite do the job, it's not like they'll say anything if your next potential employer calls them. They'll verify your employment without further comment as a matter of policy, no matter how good or bad you were.

Get involved in an Open Source project

[Nefarious Wheel]

Get stuck into an Open Source project, find out how it works, dive deep. If it turns out you can make a contribution that has even reasonably broad acceptance, that will add to your credibility as a programmer. At worst, you'll be keeping up your currency in at least one field.

Start coding

[robogymnast]

Build up a small portfolio by contributing to an open-source project, or start your own, or code that cool project that you have been thinking about in your head from time to time. Do whatever you have to do to start writing some actual working code.

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!

Demonstrate competence

[jmorris42]

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.

Three ways

[jwhitener]

There are 3 ways to get that first job:

1. Know someone in the company
2. Gain experience through personal projects and showcase it.
3. Be extremely charismatic and up to date on the job's focus areas and especially the companies specific mission.

Right out of college, with a degree in Anthropology, my first job was as a system analyst for a health care corporation.

For years I had tinkered with computers, and kept somewhat up to date on modern programming techniques, enterprise systems, and had created several little programs that resided on public servers that I could show off.

The interview was successful because I:
A) Knew exactly what they wanted for that position.
B) Researched the relevant "buzzwords" and lingo beforehand.
C) Was generally easy going and relaxed.

Despite having no formal education in computer science or programming, my obvious research into their business and corporate culture (thank you anthropology!) really showed well during the first encounter.

People with technical skills are a dime a dozen (unless you are striving to get into some very abstract programming job), and usually, a hardworking, motivated person should be able to convince a interviewer that they are up for the challenge.

Basically, apply for the job in front of you, do not apply for "a programming job". If you treat the job as something unique, do a little research on the company and their culture, and can "seem to be one of them", you are in.

Write test code

[Smallpond]

The natural step from doing QA is writing the tests for QA: specs, scripting, network, database, there can be a lot involved.

Is programming really for you?

[xquark]

Ask yourself this, do you really want to be a programmer?

Many people think its the "it thing" in IT, and that being a programmer and eventually an architect is the pinnacle of their career.

The truth is most people will not make good programmers, they wont end-up enjoying what they do, and something as mentally straining and intensive as programming requires you to continually have a good/positive mindset to be productive and to churn out top notch solutions.

I suppose this is the same for all types of careers - is it really for you?

That said most people will undoubtedly tell you to do some open source, start some of your own projects.
I have another suggestion, take your QA role, and ask yourself this: what tasks that you're doing now can be further automated, is there an area where something can be solved with a program?

If you can find that area(s), and build the program(s) to solve those problem(s), then you're probably a good fit for programming, if you're the kind of person that needs someone to tell them any one of those things, then perhaps its not for you...

How I did it (MFA to Tech Support to Programming)

[h4ter]

I got a non-technical post-graduate degree and now I'm a programmer. Only took a couple of years to get my first programming job. Here's how I did it.

First of all, I did as much programming as I could at my tech support jobs. Not all of it was company sponsored, but if I figured out something I could write that would help *me* do my job I would write it. I wrote all kinds of little things, and then I was able to truthfully add to my resume that I developed software.

I was also going to user group meetings for the language I was using most and meeting people there. I ended up getting my first job (and all subsequent jobs, actually) through people I met at those meetings. At least for the language, city, and time I happened to be in, the meetings were filled with people who knew about more work than they could take. And the recommendations you can get there are worth "2-5 years of experience" on a resume.

I'm currently helping my company's QA guy get some programming tasks so he can make the switch and give his job to some other poor CS grad. Is there anyone on the development team where you are that might help you out?

There's one more option: recruiters. I know they're not great, and the jobs you get through them aren't all perfect, but there are some recruiters who can help you market yourself without the exact "2-5 years of experience" someone's looking for.

One last thing: If you're any good at all you'll be way ahead of most people in this field. If you can get an interview, showing your abilities and desire to learn can be enough.

Good luck.

The right attitude.

[Lafe]

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?

from a manager

[jaydonnell]

I've been hiring programmers for a few years now and here is what I can tell you. 1. don't be afraid to send your resume to a job asking for 2 years of experience. Most applicants are absolutely terrible! I've often waited 6 months just to get one good resume from a programmer that wasn't asking for a ton of money. 2. Build something. Build something in your free time and put that on your resume. There are many times I would have hired someone in a heartbeat if they had simply done this and could talk intelligently about their project (for an entry level position). 3. aim for smaller companies if you are having a hard time getting hired. They don't use HR departments that filter resumes based on buzzwords and x years of experience.

Apply Anyway and have a portfolio

[Eskarel]

Employers in general, and in the US in particular, are, for the most part, totally crap at writing job adverts.

They write up things they'd like as opposed to what they actually need, and guess what, they don't get them.

When I first graduated, I saw a job looking for someone with 5 years experience with .NET. At the time, even the educational version of .NET had only been out for about a year and the commercial version had been out for about 3 months.

Since this company was not paying well enough to steal developers away from Microsoft, and wasn't anywhere near Redmond, one must presume that their eventual candidate did not actually have these skills.

Most employers ask for way more than what they're going to get, and in most cases more than they actually need.

This is particularly the case for people in entry level jobs, they want a guru for intern pay, and it's not going to happen.

Try for everything position you think you can do, be willing to take a pay cut if you have to in order to get your foot in the door, and have some good clean code samples to provide if you're asked.

When I was fresh out of Uni I did the same things you did, but I've since learned, that if you don't try you'll never get anywhere, and, especially when you've still got a pay check coming in, the cost of throwing out resumes is pretty much nil, and the rejection isn't so bad.

You should of course, as others have said, also make sure that folks in your own company know you want to move up in the world, and take whatever opportunities you can get your hands on internally. Even if the job isn't exactly where you want to go, moving up will make you look a lot better on a resume than sitting on the bottom for years.

How I got into the game industry

[VirexEye]

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.

Transfer within your current company?

[il dus]

Why not move from QA to dev in your current company? You (should) already know the product, so moving over internally will be a lot easier than switching to an entirely new place where, not only are you an entry-level developer, but you also don't know the product and the internal processes.

"Need" isn't the right criteria.

[raehl]

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.