Can I show some of my etchings?
February 27, 2008 8:15 AM Subscribe
Interviewing with a technical writing / communication portfolio. What resources and tips for those who have gone through it or hired from it.
Now there is plenty of information on putting together a technical communication portfolio, but what about the "how" to interview with the portfolio? What advice, tips, resources can you point me to on the "how" of interviewing with a portfolio and interviewers' methods of evaluation?
I am trying to put together resources and advice for both students and people entering the field from other professions.
Thanks for any help on this.
Now there is plenty of information on putting together a technical communication portfolio, but what about the "how" to interview with the portfolio? What advice, tips, resources can you point me to on the "how" of interviewing with a portfolio and interviewers' methods of evaluation?
I am trying to put together resources and advice for both students and people entering the field from other professions.
Thanks for any help on this.
The more varied a collection of writing samples you bring, the better. If you know what kind of writing the job requires, present samples like that. Stress your knowledge of the tools - FrameMaker, InDesign, or whatever.
Actually, I've found the interview process for tech writing much less laden with 'what kind of an animal would you be' nonsense than in other careers I've had, but that might just be the small sample. My experience is that if you've got the chops, it shows, and unless you dress wrong or spit, the chops are what people care about.
posted by Kirth Gerson at 9:59 AM on February 27, 2008
Actually, I've found the interview process for tech writing much less laden with 'what kind of an animal would you be' nonsense than in other careers I've had, but that might just be the small sample. My experience is that if you've got the chops, it shows, and unless you dress wrong or spit, the chops are what people care about.
posted by Kirth Gerson at 9:59 AM on February 27, 2008
Use the portfolio to make points, discuss competencies, and illustrate ideas. Effective uses I've seen are when elements of the portfolio are used to illustrate how you solved a problem, particularly if you can relate it to the position on offer.
"This one-page illustration is the result of an attempt to reduce translation costs and increase compliance with a calibration procedure. I started with a ten-page text document with five discrete illustrations. I worked with an illustrator to develop a visual narrative that leads the customer through a successful calibration. See how the critical settings and results are the only text. Informal testing found that despite being almost entirely graphical, 8/10 users were successful on the first try with this procedure versus 6/10 with the one it replaced. It's not only cheaper to translate, users seemed less intimidated by the procedure."
Credibility accrues to writers who are very specific about what they did or did not do. "This chapter represents the standard hardware manual template we use for everything. The layout is predetermined. I like that it is very scannable and the treatment of notes, cautions, and warnings is very effective. I don't like the use of table rules as I feel they break up the information for no increase in comprehension, but I wasn't in charge of templates, so I got a 'thank you for your input' when I suggested the template be redesigned with cleaner tables. We don't have illustrators so the graphics are mine, created using Visio. That one's just clip-art. I'm proud of *that* one because it started with an exploded view from a mechanical engineer and looked like a complicated mess. I taught myself how to use masks and filters and managed to highlight the angle of the Jonson rod connection to the Frobnitz, which was critical for that step, and make that the clear focus of the illustration. I had specs to work from so the logic descriptions are based on excellent specs. An engineer walked me through the assembly replacement procedure shown *here* but in *this* section I figured out the calibration steps on my own, using the performance verification specs and my existing knowledge of similar procedures. It was challenging to write them for users who may only occasionally work with high voltage - I needed to be very clear, very concise, very accurate, very safe, yet not scare anyone away from completing the procedure properly."
I wouldn't go on and on endlessly like that - just some examples of ways to use the portfolio pieces as talking points rather than some sort of static exhibit. Honestly, I want to talk to people and 'hear them think' - not admire work they might not have even done themselves (for all I know).
posted by cairnish at 10:10 AM on February 27, 2008 [1 favorite]
"This one-page illustration is the result of an attempt to reduce translation costs and increase compliance with a calibration procedure. I started with a ten-page text document with five discrete illustrations. I worked with an illustrator to develop a visual narrative that leads the customer through a successful calibration. See how the critical settings and results are the only text. Informal testing found that despite being almost entirely graphical, 8/10 users were successful on the first try with this procedure versus 6/10 with the one it replaced. It's not only cheaper to translate, users seemed less intimidated by the procedure."
Credibility accrues to writers who are very specific about what they did or did not do. "This chapter represents the standard hardware manual template we use for everything. The layout is predetermined. I like that it is very scannable and the treatment of notes, cautions, and warnings is very effective. I don't like the use of table rules as I feel they break up the information for no increase in comprehension, but I wasn't in charge of templates, so I got a 'thank you for your input' when I suggested the template be redesigned with cleaner tables. We don't have illustrators so the graphics are mine, created using Visio. That one's just clip-art. I'm proud of *that* one because it started with an exploded view from a mechanical engineer and looked like a complicated mess. I taught myself how to use masks and filters and managed to highlight the angle of the Jonson rod connection to the Frobnitz, which was critical for that step, and make that the clear focus of the illustration. I had specs to work from so the logic descriptions are based on excellent specs. An engineer walked me through the assembly replacement procedure shown *here* but in *this* section I figured out the calibration steps on my own, using the performance verification specs and my existing knowledge of similar procedures. It was challenging to write them for users who may only occasionally work with high voltage - I needed to be very clear, very concise, very accurate, very safe, yet not scare anyone away from completing the procedure properly."
I wouldn't go on and on endlessly like that - just some examples of ways to use the portfolio pieces as talking points rather than some sort of static exhibit. Honestly, I want to talk to people and 'hear them think' - not admire work they might not have even done themselves (for all I know).
posted by cairnish at 10:10 AM on February 27, 2008 [1 favorite]
As cairnish says, you can't give someone even a modest portfolio and expect them to interpret it on their own, so be prepared to deliver a narrative that explains your portfolio and how it showcases the varied skills you have, technical as well as interpersonal; effectively interviewing engineers and developers is as much a skill as writing.
I was a technical writer for five years and did my share of interviewing other writers to join our team, and the things that impressed us the most were 1) experience doing the task-based documentation our company preferred, 2) experience preparing documentation that will be localized, 3) experience with our authoring tools (FrameMaker, DreamWeaver), 4) experience in our general market niche. Of the folks we interviewed, very few were as prepared or cogent as the mock interviewee in cairnish's example, but the few who were almost always hired.
posted by mosk at 10:29 AM on February 27, 2008
I was a technical writer for five years and did my share of interviewing other writers to join our team, and the things that impressed us the most were 1) experience doing the task-based documentation our company preferred, 2) experience preparing documentation that will be localized, 3) experience with our authoring tools (FrameMaker, DreamWeaver), 4) experience in our general market niche. Of the folks we interviewed, very few were as prepared or cogent as the mock interviewee in cairnish's example, but the few who were almost always hired.
posted by mosk at 10:29 AM on February 27, 2008
« Older I'm not religious. Why is it that all the girls I... | Where did that fucking flash game go? Newer »
This thread is closed to new comments.
posted by Melismata at 9:55 AM on February 27, 2008