Orchid XP v8 wrote:
> Darren New wrote:
>> Personally, I'd leave "bright" in there. You'll have to decide. :-)
> OK. Fair enough.

For my thinking, it's telling them something about how you see yourself. 
Certainly if you put "dedicated" or "loyal" or something in there, it 
would be saying something else.

>> "Learned Tcl/Tk in a week" is misspelled.
> 
> Damn. Now I have to figure out why it's misspelt...

My copy says "leaned Tcl/Tk."  Unless *I* misread it. :-)

> Heh. You really do enjoy subtly implying that I'm more important than I 
> really am, eh? ;-)

That's part of what you have to do.

> How about "rigourous recording of changes"?

Good.

> Soft systems are warm, fuzzy things that are ill-defined. The kind of 
> thing where figuring out exactly what you're trying to do is usually the 
> hard part.

Uh, OK. Never heard that term. Maybe it's a British term. 
"Underspecified" might be the term I'd use, but again you take a look 
and decide. It just struck me as odd.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On 21-Nov-08 21:47, Orchid XP v8 wrote:
> andrel wrote:
> 
>> Better.
> 
> That's usually a good start...
> 
>> I am still missing the games group you are in. At least I suppose that 
>> is a hobby of yours.
> 
> Didn't seem highly relevant. (I suppose you could attempt to pretend 
> that this illustrates teamworking or social skills or something... but 
> mainly it involves shooting things!)

It does illustrate that you are not the social inept moron that you are 
trying to pretend. Remember: they asked you to be on the team. You even 
met IRL and you were not thrown out immediately. (The reason they asked 
nor the reason why they keep up with you does matter, so don't give your 
version in a job interview).

>> Tcl/Tk is in point 5 but not in 3.
> 
> It's in point 2 though.
sorry missed that. That is probably a good sign.
> 
>> If you would apply for a job more in my field then you may tell a bit 
>> more about what your company does. 'policy and procedure documents' 
>> are one thing, but for work in a medical lab you may be much more 
>> qualified than most.
> 
> Our lab doesn't do diagnostic stuff, only quantitation.

irrelevant IMO, our lab is in a constant transition to more regulation 
(partly because of the hype of the time and partly because the type of 
research is changing) you seem to know at least partly what kind of 
regulations are out there *and* you know how to implement such measures. 
  If someone here notices that they might even create a job description 
for you just to get you in. Pity you seem to be stuck in that hole in 
the UK.

> (Actually, all the mass spectrometers say "NOT FOR DIAGNOSTIC USE" on 
> them in big lettering. I'm not sure why... Presumably if you want to do 
> diagnostic work, they sell you an identical machine for 12x the price.)

I know a company that does do the labeling and the reason is simply that 
they a) don't want to get sued for misdiagnoses because their system 
happened to be in the same room. b) they are a small company that can 
not afford expenses associated with the testing. and c) their 
administration of the development and production is not even remotely 
resistant to an medical grade audit. Not everybody can afford an Andy, 
you know.

Post a reply to this message

Orchid XP v8 wrote:
> OK, so I *think* I've taken nearly everybody's suggestions on-board. 
> What do we think of this then?

One more comment by the way.  Nowhere does it actually say "Windows", as 
far as I can remember. You might want to mention you administered AD, 
and that some of your scripts were work-arounds for design flaws in 
roaming profiles, for example.

(What, you think nobody remembers what you complain about? :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On Fri, 21 Nov 2008 20:48:12 +0000, Orchid XP v8 wrote:

> Jim Henderson wrote:
> 
>> "Troubleshooting" is a good general term for this, or "problem
>> diagnosis and resolution".
> 
> Troubleshooting is the term I'd go with.

It's a good one; "problem isolation" is another that I've seen.

Jim

Post a reply to this message

On Fri, 21 Nov 2008 23:00:59 -0500, Jim Henderson wrote:

> On Fri, 21 Nov 2008 20:48:12 +0000, Orchid XP v8 wrote:
> 
>> Jim Henderson wrote:
>> 
>>> "Troubleshooting" is a good general term for this, or "problem
>>> diagnosis and resolution".
>> 
>> Troubleshooting is the term I'd go with.
> 
> It's a good one; "problem isolation" is another that I've seen.

Another that gets attention is "root cause analysis".

Jim

Post a reply to this message

On 22 Nov 2008 00:43:08 -0500, Jim Henderson <nos### [at] nospamcom> wrote:

>On Fri, 21 Nov 2008 23:00:59 -0500, Jim Henderson wrote:
>
>> On Fri, 21 Nov 2008 20:48:12 +0000, Orchid XP v8 wrote:
>> 
>>> Jim Henderson wrote:
>>> 
>>>> "Troubleshooting" is a good general term for this, or "problem
>>>> diagnosis and resolution".
>>> 
>>> Troubleshooting is the term I'd go with.
>> 
>> It's a good one; "problem isolation" is another that I've seen.
>
>Another that gets attention is "root cause analysis".
>
Personally, I'd say fault finding ;)

Seriously, on this side of the Pond. The simpler the word or phrase the better.
I'd rather hire someone who could do a good job rather than talk a good job.

"Troubleshooting" is acceptable but it would be more applied to whole system
problems not individual equipment faults.

I think it's interesting that "fault finding" sounds like a "blame game" to
Darren. Here a phrase like "root cause analysis" would get the CV passed around
so everyone could have a good snigger. Again two countries separated by a common
language :)


-- 

Regards
     Stephen

Post a reply to this message

Orchid XP v8 wrote:
> OK, so I *think* I've taken nearly everybody's suggestions on-board. 
> What do we think of this then?
> 
> (The information about my degree is incomplete and possibly incorrect; I 
> can't seem to find the transcript right now.)
> 
> I've basically dumped in everything that seems remotely relevant. 
> Presumably before I finalise this document I'll need to trim it back 
> down again a little.
> 

Much better.

Many people have further comments about what could be improved.  Some I 
agree with, some I don't.  You decide.

However it is now at the stage where the major improvements have been made.

I'd be much more likely to interview somebody based on this version. 
Your original I would have declined without even reading it all the way 
through.

So, stage 2 - Get applying.

Cheers.

Post a reply to this message

On Sat, 22 Nov 2008 08:32:56 +0000, Stephen wrote:

> On 22 Nov 2008 00:43:08 -0500, Jim Henderson <nos### [at] nospamcom> wrote:
> 
>>On Fri, 21 Nov 2008 23:00:59 -0500, Jim Henderson wrote:
>>
>>> On Fri, 21 Nov 2008 20:48:12 +0000, Orchid XP v8 wrote:
>>> 
>>>> Jim Henderson wrote:
>>>> 
>>>>> "Troubleshooting" is a good general term for this, or "problem
>>>>> diagnosis and resolution".
>>>> 
>>>> Troubleshooting is the term I'd go with.
>>> 
>>> It's a good one; "problem isolation" is another that I've seen.
>>
>>Another that gets attention is "root cause analysis".
>>
> Personally, I'd say fault finding ;)
> 
> Seriously, on this side of the Pond. The simpler the word or phrase the
> better. I'd rather hire someone who could do a good job rather than talk
> a good job.
> 
> "Troubleshooting" is acceptable but it would be more applied to whole
> system problems not individual equipment faults.

See, over here, we troubleshoot everything from system-wide faults to 
individual hardware component failures.

> I think it's interesting that "fault finding" sounds like a "blame game"
> to Darren. Here a phrase like "root cause analysis" would get the CV
> passed around so everyone could have a good snigger. Again two countries
> separated by a common language :)

Ain't that the truth. :-)

"Fault finding" to me does imply "blamestorming" as well - the result of 
"fault finding" is that "it's your fault", so has a very negative 
connotation in most parts of the US IME.

Jim

Post a reply to this message

On 22 Nov 2008 12:05:15 -0500, Jim Henderson <nos### [at] nospamcom> wrote:

>
>See, over here, we troubleshoot everything from system-wide faults to 
>individual hardware component failures.
>

Lordy, lordy you'll have me speaking 'Merican yet. :)

>> I think it's interesting that "fault finding" sounds like a "blame game"
>> to Darren. Here a phrase like "root cause analysis" would get the CV
>> passed around so everyone could have a good snigger. Again two countries
>> separated by a common language :)
>
>Ain't that the truth. :-)
>

Tell me about it!

>"Fault finding" to me does imply "blamestorming" as well - the result of 
>"fault finding" is that "it's your fault", so has a very negative 
>connotation in most parts of the US IME.

I suppose that differentiate it by saying someone is finding fault.
-- 

Regards
     Stephen

Post a reply to this message

On Sat, 22 Nov 2008 23:08:31 +0000, Stephen wrote:

> On 22 Nov 2008 12:05:15 -0500, Jim Henderson <nos### [at] nospamcom> wrote:
> 
>>See, over here, we troubleshoot everything from system-wide faults to
>>individual hardware component failures.
>>
> Lordy, lordy you'll have me speaking 'Merican yet. :)

One by one. ;-)

>>> I think it's interesting that "fault finding" sounds like a "blame
>>> game" to Darren. Here a phrase like "root cause analysis" would get
>>> the CV passed around so everyone could have a good snigger. Again two
>>> countries separated by a common language :)
>>
>>Ain't that the truth. :-)
>>
> Tell me about it!

Well, you see, you're in the UK, I'm in America, we both speak English 
but we can't understand each other.  I thought you understood that, but I 
hope this clears things up a bit. ;-)

>>"Fault finding" to me does imply "blamestorming" as well - the result of
>>"fault finding" is that "it's your fault", so has a very negative
>>connotation in most parts of the US IME.
> 
> I suppose that differentiate it by saying someone is finding fault.

I think the evolution of language, though, means that one who finds fault 
engages in fault finding. ;-)

Jim

Post a reply to this message