Re: Interviews and Portfolios

["Robyn M. Nace" <robyn -at- BIT-NET -dot- COM>]

Sybille Sterk wrote:

> I generally have a problem with portfolios. Often projects are created by
> several people, not just one - so how do you show in your portfolio your
> part in a project?

That's why there's:
a) framing material, in which you indicate that you worked as part of a
team, and
you did (x).
b) an interview, in which you can explain the pros (and possibly cons) of
working
with that particular team.

> The other thing is that, theoretically, you could
> download whatever takes your fancy from some tech author's web site and
use
> it in your portfolio.

Theoretically, however, a good interviewer will sniff this out fairly
quickly.

> Generally, I find it far more useful (for both me and the interviewer), if
> the product I'd be writing about is described to me and then I am asked
how
> I would tackle the documentation, i.e. what kind of documentation I would
> suggest or how I would improve existing documentation. This shows far more
> if the interviewed author is suitable to the task, can work within company
> restraints and is the right person to work in this particular role.

This is one interview scenario, but the portfolio scenario can also work.
Behavioral interviewing is often a better predictor of success than
hypotheticals. For example, if someone described a situation in which I had
to do
an immense amount of work in a short period of time, I would pull out my
portfolio and show them the Help responses that I did, and explain how I
tacked
that.

> In any case, as the interviewer you don't want to know if a prospective
> tech author can write about another product, but if he can write about
yours.
>

I must disagree. If a person can write about one product, he or she can
probably
write about a similar product. For example, I wrote about one Web-based
software
program, and was interviewed for another Web-based tech writing job. You can
often have many ideas based on previous work. For example, how to (or how
not to)
tackle a Web-based Help system. (I'm not talking about duplicating or
stealing
work, that's completely different, and another discussion entirely.)

In addition, end user documentation generally consists of procedures. Past
work
can show how well you write procedures, or how well you captured graphics,
or how
well you wrote intro material.

I always hope that interviewers see the connections between all of the work
that
I've done. At least, I hope that they can see how well I can write and
design.

--
-Robyn

"No, my powers can only be used for good."

http://www.bit-net.com/~robyn/

Now appearing in Little Shop of Horrors!
August 19-22 @ the Downstairs Theatre in downtown Nashua

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=