TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:How To Interview For a TW Job From:"Anthony Markatos" <tonymar -at- hotmail -dot- com> To:mbreinha -at- us -dot- oracle -dot- com, tonymar -at- hotmail -dot- com Date:Mon, 27 Sep 1999 15:13:48 PDT
Tony Markatos said:
Unfortunately, about ninety-eight percent (98%) of all companies are at CMM
levels 0 or 1. And it is impossible to get real respect in such companies.
Mary Reinhardt asks:
In relation to most companies being at a level 0 or 1 on the Capability
Maturity Model (CMM), my question is, how can you tell from the outside what
level a company is at in their documentation processes?
Seven months ago when I was graduating from a master's program in tech
writing and interviewing with numerous companies, I tried to ask questions
about processes, audience analysis, etc. aimed at figuring out what level a
prospective employer was at. The problem was, 99% of them gave answers that
would have put them at a level 2 or even 3.
Any suggestions for interview questions which let you know exactly what type
of environment you're in for?
Tony Markatos responds:
The vast majority of job interviews are more like a frat-house rush party
than a serious negotiation. Even when the applicant is serious (which you
obviously were), it is almost impossible for the company to be.
THE APPROACH TO TAKE IN JOB INTERVIEWING
1.) Realize that you can ask questions forever and never find out what it
is 'really' like within a company. Been there. Done it.
2.) Realize the truth in the old saying 'the first steps are the hardest'
(and the most important). In software, the first step is analysis. All
other processes are dependent upon the output of the analysis phase; if the
analysis was conducted poorly, it is impossible to implement effective
processes downstream (in design, testing, and documentation).
3.) Ask for about 45 minutes to review the output of the analysis effort
for the software product you will be working on. (This animal is often
called a Software Requirements Specification.) If they have not started
analysis, ask to see the output of the analysis effort for a similar
product. (Within a given company, the quality of the analysis seldom varies
from project to project.)
4.) If the analysis output (i.e., the spec) has true value, a computer
novice should be able to study it for about 45 minutes or less and gain a
fairly rigorous understanding of the essential tasks that the system is to
perform and how all of those tasks interrelate (unless, the system is truly
monstrous). You want to gain an understanding of WHAT the system does
(i.e., what end user goals it supports) not HOW it does what it does.
5.) If you find a company having analysis output of such quality -- go to
work for them! Don't ever leave them! If they have not currently
implemented a set of formal processes for design, test, and documentation,
doing such is relatively straight forward.
6.) Unfortunately, very few software companies produce specs to the quality
mentioned in Step 4.) (above). In considering the others, it is a matter of
how bad are things. Can you at least get the gist of the essential tasks?
If so, than it is a better than average company. The worst cases: totally
unreadable or even no formal analysis analysis output is produced. These
are your Level 0 and 1 companies.
CLOSING REMARKS - The Importance Of Process Maturity
I started my corporate working career back in the 80's at Hughes Aircraft
Company. I was fortunate to be a member of a small team of software
professionals who were really gun-ho on Structured Systems Analysis
(SSA)techniques. SSA techniques are implemented through a set of rigorously
defined processes. I lead projects in which we were very successful with
these techniques. I learned that once you have experienced the joy of high
productivity only possible by working within the constraints of defined
processes, going back to the old (ad-hoc) way of doing things is very
depressing.
Tony Markatos
(tonymar -at- hotmail -dot- com)
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com