Skip to main content
MindTouch Lavacon

Portfolios and Interview Strategies: Four Critical Steps to Acing a Tech Comm Interview

In today’s job market where there are far more qualified applicants than there are jobs, you need an edge when interviewing.  Rather than subjecting an interviewer (and yourself!) to yet another Q-and-A session and hoping you did well enough to get an offer, use your portfolio to take charge of the interview and lead the conversation exactly where you want it to go. 

This article will show you how to use your portfolio to achieve the critical objectives needed to  ace an interview and land a technical communication job.

Four Critical Objectives

Most technical communicators I have met do not have interviewing strategies—they just answer the questions an interviewer asks, show a few sample documents from their portfolio and then leave hoping they did well enough to get a second interview.  Or worse, they let interviewers casually flip through their portfolio, totally missing an opportunity to show the interviewer exactly why they are a good fit for the job and how they can help the company with their specific technical communication needs.

Have you ever interviewed for a job that you thought went well but didn’t result in an offer?  If so, chances are you lacked an interview strategy that accomplishes four critical objectives:

  • Understand the job requirements.
  • Establish that you are an expert at what you do.
  • Establish that you really have done what you claim.  (That is, show that you have achieved practical results, not just absorbed theoretical knowledge.)
  • Show how you can solve the problems they are experiencing

By achieving each one of these objectives in order, you show a potential interviewer who you are, what you’ve done and why you are the best candidate for the job.


Objective 1:  Understand the job requirements.

While this article is mainly on how to use portfolios to control a tech comm interview, I would be remiss if I left out the first critical objective in any interview, understanding the job requirements[1].  This is critical because more often than not the published job description is not even close to what the hiring manager is really looking for, and it gives you some insight into what the interviewer thinks is important so you can show how you match those requirements.

Ask interviewers about the job, how the position fits in the overall documentation development process.  If you know the position has been open for awhile, ask what they have not been finding in other candidates interviewed and then make sure to address those points.

By really understanding what is needed and wanted, you can position yourself as the perfect match as you move the interview forward.


Objective 2:  Establish that you are an expert.

The next objective in the interview process is to establish you are an expert in your field.

Please note that when I say “expert” I don’t necessarily mean someone who has 20 years experience in the field.  To me an expert is some who understands and can competently apply the theory of technical communication to the level to which he or she has been trained.  For example, I wouldn’t expect intermediate technical writers to be experts in project management, but I would expect them to be experts at asking what procedures need to be documented and then documenting them.

So how do you establish that you are an expert in the field of technical communication? Show a sample documentation plan you have created. 

I’m not going to describe in detail what should be in a document plan since there have been excellent articles on doc plans in previous issues of Intercom, but let me say that a document plan (or a project plan if you are not developing a “document” per se) addresses all the aspects of a project that need to be known for the project to succeed.  The plan defines the scope of the project, how it is going to be developed, how it is going to be published, what the cost and schedule will be, etc.

In the interview, explain how just as a good engineer creates a design before starting an engineering project, a good technical writer creates a documentation plan before starting a documentation project.  Explain each item in the plan, why it the information is needed and why not having that information can affect the cost or schedule of a project.

I have found that most companies do not have mature documentation departments (especially in these “lean and mean” economic times), so chances are you will be interviewing with a person who is not familiar with document plans, why they are important, and what happens when you don’t use them (mission creep, missed deadlines, cost overruns, etc.).  Watch them nod their heads in agreement when you point out aspects they had already considered and watch them take interest when you explain aspects of a project they hadn’t considered!

By the time I finish explaining what goes into a documentation plan, the interviewer knows I know what I am talking about.  Thus, I achieve the second objective: The person recognizes I am an expert in my field.   


Objective 3:  Establish that you really have done what you claim.

Once you have explained the importance of documentation plans, show a few sample pages that resulted from the plan to illustrate its success.

Next, show sample pages of various documents you have written, pointing out the individual successes you achieved and/or problems you overcame.  (Note: before your go on an interview, tailor the samples in your resume to the type of job you are interviewing for.  If you are interviewing for a software documentation job, then take out less applicable samples in favor of more software documentation samples, etc.)

In addition to including samples of documentation you have written, I recommend including sample marketing pieces that have been written about the item you documented.  My company has done quite a bit of documentation for international consumer electronics and software companies, so in addition to the black and white pages from manuals we produced (boring!), I include full color advertisements my clients placed, product reviews from technology magazines, “first look” announcements, etc.  Not only does this position me as an expert in the field (If we do the documentation for those companies we must be good….), glossy, full-color ads and marketing collateral are interesting (and impressive!).

You can also include copies of awards you have won in publication competitions, “success stories”, thank you letters from clients, etc. If you can get them, also include statistics that show how your documentation has helped customers reduce tech support or production costs, how the sales brochure or demo disk you created increased sales, etc.  The more you can show that you add value to a company the better your chances of getting the job.

Note: In the portfolio and interviewing workshops I teach, I advise attendees to use their portfolios whenever possible to show that you have done what the interviewer wants.  For example, when an interviewer asks if you know FrameMaker, don’t just say you do, show samples in your portfolio that you created with FrameMaker. If someone asks if you know the Information Mapping™ method of structuring documentation, show samples of your structured documentation. Why? Because people believe what they see more than what they hear, and more importantly, people remember more of what they see than what they hear. 

By the end of showing your documentation samples, you have achieved the third critical objective: establish that you are an expert and really have done what you claim. 


Objective 4:  Show how you can solve the problems they are experiencing.

By now in the interview you have established that you are a competent technical communicator.  But how do you reach the ultimate goal, getting the job offer (or the contract or the outsource project)?  By using a before-and-after sample that shows no matter how bad a problem or need the interviewer has, you can help.

In my portfolio I have a really messy engineering drawing that looks like it was scribbled on the back of a napkin.  From that really messy drawing I created a very professional illustration, and dropped the illustration into the document.  All three versions are in my portfolio. 

Here is how I use the sample to land the job/contract/project: After I show my writing samples, I then say, “Let me show you how the XYZ system was explained to me.” and I show my really messy "before" sample.

Almost every time the person laughs and says, "That is EXACTLY how our stuff looks!!!" 

An then, after the person stops their cathartic chuckling, I show the “after” samples—how I brought order to chaos.

At this point I sit back, shut up and wait for a go button. (In sales talk, a “go button” is anything the other person says that indicates they want to buy.)  After the person finally finishes smiling at the before-and-after samples, he/she usually puts them down and says something to the affect of, “OK, how long do you think the project will take?” or “I have one more person to interview but I’d like you to come back so the VP can meet you….” or some other statement expressing the desire to move forward.

You may not have a messy engineering drawing, but I’m sure you have some sort of chaotic source material to use as a “before” sample until you can save a suitably messy drawing from your next project.  While we may take for granted that it is part of our job to turn the utterly incomprehensible into beautifully clear and lucid documentation, the point here is to show you can do that.

By showing radically different before and after samples, you can achieve the final interview objective: The interviewer decides you can help solve the exact problems the company is having, and thus offers you the job/contract/project.



A portfolio is not just a collection of samples of your work, it is a sales or interview tool you can use to control an interview and actively lead an interviewer to the conclusion that the you are the person to hire because:

  • You took the time to really understand the interviewer’s needs.
  • By explaining what goes into a document or project plan you showed you are an expert in your field.
  • By presenting samples of your work you showed you really have done what you claim.
  • By showing an incredible before and after sample you showed you can solve problems such as the ones the interviewer has.

Why would they hire anyone else?


Other Resources

There is far more information about portfolios than I could include in this article, such as what kind of portfolio to use, what can or should you put in your portfolio if you are just starting your technical writing career, how to present your portfolio, etc.  For more information about portfolios and interviewing, see the Resources page on the ProSpring website,

Also, please contact me if you would like me to present my Career Makeover, Interview Skills for Technical Communicators or Creating a Killer Portfolio workshops for your chapter.  I’d be happy to help.

Good interviewing!


[1] There are many other important practices you should follow when interviewing, such as establishing a rapport with the interviewer, maintaining eye contact, etc.  See the Resources page at for more information.

In today’s job market where there are far more qualified applicants than there are jobs, you need an edge when interviewing. Rather than subjecting an interviewer (and yourself!) to yet another Q-and-A session and hoping you did well enough to get an offer, use your portfolio to take charge of the interview and lead the conversation exactly where you want it to go. This article will show you how to use your portfolio to achieve the critical objectives needed to ace an interview and land a te