[ Home | Library | Contents ]


[ Prev | Next ]



by Matt Slot

Getting a Job

I've mentioned several times how a computer degree is inadequate for doing real work in the real world. Classes are fine for learning procedural stuff, like writing binary search trees and doing Fourier transforms, but there is so much that is simply never discussed.

When you actually go looking for a job, you shouldn't be surprised to find that companies are looking for more than straight-A students. While heavy memorization can improve an academic record, there are actually many skills that simply aren't developed through perfect attendance and copious notes.

If you really want to get a good job in the real world, you need real world experience and proven track record. The job listings detail how you need years of experience with a given language or software package, but of course, if you haven't actually had such a job, you don't have the experience. It's a conundrum.

Let me tell you a secret... you don't need to fall into this trap. Instead of waiting for your last semester to start preparing and hunting for a job, take the initiative and put some practical experience under your belt. In fact, these tips are useful in almost any field -- they are universal skills.

Dissection of a Resume

Imagine your resume... or maybe you have it handy. You can probably divide the information into several groups: name and contact information, education and work history, and a bulleted list of skills. Name and contacts are just that. For each item in education and work history, you should make a brief note regarding what you actually learned.

As for the skills, don't try to be exhaustive. Interviewers see enough resumes that list operating systems, compilers, and numerous programming languages. (If you actually put HTML on a resume for software engineering, rip up the paper and start from scratch). These things really don't impress them. Each are examples of task-oriented skills -- things that can probably be read about and learned in 2 weeks time by a competent programmer.

If you want to get the job, present yourself as goal-oriented. If you can list the following skills on your resume, with software or references to back them up, then you will almost certainly get the job -- even as a recent grad!

Other keywords include initiative, teamwork, and enthusiasm. Don't forget to add the task-oriented stuff, but make it concise and don't dwell on the details.

Getting the Skills

I'd say that about your second year of college is probably the best time to start working toward these goals. You won't find them in the course listings, and nobody will advertise them in the job boards, so it's up to you to make them happen.

The first and most straightforward way to get some experience while in school is to find some nearby work in your field. A work-study program or internship at a local business can give you a head start on your career path, while not requiring lots of previous experience. Often, they let you start working while taking the necessary courses simultaneously.

An intern has the opportunity to work with professionals in the field, ask any "dumb questions" that come up, and basically get a feel for how things are done. Alot of the work is simple stuff, coding basic utilities and tracking down bugs, but in the meantime you gain practical experience working as part of a team and seeing a project through its evolution.

The other advantage to the hands on approach is interacting with the smart people that you work with: learning new algorithms, debugging real world code, and even brainstorming.

Another way to get the practical experience is through contract work. The pay is pretty good, and it's a good way to get a project that you can work on and finish in a finite amount of time. This path is rather risky, however, because there are enough people out there willing to take advantage of young, naive programmers. I'd strongly recommend that if you follow this path, work for someone you know and trust and get everything in writing.

Finally, you can always strike out on your own and start with small shareware projects. This is a very popular plan, because there are so many great ideas that it's tempting to jump right in and write code. Everybody at some point wants to write the next cool game.

Large numbers of novice programmers clutter programming and discussions with requests to write a new game -- don't get sucked in. Writing a 3D, network, role-playing, game is simply too much work for people with no experience. The number of game projects that stall after a few months and a partial demo is staggering. It's easy to write the first 30% of a game, but actually finishing the project is difficulty.

I'd recommend starting with something feasible, a small utility program that you can start and finish in about two weeks. Any more, and the real world may distract you long enough that "code rot" sets in and you never finish the project. After the two weeks, you should have a decent working program that is worth showing off to your friends.

Your friends will give you three things you need: UI bashing, feature requests, and the warm fuzzies you need to make the thing happen. Use this momentum to finish up the project and get it out the door. Find a publisher who'll work with you, post it to the Internet as freeware, or use Kagi to collect shareware payments. Most importantly, finish the project.

Writing a nice graphics demo is pretty cool, but designing and implementing a full software package is much more impressive. Companies like to hire smart people, but they will go the extra mile for a competent software engineer who can meet commitments and ship a product.

Matt Slot, Bitwise Operator



[ Prev | Home | Library | Contents | Next ]

Copyright ©1995-8 by Ambrosia Software, Inc. - All rights reserved