Re: interviewing tips

[John Posada <john -at- TDANDW -dot- COM>]

Guys...relating to this interview thread, which couldn't be timed better
with what I have going on at my job.

An interesting situation happened this Wed evening as I was walking out
of the door (I had my coat on, in fact).

I had mentoioned to one of the department managers a couple of days ago
that I noticed in the programmer's weekly department status report that
a particular program had been upgraded to a new release and deployed on
the servers.  Understand that I came on about a month ago, there was NO
formal document process, and I've been trying to track down all of the
documentation floating around, and I haven't even scratched the surface
yet.

Anyway, the manager told me that this particular program belong to
"Matt".

Now, Matt is as geeky as they come.  If I spent 10 hours per day juts
writing code for UNIX servers, I'd be pretty geeky too.

Anyway, as I'm passing his cube, I mention to him that I'd like to get
10 minutes of his time next week to discuss the changed to the program
so I can update my document (only about 7 pages).

His response was that "he didn't see any purpose to having documentation
for this program (or any internal program was the implication) because
it changes so often that any information about the program is just sent
around to all of the developers by email."  (Oh, boy...this one is going
to be fun)

My response, which resulted in about 30 minutes of discussion why
documentation was necessary BECAUSE of the changes and some alternatives
that could accomplish what I need without work on his end...like simply
add me to the email distribution list that is used to notify his peers
of these changes.

However, some time in the middle of the conversation, he mentioned that
he'd written a tool to solve a particular problem in using the program
and that he hadn't deployed it yet. I didn't say anything about it at
that point, but mentally filed it away.

Later in the conversation, I brought up the subject of his utility and
why it hadn't been deployed. His response was that he hadn't made it
available yet because he had to write the instructions on how to use it
and he hadn't done that yet.

Who says Christmas doesn't come in November.

To make a long story short, he called up from his terminal and emailed
to me a change history document on the program, I have an appointment
next week, and I'm going to help him write his instruction on using his
utility for use by all of the other programmers in the company.

The moral of the story.  Keep your ears open for anything that may be
discussed during a conversation that you can use to leverage what you
want by doing something for the developer that wasn't in the original
job scope.



M. Dannenberg wrote:
>
> In an episode of Northern Exposure, Fleischmann says: "If you want to
> catch fish, you have to think like a fish." If you want to catch geeks
> you have to think like a geek. A large part of any geek training
> consists of stuff like "this is algorithm A, this is algorithm B.
> Compare them and say which one's better". The answer is usually "it
> depends on your application". Another all-time favoured is comparing
> programming languages, like "what are the performance issues when
> comparing C to C++", etc.
>
> The more geeky your questions are, the more inclined the geeks will be
> to answer them. If you ask "what's a method?" the geek will groan and


John Posada, Technical Writer (and proud of the title)
The world's premier Internet fax service company: The FaxSav Global
Network
-work http://www.faxsav.com     -personal http://www.tdandw.com
-work mailto:posada -at- faxsav -dot- com  -personal mailto:john -at- tdandw -dot- com
-work phone: 908-906-2000 X2296 -home phone: 732-291-7811
My opinions are mine, and neither you nor my company can take credit for
them.

HEY! Are you coming to the NJ TechWriter lunch?  So far, about 10 of us
are.
Ask me about it.

	http://www.documentation.com/, or http://www.dejanews.com/