what does "documenting expeirence" mena?

duing the telephone interview, they asked if i have experience in "documenting". who can tell me in detail what kind of work this is?

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

EdTheLad

madonion wrote:

duing the telephone interview, they asked if i have experience in "documenting". who can tell me in detail what kind of work this is?

Creating inventory lists,network diagrams, training documents all this kind of stuff.

Plantwiz

ed_the_lad wrote:

madonion wrote:

duing the telephone interview, they asked if i have experience in "documenting". who can tell me in detail what kind of work this is?

Creating inventory lists,network diagrams, training documents all this kind of stuff.

Not to overstate it:

http://www.answers.com/documenting&r=67

Depending on the type of work, Ed is correct. Creating a 'paper' trail of stuff.

JDMurray

Documentation is writing information down on paper that other people will need to use, possibly be made publicly available, and will probably be archived. Exactly what you will be documenting depends on the type of job you were interviewing for. If documentation is a significant part of the job, you may be asked to take a writing test.

the_return_of_the_Ring

thanx for the anwears. but i'm still a bit confused, is it improtant enough to ask this as an inverview question? i mean, hey, it's documenting something that will be useful for future. You just do as the company policy requires, do you need experience? what's difference between senior and junior? is it skillful?

Plantwiz

Likely it will mean the difference between how well one reads and writes English. Their use of Grammar/Spelling and their ability to be concise, yet through.

It probably won't need to pass Lawyeresse, but getting things close should be a plus.

JDMurray

If the company does not have a technical publications department to edit all of the docs produced by the employees, then it's likely what ever you write will be the final documentation. In this case, a business would really want people who are better than average at descriptive writing.

And yes, it's a perfectly reasonable interview question, even to an interviewee who won't be doing much writing other than emails. (Poorly written public emails reflect on the reputation of a company.) At one time, writing was a skill that everyone possessed, but it's just not that important to many learning institutions anymore. Hence, people with poor writing skills are now commonplace in the workplace.

TheShadow

If they bothered to tell you then I think jdmurray' last post is the closest to correct. When I actively worked as a design engineer, one of the things that you had to do was document your work in sufficient detail to be used for design reviews, transfers of information for the real technical writers, and review by the patent department. So basically here is what you did, this is why you did it and here are the trade offs for doing it some other way.

Ask yourself if you set up a server room or a small network could you document it sufficiently so that someone could understand what you did with few or no questions.

garv221

jdmurray wrote:

And yes, it's a perfectly reasonable interview question, even to an interviewee who won't be doing much writing other than emails. (Poorly written public emails reflect on the reputation of a company.) At one time, writing was a skill that everyone possessed, but it's just not that important to many learning institutions anymore. Hence, people with poor writing skills are now commonplace in the workplace.

Yes, its annoying reading emails like that.

forbesl

jdmurray wrote:

Hence, people with poor writing skills are now commonplace in the workplace.

I would add they are also quite common in the forums!

Danman32

I certainly could answer 'Yes' to such a question. In my last job, even if 8 years ago, we had to write status reports to the next shift, and the CIO had us write policy/procedure documents, as well as change requests. I get pretty detailed in procedures. We hated the change requests (let's just do it already!), but it did prove valuable, as we had to document what we would do if the change blew up in our face. Much of the time the answer was to do a restore but other times we had a less intensive backout plan, such as copying existing unmodified files out for safe keeping.

Even in this job I document what I told the client to do to fix their problem.