How quickly things change. A year ago, I received a dozen or more e-mails a day from companies and recruiters looking for developers. Some were so desperate they were willing to pay extraordinary salaries and bonuses. Wags were pronouncing massive shortages of engineers over the coming decade.
Now I'm flooded with mail from developers who have lost their jobs or fear their company is in danger of failure. Rare indeed is the message from a company trying to hire.
Macroeconomics mostly baffles me, but it does seem there's a pattern to our industry's boom and bust cycle. The early '70s, '80s, '90s, and now '00s all saw recessions of varying magnitude. For some reason, the start of a new decade brings a slowdown. Those of the '80s and '90s even changed the political climate when incumbent presidents lost their reelection bids.
The electronics industry always gets hit hard in these recessions. No surprise there; our business isn't particularly special, so it should decline in sync with the rest of the economy. The '90s subordinated common sense to a fury of stock market irrationalities. Many analysts sagely pronounced high-tech recession-proof. Too many folks believed them and spent as fast or faster than they earned.
Lifetime employment, once a staple of businesses like IBM, is long gone. There is no job security anywhere anymore. Despite Dilbert's buffoon-like portrayal of managers, their jobs aren't easy. Can you imagine responding to non-negotiable forces like demanding stockholders or empty bank accounts? By far, the biggest expense for most high-tech companies is salaries. So there's little surprise that's the first place most outfits economize. It's awful and brutal, and horribly impacts people's lives, but in our capitalist economy I can conceive of no alternative. Some would say the problem stems from a greedy corporate culture, in which the top dogs earn (or steal) millions or even hundreds of millions. Perhaps. Surely that's worth cleaning up. But a tens-of-billions problem in the United States' $10 trillion economy is in the noise.
The moral is that bad times always come. A hot economy is the prelude to a downturn. We little people must be prepared for the inevitable troubles. Squirrel away money. Avoid credit card debt. Bucks in the bank give you options and flexibility when the company folds, or when all engineers are told to take a 10% pay cut “for now.”
But saving is only part of a defensive livelihood strategy. I suggest that we manage our careers ourselves. No matter how benevolent and people-oriented your company, no one cares more about your future than you. Abdicate career-planning at your peril.
Avoid stagnation. It's sad to read rsums that illsutrate how an individual spent decades becoming expert at a very narrow, often non-transferable, skill. One came across my desk recently that more or less read, “12 years at XYZ company creating test procedures for the AN-XYZ radar system scanning mount.” The rsum-reviewer at a potential employer will dump this one in a heartbeat.
When my dad worked at Grumman in the '60s, a mechanical engineer there became the world's expert on lunar rover wheels. He spent almost a decade perfecting the technology and his skills in this infinitely narrow arena. The economic nosedive of the '70s saw him on the street, pumping gas. (For younger readers living outside New Jersey: there was a time when gas station attendants actually put the fuel in your car for you.) Perhaps his skills could translate to other, more diverse, areas, but the rsum's black- and-white facts condemned his career.
Our industry's career-killer is maintenance. “Joe, you did such a great job on that project that, well, no one knows the system like you. So why don't you maintain it for the next few years?”
Sure, maintenance is a critical part of any software project. It's unavoidable, and developers who do their best to dodge it do their companies a disservice. But all things in moderation. An outfit I visited recently rotates developers through a part-time maintenance schedule: every six months each engineer puts in 20 hours a week taking care of old projects for two months. That's not a bad solution. More people understand the old technology. The company gains by not being so dependant on a single person, and the staff have more fun and better employment prospects in the future.
Lawyers tell us to audit insurance policies and wills regularly. Nothing wrong with that, but I think it's more important to manage life than death. In the best of times and in the worst of times, you should routinely update and tune your rsum. Pretend you are a tired boss tasked with hiring, made a bit cynical by digging through a pile of rsums with their exaggerated claims. How can you appeal to that person?
It's a competition in a sense, a battle against your peers. The rsum is your main, and perhaps only, tool to get a foot in the door. It's the key that may get you admittance to the interview. Post-interview, most employers review the rsum, make notes on it, highlight the good stuff and problem areas. It's circulated for comments.
A crummy rsum-and in bad times, anything that's less than stellar-will doom your job search.
Sales and marketing
This critical document is a selling tool. A lot of us hate the thought of sales and marketing. I remember as a very young and very nave engineer telling a group of older folks how engineering is so “pure” and unsullied by the grittiness of sales and marketing. They all laughed, and rightly so.
Everything we do is sales. How do you convince your boss to get new development tools? Sell him. Show how the benefits outweigh the costs. Want to get your colleagues to start using eXtreme Programming or UML? Better sell them, hard, since change is always difficult. Show them the upside of the change. Be prepared to push for some time, as the biggest changes need the most selling. Hit them on all fronts.
Successful sales means we must speak the customer's lingo. Too many engineers never get this, and talk to their bosses about bits and bytes when those individuals really want cost/benefit ratios. Write your rsum to communicate clearly what you've done to someone who probably doesn't have a clue about your specific field.
Acronym overuse is a mistake. None of us know them all and a lot of them are industry-specific. Few folks not building colorimeters, for example, know what CIE means. It's best to describe your projects in terms any working engineer knows.
An example snore-inducer: “Worked on DOB-EKV project, used Shlaer/Mellor in C++ on Galazor 3.12 compiler running CDC1412.”
Yuck. Who cares what compiler, let alone version, you used? What did the system do? Who used it? Did it work? Was this a big job or did it take you six months because you're incompetent?
Better: “Wrote the DOB-EKV star tracking software for Marshall Space Flight Center. Used Shlaer/Mellor methodology and an object-oriented design. I wrote 25,000 lines of C++ running on an ARM processor. Six month project that flew successfully.”
Most rsums start with career goals. They're a waste of space, and are better handled in the cover letter. Let's face it, the prospective employer, at this early stage, cares little about you as a person. Most just want to know whether you can do the work. Replace the objective with a paragraph that states what you're really good at. Even better, write one that tells the company how they can use you effectively.
“Though I have written over 50,000 lines of GUI code in the Windows environment, I'm one of the best 8051 assembly and C programmers around. I can build tight, fast interrupt handlers for you, and am a master of working with an RTOS. If your product has performance constraints, limited memory resources, or tight timing, I'm the man for you.”
Traditionally, this sort of sales-y prose goes into the cover letter. That's a mistake. They get only a fraction of the scrutiny devoted to the rsum. Figure anything in the cover letter will be forgotten or de-emphasized, so make sure all of the meat, everything you want to say, is in the rsum itself.
We always conclude our rsums with a laundry list of languages and tools we've used. Though it does make sense to show a breadth of experience, the reader can't tell how well you know these things. Surely, no one is an expert at everything. Instead, consider something like, “Expert at C (over 100,000 lines), C++ (50,000), assembly (50,000). Very good at Perl, Fortran. Have completed projects in Modula, Pascal, Ada, and Algol.” The evaluator will appreciate the more coherent information and the honesty.
Rsums targeted at U.S. companies should be two or three pages long. A single page is appropriate for a new grad; five pages is too much. Overseas, longer is better; five, seven, or even 10 pages may be okay if you have a lot of experience. At that length, figure on more descriptive prose and fewer bullets.
Include lots of contact information. The experienced rsum reader expects a pretty high BS factor. Prove your points by including references (don't make the reader ask for them), and phone numbers and contact names for every job. If you had one bad experience, leave the contact information off for that one job and be ready to explain the circumstances, honestly, in the interview.
Everyone understands that if you're looking around while still employed, you'd rather not have the current boss contacted, but it's best to be explicit about your wishes.
Be sure it's easy to contact you. I've seen rsums with neither e-mail nor phone number. That hardly speaks well for someone wanting a cutting-edge technology job.
If you apply for an engineering/software job in the U.S., don't call the silly thing a curriculum vitae (CV). That's a term used mostly by people applying for academic jobs.
Never lie on your rsum. The truth has a nasty habit of surfacing. These days, companies check on degrees, immigration status, and more. For a few hundred dollars, you can investigated anyone in at least surface detail. Companies routinely run such checks.
But an honest approach doesn't mean you can't practice a bit of truth management. For example, why not customize the rsum for a particular job opening? If you know the firm uses 68HC11s, and you have that experience, emphasize it. Devote a greater part of the document to your expertise with this processor. If you have no 68HC11 background stress the transferable skills. C is pretty much the same thing on any small microcontroller. Sell the reader on your competence in their area of interest.
You take the truth too far. One rsum I've kept for years was for a person applying for a medical job. Under “mental health” she wrote, “better, now that I have full custody of my kids,” and then went on about the details of her breakdown. Discretion is often the better part of valor.
I worked for years with an engineer who later admitted he had no analog experience, though he was hired as an analog designer. He told me, “I just lied about it all.” Sure, he got the job, but that's a lousy approach to life. And he was awful at the work, later being relegated to an almost clerical position.
I've read hundreds, maybe thousands of engineering rsums over the years and I'm always struck by how many are so poorly edited. If you can't be bothered to get the tedious language details right, then who's likely to believe you'll take the time to make perfect software?
Proofread it. Put the doc on a shelf and reread it a week later. You'll be amazed at the mistakes that leap off the page. Have several friends go over it; if one's an English major, so much the better. Make sure a techie pal or two checks the details as well.
Try to get a boss-type, one who actually hires people, to edit the rsum. That input can be invaluable. Remember, your target audience isn't yourself or technical peers-it's someone who's making a selection based on how well the document matches their needs.
The official language in the U.S. is English, yet many of these important selling documents are written in what appears to be a corrupt technical argot. Butcher the language and you'll convince readers of your poor education, a very bad way to apply for a job.
There are important differences between “your” and “you're,” and between “there,” “their,” and “they're.” A billboard shouts the ad agency's thoughtless approach to work when it mixes up “your” and “you're.” These sorts of errors are inexcusable, easily avoided, and deadly on a rsum.
It's okay to mangle the grammar a bit; clarity and brevity is more important than a gripping storyline. Don't be chatty but do use active voice. Convey the information in an easy-to-read, concise way.
We all want our rsum to stand out, but resist the urge to be too quirky. Don't print it on orange paper. Don't include a photo of your dog or a bio of your spouse. It's a sure way to put off the suits who often make the big decisions.
When times are hard, want ads generate a rsum avalanche. Stand out by matching your skills to the prospective employer's needs, and by cogently documenting your prowess. esp
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at .