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.
Most job interviews are more like a frat-house rush party than a serious
negotiation. The interviewee talks about the joys of hard work. The
interviewer talks about tremendous "growth opportunities". Everyone
smiles a lot but half-truths abound. And when all is said and done, all
is said and done - you still don't really know what your in for until
you start.
In 17 years of interviewing in the software industry, I have only found
one way around all this nonsense. I ask to see the requirements
specifications for the product. If you know what to look for, you can
obtain more info in 1/2 hour studying them than you could otherwise by
interviewing days for the job. What do I look for?
1.) Do they have any specs? If they do not, or are unwilling to let me
look at them, I know I am dealing with a very immature organization.
2.) Are the specs big and thick with tons of confusing text that
discusses a lot about HOW the software works but very little (if any)
about WHAT the software does from an end users's perspective. This is
the hallmark of a mediocre organization.
2.) Do the specs employ Data Flow Diagrams and/or Entity Relationship
Diagrams? This is what you want to see - these are signs of a mature
organization. But be aware! Many times the DFDs and ERDs (or any other
graphical technique) within a spec are meaningless. Superfically they
may look OK, but upon further analysis, they don't make sense. If they
are any good, you should be able to understand them in one sitting. If
you can not, it is not your fault. Often, these are included in the
spec not to convey requirements but to demonstrate to management that
the analyst has been a good little boy/girl and has done his/her
homework.
Tony Markatos
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com