[Tfug] [OT] Thinking about getting an online degree

[Harry McGregor]

Bexley Hall wrote:
> --- On Sat, 12/27/08, Harry McGregor <micros at osef.org> wrote:
>
>   
>>>> Knowing people and knowing how to write tends to help the most.
>>>>         
>
> I think the former (i.e., contacts) is the stronger of the two.
>
>   
>> Oh, and to add to that, the Federal Government won't
>> look at you unless you are either too good for the position, 
>> or can lie through your teeth.
>>     
>
> (sigh)  Do *not* lie on your resume or in an interview.
> It is just *too* easy to catch people doing this.  And,
> even if you land the job, it can be used to summarily
> dismiss you at a later date when the truth comes out.
>   
I agree entirely, but also don't sell yourself short, if you have done
something, it should be listed in some way, shape or form.  Previusly, I
did not work with SANs in a major way, but I have worked with a few FC
and iSCSI sans here and there.  Listing that got me the contacts for my
current position.

I was honest with them in what I did, when and where, and that I would
need to brush up my SAN skills a bit, but was more than up for the
challenge.
> I've caught many job applicants in bald-faced lies.
> Usually, misrepresenting what they have done (i.e.,
> claiming to have done something when, in fact, it
> was someone else who "did" it -- their involvement
> was peripheral, at best).
>   
Same here
> Note that their are rules (laws?) over what a previous 
> employer can/will disclose to a prosepective new employer.
> But, those rules do not apply to your "work-mates"
> (though one still has to be wary of libel).
>
> Some industries are very small, tight-knit groups.
> "Everyone knows everyone".  So, it is easy to make a
> call "off the record" and get The Straight Dope on
> a prospective applicant without going through "formal
> channels".  I've done this, often, to catch people
> misrepresenting themselves and/or their accomplishments.
>
> Also, in more technical fields, it is not uncommon to
> "test" an applicant "on the spot".  Usually not a tough
> question but, rather, one that shows how the person
> approaches a problem and how well they think on their feet.
>   
Yes, and these are wonderful for both sides of the hiring.
> So, you might be asked to design a little circuit or
> hack together a simple algorithm.  The followup questions
> are most important:  "How would you *improve* what you
> have just done (admittedly, under pressure)?"  This is
> good for catching people who are aware of your firm's
> testing policy and come prepared with "canned answers".
>
>   
>> To make it to the local hiring managers, you have to answer
>> every question on the application perfectly.  Any sign that 
>> you can't answer every question perfectly, and you don't 
>> make the list sent on from HR.
>>     
>
>   
In this case, they had two programming related questions on a
System/Network admin job application.  While it is a good idea to ask
peripheral questions to see how rounded the applicant is, it's a bad
idea to refuse to let the applicant into the pool, as they did not
answer "very knowledgeable" to a non-primary question.
> (sigh)  I had a cousin who was a big shot at a large
> multinational (fortune 100) firm.  I recall him boasting (?)
> to me that he wouldn't hire someone if their fingernails
> weren't clean; or, their shoes weren't polished; etc.
> At the time, this seemed assinine (it still does!).
> But, from his point of view, he is inundated with
> hundreds of applications for a particular job.  He can
> apply any sort of litmus test he deems appropriate to
> "thin the herd".  In *his* mind, appearance was a
> simple test to enforce  :<   (arguably, if someone
> isn't willing to invest the time in proper "presentation",
> then how serious are they about the job??)
>
>   
>> As a hiring manager, I think that's nuts.  You need to
>> evaluate each person's pluses and minuses, and figure 
>> out the best fit for the position.
>>     
>
> That's a laudable goal -- but I think the practicalities
> of most hiring situations result in many artificial and
> arbitrary (see above) criteria being imposed.  *Hopefully*,
> the person doing the hiring/evaluation is at least *aware*
> of any of these arbitrary criteria he/she may be imposing.
> Subconcious prejudices are considerably harder to identify.
>   
In the case of the federal hiring system, the people making the first
level of cuts have no idea about the job or it's requirements.  They are
evaluation if you answered "perfectly" for each question.  Only the top
5 or top 10 applicants actually make it to the hiring committee.

Thus if you do a proper "spread" of questions to catch the peripheral of
skills, you end up limiting your options to either people or just
answered "perfect" all the way down, no matter what the question, or
someone who is over skilled for the position.  Neither case is very good.
>> Working for the University used to have some semblance of
>> stability to it, now the Regents are pushing towards
>> "centralized" IT for "cost savings".  All of the possible 
>> cost savings will be made up by the time
>> it takes to figure out how to do this, and then the
>> "underground" IT infrastructure that will arise out of the ashes.
>>     
>
> This is common wherever "rules" are put in place (bean counters,
> etc.).
>
> I wrote a contract many years ago.  We were trying to sort out
> how we (the supplier) would provide "spares" to our customer
> (client).  "Minimum order quantities", "preapproved subassemblies",
> etc.  The client made a very astute observation:  "Let's just
> play it by ear; if we (client) start asking for things that
> get to be too tedious/costly for you (supplier) to provide
> (e.g., asking to purchase a single *screw*), you can just
> start quoting us insanely long lead times to discourage these
> sorts of requests -- we'll get the message without having to
> argue about the details of the existing contract, etc."
>
> His point:  when you make a rule, you just give people 
> something that they have to work-AROUND!
>
>   
>> Instead of pushing for centralized IT, they need to improve
>> and reduce the cost of centralized services, and get departmental
>> IT to buy into them.
>>     
>
> Treat IT as a cost center.  Let them price/sell their services.
> Let departments "go outside" for services (this isn't always
> practical).  This keeps pressure on IT to keep their
> organization "lean" and efficient.
>
> I always chuckle when groups are faced with budget cuts, etc.
> (e.g., as the city/county are, currently).  They invariably
> come up with *something* to trim from the budget.
>
> My question is:  why couldn't you have trimmed this when
> "times were good"?  (of course, this is a superficial argument
> but it tries to highlight the fact that groups tend NOT to
> be as efficient as possible unless they *have* to be)
>
> <shrug>  I'll leave the soap box for the next participant...
>
>   
                   Harry
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org
>