getting that first job

Subject: getting that first job
From: KAREN_OTTO -at- HP-SPOKANE-OM2 -dot- OM -dot- HP -dot- COM
Date: Tue, 26 Nov 1996 10:04:12 -0700

Item Subject: cc:Mail Text
Think about the hiring experience as a huge technical communication
exercise.
The "user" is the hiring manager/team, and you have to communicate how
well you can do the job.

Your cover letter is the first document your user sees. You have to
get their attention first. Think about this document as a sort of
marketing document. It needs to be short and to the point. It also
needs to make them want to read more (that is, your resume).

How do you get their attention? Think about their ad. Right there,
they say what is most important to them. Make a cover letter that
answers those issues.

In your resume, you have a good chance to more deeply connect with the
user. By understanding your user, you can word and structure your
resume into their language. Remember, if they can easily understand
the words you use, they can concentrate on what you have to really
say.
If they advertise for a "team player", reword your resume to emphasize
the times you worked succesfully in teams. If they seem to be
emphasizing technical skills, then you emphasize the same. If they're
really hoping for a more experienced person, make sure *all* of your
relevant experience shows up clearly.

Here's an example: You had a class project where you worked in a team
of 5 people to develop a paper and online manual. You can write about
it in your resume from many different aspects:
- how it was to work in the team
- how you worked on your own
- how you created both online and paper within the time alloted
- what the development process was
- what skills you learned in order to do the job
- what technical content you had to learn

There's never enough time or space to explain all aspects of a
job/project in a resume. That's why you should tailor each resume to
the user's needs, which they have hopefully stated fairly well in the
advertisement.

Don't forget the phone interview and/or on-site interview. This time
it's tougher, but at least you get the opportunity to interview the
user and find out their real needs. It's still all a communication
issue, though - can you verbally make them understand that you can
fill their needs?

Good luck,
karen otto
karen_otto -at- hp -dot- com


Previous by Author: Re: Documenting a Programming Language. Was Syntax Diagram
Next by Author: Re: Query -- Software doc writer's responsibilities
Previous by Thread: Re: getting that first job
Next by Thread: Does HTML recognize small caps?


What this post helpful? Share it with friends and colleagues:


Sponsored Ads