Getting a good job

From: Richard Erlacher <richard_at_idcomm.com>
Date: Sun Jul 2 03:58:18 2000

See my remark below, plz.

Dick

----- Original Message -----
From: Eric J. Korpela <korpela_at_ellie.ssl.berkeley.edu>
To: <classiccmp_at_classiccmp.org>
Sent: Saturday, July 01, 2000 3:38 PM
Subject: Re: Getting a good job


> > > We also expect that a PhD should be able to perform any task that
might
> > > require a mechanical, electrical, software or civil engineer, an MBA,
> > > economist, lawyer or priest. They better have learned more in that
extra 4+
> > > years of school than they did in the 16 previous.
> >
> > If you amend that to "...learned more about a very specific topic in
that
> > extra 4+ years..." then I'd agree.
>
> That's not my experience. Specialization is required for the project,
> generalization is required for sucessfully completing it. Perhaps it's
> different in engineering than it is in the sciences.
>
This is what I meant initially when I said the PhD has, at least once,
performed and completed an entire task. Not necessarily so with Bachelors,
or even Masters, though the latter are required to do more with less
direction. While the specialized skills are required to do the job, the
generalized skills acquired in doing an ENTIRE piece of work are rare but
essential. Consequently, it's the PhD's who are chosen to lead, or manage
an operation, simply for their experience in "doing a job" to completion.

Look around your lab or work area at home . . . how many of your homebuilt
bits of apparatus have "real" legends or printed labels for all the knobs
and switches? How many of your projects end up in a box that's screwed
shut? That's where the truth of the matter lies. Everybody has built a
thingie or two that never gets past the wirewrap board even though it's been
used occasionally for 10-20 years. It often starts out as an immediate
need, but ends up as a tool.

I like my tools "finished", i.e. in a sealed box with external knobs that
don't require a screwdriver to operate them. I like to be able to use them
without taking the back panel off another piece of gear to get the power
supply I need. Now, I do have stuff lying about that's never been finished,
but that's just what they are: unfinished. If I build a tool to completion,
you can bet there's documentation. . . particularly for revisions, and the
knobs and switches are documented as well as labelled on the box. Moreover,
the box is complete enough that I don't have to worry about spilling coffee
on it or having parts fall out if I turn it over.
>
> > The principal problem with Ph.D.s is that their knowledge base tends to
> > be as narrow as any other new grads; the only distinction being that
they
> > have significantly more depth in one very specific area.
>
> I disagree.
>
I'm sure there are both types, but my experience has been that the PhD types
are often working far outside their own discipline but are able to handle
the job because of their experience and training. They understand how
difficult it is to get those things done that aren't within your own
specialty. It's easy to design a circuit. Powering and packaging it is
often where the real challenge lies. Designing durable and serviceable
interconnects is not a trivial task either. I haven't seen an HDL for
wiring and packaging.
>
> > I've had more than one occasion
> > where such people were literally reduced to tears in design meetings
> > as a consequence of being crucified by some staff engineer.
>
> I've also seen precisely the opposite where an engineer has been so caught
> up in the way things have been done that they can't understand that there
> just might be a better way or a case where the old way won't work.
>
> > It just means that there are
problems
> > > I can drop in the lap of a typical PhD that would take a week to
explain to
> > > the typical programmer.
> >
> > "...drop in the lap of a typical PhD who is familiar with the problem
area..."
>
> Again I disagree. If a PhD is unfamiliar with the problem area they will
> get familiar with it damn quick. That's what is expected of them. If
they
> don't do what's expected of them, you don't keep 'em around. Then again
an
> engineer who is unfamiliar with the problem area will likely come into
your
> office every hour and a half to ask a question.
>
> > When they were done we tried to find other things
> > for them to do, but they were only marginally more effective than
> > our new crop of four-year grads. The person in question is now making
> > use of their Ph.D. by teaching undergraduate CS courses.
>
> I'm not saying there aren't idiots with PhDs out there. Did you ever
> think that putting the PhDs to work doing the same tasks as the new crop
> of four-year grads was a waste of material? You don't hire a PhD to write
> Visual Basic code, you hire PhD's to do work that you need a PhD for.
>
> > > It's a different skill set, and should be treated as such.
> >
> > I don't see any evidence that the skill set is particularly different;
>
> Perhaps that's because you treat them like fresh undergrads.
>
> > All the Ph.D. represents is an additional four years of training in an
> > environment that is skewed from the one found in industry;
>
> Ph.D. must me different where you come from. Where I come from a Ph.D.
> candidate is not getting much training apart what they provide themselves.
> The biggest difference I see between people in industry and people doing
> their thesis projects is that people in industry work shorter hours.
>
> > It's all about what you can
> > do and how well it fits with my needs. Everything else is meaningless.
>
> Of course, and if you don't need Ph.D.'s working for you, so be it. But
> you might want to consider that the guy with the Ph.D. may be able to do
> quite a bit more than you need...
>
> Eric
>
>
Received on Sun Jul 02 2000 - 03:58:18 BST