In one of the technical writing community forums, I came across the age-old confusion of candidates who prepare for an interview and struggle to deal with the standard questions on *work samples*.

While I can understand the confusion for relatively less experienced professionals, I am surprised at why experienced professional find it difficult to deal with this situation.

For an Experienced Professional

A candidate *A* with an experience of say, more than four or five years has many options to handle it.

- *A* is likely to have a blog, so one can create a manual (for self-reference as a kind of checklist, and of course as a sample document for interviews). One can have the standard structure for this manual including title page, revisions, conventions, TOC, and the procedures and instructions. The procedures can be (a) how to create a new post (b) how to create a new page (c) how to create/manage categories (d) how to manage (approve/reject) comments, and so on.

- *A* can create a manual on how one prepared the *resume* document for the interview (why not?). It includes:

- steps on creating styles (I am yet to find a SINGLE resume document that was written using Styles)

- file name conventions (99 out of 100 documents that I receive as CV, have poor naming scheme)

- setup page properties, and so on.

A clear, accurate, and flawless (though not extraordinary) resume is absolutely neccesary for an experienced technical writer, as I talked about it during STC India’s 13th Annual Conference Chennai, in Dec 2011. So, your document can have a section on best practices that you followed while creating your resume .

- Since *A* is experienced, one has options to develop manuals (A quick guide and why not a cheat sheet?) for how to tweet, how to create/manage email signatures in MS Outlook, how to clear cache from internet browsers, and the list goes on.

- Why not a case study on how you added value to a documentation project?

A Beginner

A candidate *B* with less than one year of experience may be caught unaware at such a request for *work samples*.

- *B* may lack general confidence required to handle such a request because of absence of directions from peers (or community), and because of lack of exposure so far.

- *B* may not have a blog (as yet) and the ideas for *what kid of manual I can develop as sample* are not leading anywhere.

- Again the options are to develop basic level manuals for how to tweet, how to create/manage email signatures in MS Outlook, how to clear cache from internet browsers.

An interview is actually a conversation between an organization and a candidate. Remember that you need the job as much as the organization needs a capable and confident candidate.

Prepare yourself with accurate and good quality work-samples. Stay spontaneous rather than preparing too much for the interview questions. Engage in conversation rather than setting up the tone of questions-answer format. Remember, the work samples are not the only criteria for your selection; it is one of the parameters. So, give your best shot, and stay relaxed.

For the STC India Annual Conference 2011 (Chennai) on 03 December, I am speaking on *Passing The Baton*.

Like any other profession, technical writing evolves across generations. One generation of professionals pass the baton to the next one, along with all the skill, knowledge, and experience. It means handling over a huge responsibility to carry forward the tradition and best practices.

I am not a veteran in this field; however, I plan to share my thoughts on (a) how the current generation of experienced professionals is passing over the baton to beginners, the next generation technical writers, and (b) how the next generation responds to the opportunities.

Some key pointers that gave me food for thought are:

• What we expect from beginners and next generation technical writers
• What we focus on
• The unfortunate signs
• The *Wholeness* of being a technical writer

If you have not registered for this much awaited event, do it now here: http://www.stc-india.org/conferences/2011/?page_id=6. See more topics and the detailed agenda at: http://www.stc-india.org/conferences/2011/?page_id=2.

Flight reserved. City map explored. Menus scanned. Catch you at Chennai! 

- Vinish

In my presentation during first STC India Chapter Summit earlier this month, I conducted a technical writing quiz for the audience. Nothing fancy, it was just part of STC India Chapter’s initiatives to conduct QUIZ on monthlly basis, that they started in February 2011.

Here are the QUIZ questions:

1. Technical Writing was first recognized as a separate profession in the West in: (TICK the correct answer.)

(A) 1537, when a technical writer named Wills Markum wrote a technical document about the mechanics of flight

(B) Late 1970s, when President Jimmy Carter mandated simple language in government documents

(C) First half of the 1800s, when Augusta Ada Byron documented the analytical engine invented by Charles Babbage

(D) The 1990s, when computers became more widely used

2. On average, what percentage of a documentation project’s time is spent gathering information? (Select one answer.)

(A) 5-10%

(B) 15-20%

(C) 25-35%

(D) 40-60%

3. What section of a technical user manual is used most often by target users? (You can select multiple answers.)

(A) Procedures

(B) Troubleshooting

(C) Index

(D) All these equally

4. In MadCap Flare: For an image listed in Content Explorer, you can directly open it in snagIT or in Photoshop. (Select one answer.)

(A) True

(B) False

5. MS Word 2007: What page view can you use to see what it will look like when printed? (You can select multiple answers.)

(A) Draft View

(B) Print View

(C) Reading View

(D) Outline View

6. The dash used to express range of values such as ‘30-35 age group..’ is: (Select one answer.)

(A) An en dash

(B) An em dash

(C) It can be either en dash or an em dash; does not make a difference

(D) Neither en dash nor em dash, it is a hiphen.

7. RoboHelp: For merged projects to create a webhelp, does generating or publishing a master project updates the child projects automatically? (Select one answer.)

(A) Yes

(B) No

8. Which of the following sentences (more than one) are in the active voice? (You can select multiple answers.)

(A) Click on the Delete button and ABCDE asks you to confirm if you want to delete the selected order.

(B) Click on the Delete button and confirm if the selected order to be deleted by ABCDE.

(C) To delete the selected order, click on Delete button and confirm that you want to delete it.

(D) For the selected order to be deleted, click on Delete button and confirm that you want want to delete it.

9. RoboHelp 7 (or later): In webhelp, you can format the text of breadcrumbs for font properties, color, size, and for the location of breadcrumbs.

(A) Yes

(B) No

10. Compared to a serif typeface, a sans-serif typeface is easier to read on the screen because the letters are simpler.

(A) True

(B) False

Answers

(1) Late 1970s… (2) 40-60%   (3) Index  (4) True   (5)  An en dash  (6) No  (7) 1st and 3rd sentences are in active voice

(8)  Yes  (9) Print View  (10) True

The Mug of Joy

The audience had 5 minutes to answer the questions. The sheets were shuffled, the answers were displayed on screen, correct answers were counted, and the best effort was 9 correct answers by Priya, a technical writer at National Instruments at Bangalore.

Priya won a Mug of Joy

I am back from the First STC India Summit in Bangalore and I attended a few interesting sessions. Here, I shall share my own presentation that I gave on Starting a Technical Documentation Services Company. My objective was not to present or discuss how to run a technical documentation company, or how to write a business plan, or how to prepare balance sheets or cash-flow statements. The basic objective was to deal with the confused state of mind–whether to start your own company, when it is the right time for it, and when it is not.

As I shared the contents of this presentation in my previous blog post, the basic outline of what I talked is as below.

• Starting a new technical documentation (or any business for that matter) is a lot like raising a child.
• We meet an entrepreneur who is a successful businessman in 2013, and is a happy and proud father.
• The reasons of NOT planning a child, and for NOT starting your own technical documentation company can be very similar (slide 5 and 6). It was four years back, in 2009.
• Two years later, the reasons for saying YES to both–the baby and own company, are again similar.
• How it is different for an employee as compared to a freelancer (slide 13).
• How the approach of raising a baby corresponds to running your business in initial years.
• And few other points on starting your own technical documentation company.

I have shared it on slideshare, please access it at: http://www.slideshare.net/vingar/starting-a-technical-documentation-company.

This presentation will also be added to STC India’s portal in a few days, Please see it at: http://www.stc-india.org/stc-india-presentations/ in few days.

At the end of presentation. I conducted a short QUIZ of ten questions on technical writing. This was part of STC India’s initiative to hold a technical writing quiz every month, started in February 2011. The questions sheets were distributed and the lady who had most correct entries is Priya, from National Instruments, Bangalore. She won a Mug of Joy.

I shall welcome your thoughts on my presentation on ‘Starting Your Technical Documentation Company’.

For the first STC India Summit, in Bangalore next week, I have a presentation on *Starting a Technical Documentation Company*.

What I plan to present, includes:

• Why (and When) to start a documentation company
• Why (and When) NOT to start a documentation company
• What you need (Preliminary checklist)
• Some pointers or lessons
• The fun, fulfillment, challenge, rewards

What I SHALL NOT present, includes:

• How: Technical details such as how to write business plan, to prepare balance sheet, or to prepare documentation plans
• Lifecycle: The lifecycle of an organization

The summit promises some really interesting topics. See the agenda at: http://www.stc-india.org/2011/04/summit-agenda/. If you have not registered yourself for the summit, please register at: https://spreadsheets.google.com/viewform?hl=en&formkey=dDl3SER0LW1oV19hdnV3Qm16cUNnRnc6MQ&ndplr=1.

When I will come back from the summit, I shall share the presentation here on this space.

Cheers!

Few months back, I came across an excellent post on how to handle difficult candidates (interviewees). This week, I got fresh experience with a professional whom I would classify as a difficult applicant. For such individuals, nothing is wrong of course with their individuals self but something certainly wrong with their professional self.

I posted an advert on TWIN, for a freelancer technical writer position, in 2009. Of the ~30 applications that I received, all professionals had two to eight years of experience and had worked with reputed employers in India. However, I was taken aback to see the number of mistakes in their resumes. It was painful. Not that I expected something extraordinary in their skill-set or technical expertise, but a resume document without mistakes is absolutely crucial for me.

Note: I cannot understand how an *experienced technical writer* can afford to apply with a pathetic resume document!

Candidate 1: One of the candidates (whom I declined politely) asked me for the reason why I did not consider him. I was tempted to tell him that the resume had so many mistakes (at least 20 when I counted). When asked to highlight some issues and to help him correct those, I sent him an email and he was delighted to see my feedback. I got a note of thanks from this learning professional.

Candidate 2: For that advert, I said NO to another technical writer from Delhi and she again approached me for some freelance work, in April 2010. Her resume was poor and I declined citing other reasons.

She again sent me an email this week (April 2011) that she had 6+ years of experience and is working with a leading MNC in Noida (Near New Delhi), as senior technical writer. I saw her latest Resume that she sent this time, and it is awful.

No disrespect to this professional but since she has tried to contact me for 3^rd time in 18 months, I replied her as below.

I was shocked to see her response. Her response (or reaction?) is as below.

I wondered how I am wrong, by giving her feedback when she was making her 3rd attempt to work with vhite, in last 18 minths.

Is she a part of society itself, where feedback is least required? And Thankless.

I replied it calmly as:

 

If you are curious to see what could have been wrong in her CV, see below.

I repeat the Note: I cannot understand how an experienced technical writer can afford to apply with a pathetic resume document!

Any comments on how ELSE I could have handled it?

PS: In my next post, I shall cover: “How important it is for a technical writer (or documentation specialist, information developer) to have a good and clean resume, while applying for an open position. (This does not include focus on resume writing skills.)”

I have responded to the basic law of nature, and vhite has undergone a change. The vhite website is live in new design, and the change is for better. I have stuck to my original principle of website – simple, clean and professional.

For the new theme, the green color makes me feel as part of the community that is moving towards ‘Go Green’. In addition, I have added work samples to give you a glimpse of our technical documentation works. I offer my thanks to my associates and friends for their support and suggestions.

vhite wishes a happy and fruitful year 2011 for you. We look forward to technical documentation trends and challenges in 2011.

A Quick Recap on 2010

The year 2010 was an interesting one as we got chance to develop documentation for products in mobile surveys technology, real estate CRM, SOPs for a healthcare product, a couple of white papers on social media, functional and technical specifications for a huge ecommerce, and many more. I take this opportunity to thank our customers for their trust and cooperation all the way, and for helping us add value to their business, products or vision.

This would not have been possible without consistent efforts of our writers; thanks team for the great job!

Some highlights that punctuated our documentation journey are:

• Diversified into developing video tutorials for products
• Helped three professionals learn technical writing and they earned a certificate
• Used collaborative authoring on wiki for a client
• Attended the STC India Chapter Annual Conference in New Delhi

Promises and Commitment for 2011

While the year 2010 gives us a chance to reflect back and to feel good about what we did, the new year brings its own challenges. As always, we raise the benchmark with each milestone and promise the same–commitment to quality, be receptive to change, and strive for excellence.

In addition, we are looking forward to meet industry stalwarts, when we attend STC and tekom conferences.

Happy New Year 2011
The vhite Team

As I had posted earlier about my experiences at STC India Annual Conference 2010, I resume it with ‘Interactive PDF Designs Workshop’.

Among many sessions that I attended at STC India Conference 2010, one on tools was on ‘Designing Interactive PDF forms’. The speakers were Samartha V and Vikrant R, from Adobe India, and they organized a perfect session. Participants had laptops to design the PDF forms in real time, while following their instructions.

Vikrant started the session interestingly, asking us (the participants) what we expected from that session. I think it was a beautiful way to know audience expectations so that they could channelize their session, and they did it magnificently.

Samartha has got this topic published in the IEEE library, you can access it at: http://ewh.ieee.org/soc/pcs/index.php?q=node/1879.

The detailed presentation version of that session is available at: http://www.slideshare.net/samarthavashishtha/make-the-most-of-pdf-forms.

I recall that two weeks before the conference, I needed to design a fairly long and interactive Certificate form in PDF, for BioCollections Worldwide Inc. (a business based in Miami). We struggled to put it right that time and while sitting in this STC session, I wondered how easily I could have done it. The ‘What’ and ‘How’ of session matched very well, a thoroughly enjoyable experience it was.

Since technical writing is primarily writing about technology, it keeps on changing and evolving. A technical writing services provider works for different businesses across the continents and industries, so it is important to keep our eyes and ears receptive to cross-cultural challenges.

There are times, when we are developing documentation for a client in France, one in Korea, another one in Denmark and one more in Australia. It brings a lot of diversity in the documentation process, since businesses have different priorities and preferences, and different levels of expectations from vhite.

The products keep on changing and the documentation can be as varied as developing functional specifications for a portal that is as huge as comparable to eBay, writing a white paper on leveraging social media, or developing online user guide for a real estate CRM.

The vhite work culture ensures that we adapt to these diverse requirements well, and each of our *artworks* is different and maps exclusively to the way a business expects it.

First thing

Technical writers have a quick meeting for a recap of what was done a day before and what is scheduled for the current day.

Ever evolving

One of our technical writers, after she had developed two online user guides during her first four months at vhite, asked me “This is just repetition of what I have been doing for four months. Will there be no change in what I do here?” The writer had missed an important meeting in the past where we had talked about *evolving in what we do*. We called up a coffee table meeting and discussed a few scenarios.

Case 1: For the source files of an online user guide, we used links to the social media tools of its business website. The idea was greeted well. Apart from procedures and instructions, every page of that guide has links to the social media pages.

Case 2: For a real estate CRM, the screenshots of system were large in size and a few help topics showed horizontal scroll bar when seen in internet browser. We used image thumbnails and linked these to corresponding enlarged images. The reward was words of appreciation.

Such work culture keeps us evolving, and raising the bar for next job.

I work best at *this* time

Individuals plan their own best time for specific tasks, as they know best when they are *in the zone*. If documentation review is more productive and accurate during 1500 hrs to 1700 hrs, or if 0900 hrs to 1200 hrs is the best time to write instructions, we plan it accordingly.

Individuals always remember why they work. It is the *joy of working as a technical writer*.

Call for tea, coffee or salad

When a poorly written instruction is rewritten and it still looks poor in sentence structure, or when the fingers are moving slow on keyboard, or the list alignment continues to misbehave in HTML, we take a break.

Not a kitkat but a cup of coffee, or a plateful of salad, or flavoured lassi.

Documentation and value system

No organization can isolate its value system, from whatever they do. Our value system is:

• Process: Follow the process and enjoy the process
• Respect: Respect yourself and respect others
• Excellence: Commit to excellence, always
• Harmony: Build harmony and ensure harmony

We would rather not write an instruction as…

Click on the PUBLISH THE SCHEDULE button. The jobs for the selected period are marked as published, and employee get the notifications based on the notifications parameters. (See [setup job notification parameters]<Reference to the page> for more details.)

…since *Please* is as important as the instruction itself, as below.

Click on the PUBLISH THE SCHEDULE button. The jobs for the selected period are marked as published, and employee get the notifications based on the notifications parameters. (Please see [setup job notification parameters]<Reference to the page>for more details.)

Pizza. Fried Rice. Curry

A self-defined roaster ensures that individuals happily lay lunch for the team, and clear the table.

Checklist. And Smile

A checklist helps us to ensure  job well done. Some boxes ticked. To-Do list updated, timesheet updated, dishes at right place, printer switched off, windows locked. With a Smile.

Not *always* technical writers

The vhite technical writers respond well to documentation challenges but they are not *always* writers. While watching a movie, we can easily ignore the inconsistent alignment of text in the movie sub-titles. Similarly, we overlook the white space before a semi-colon on a hotel parking sign-board.

Just like normal humans do. Just as non-technical non-writers do.