Advice to BSEE juniors and seniors...

Unfortunately, I don't know how much of that is a generational perspective -- did my folks say that about *my* generation? (though I seem to remember people my age could at least 'make change for a dollar' :-/ )

"Jim Thompson" wrote in message news: snipped-for-privacy@4ax.com...

Very dumb on their part.

I wonder how many newly-minted BSEEs today would pass muster as the kind of tech you were looking for 40 years ago?:-)

A test is a good way to determine the level of knowledge and experience of an applicant. See your statement about assessing honesty below.

I guess I never work for you. I always ask those questions to get rid of idée fixes. IMHO its part of thinking outside the box and getting a good grip on all the (hidden) requirements.

Major deja-vu here :-) We often have a good laugh about a certain person who was hired as a programmer (this person is actually the reason we are using tests nowadays). In the end we let him equip the test room. We asked him to make a plan first though. His plan consisted of two lines of text:

- Order materials

- Wait for materials to arrive

Very damn few, from what I see... even coming out of MIT :-( Zombies exhibit more enthusiasm and creativity :-) ...Jim Thompson

Thats something to keep an eye on. I just had one of the interns chase a problem on a digital board. In the end it turned out to be a problem in a connector (much to my surprise as well!) but it was an interesting problem. It does take some coaching to guide someone through a fault-finding process.

The fairly recent version I have (2.3.0) and also a newer one does have some support. But it doesn't run all of it. The help file explains how to parse for basic lines that have been disabled and need to be re-written. That can end up in a lot of grunt work. Considering that older MS-Office licenses aren't terribly expensive I rather shell out the dough :-)

My (previous) point exactly. It really is just a job, and a contract job at that. Not a career.

Where is the incentive to hone the engineering mindset, if by all accounts, your next project employer won't care?

Yep, red tape. Credentials and all that non-essential stuff. If someone wouldn't have the skills to teach a class he would hardly apply, or at least wouldn't last. I've never really understood what good that does, and probably never will. Probably good old turf protection.

ts

her.

..

I must admit, waaay back in the day, for the life of me I could not understand how a four-quandrant multiplier worked. I knew how to test it, and tell when it wasn't working, but to say I truly understood it -- nope. Still not sure I do, honestly. (?) It was an IC we used in a video application. Would have been 1985-ish?

The Sr. Engineer did exactly as you say. He handed me some materials, and a working circuit, and pointed me to the corner for awhile. I guess I just had a total mental block, because we finally gave up. It was enough (for the intern position I had at the time) to just be able to detect when things weren't working. Did not really NEED to know precisely why.

-mpm

in

of

=A0 =A0 ...Jim Thompson

=A0 =A0| =A0 =A0mens =A0 =A0 |

=A0 | =A0 =A0 et =A0 =A0 =A0|

=A0|

=A0 =A0 =A0 |

An MIT-grad friend of mine told me the other day that MIT doesn't even have a straight EE program anymore. You must specialize in communications, or software, or whatever.

I guess i is the new e.

iPad, iPhone, i[blank]

eMail, eTrade, eHarmony

Maybe we should trademark all the other vowels now, sit back, and wait for future royalty checks?

It's been that way for quite some time. I.e., 6.1 was "classic EE", 6.3 was "CS", 6.2 was something like "bioelectronic" (?)

However, the core curriculum shared by all "course 6" ensures that a 6.1 grad can still write code and a 6.3 grad can design an amplifier...

I've been in the business for >35 years (though probably half that working with PCB sorts of things) and have never done layout and will likely never do it. Not that I couldn't learn or that I don't want to, just never any reason to. There's always someone else (cheaper) to do it.

Agreed. Where's the beef?

With a rookie this is often the problem, though. It's also the reason they pay experienced engineers more. IMO, if you don't have time to hand-hold you shouldn't be hiring a rookie.

Agree here too. The ones who really want to do the work enjoy talking about what they did and how they got there. The good ones can defend the choices, too.

I think you'll find it's the other way around.

A lot of large companies don't hire contractors for this reason. If they do, they hire the hiring out to a meat market to make *sure* they aren't tagged with the contractors being regular employees. I know the few times we hired a contractor we had to pay another 20%, or so, on top of all the taxes, just so we would never pay the contractor directly. We even put the contractor and "employer" together and only funneled money through one to the other.

IBM paid for advanced degrees and usually gave time off for engineers to take classes but there was no promise of a raise or promotion upon completion of a degree. There rarely was either for engineers. Tecnicians would often be promoted to engineer upon receiving a BSEE, though.

re

e*

ng,

some

egular

re

ps...

ths

rary"

d this

ng for

ey do,

ed

hired a

t so

and

hool

ing

- I

le

e she

bees

n she

take

of a

en be

I would hope so

We use Bugzilla too. Not a Linux machine in the place, though.

You mean you need an iMax to go with your iPad?

I don't know if it can be taught, but it can certainly be strangled at birth by too much empty praise and too much entertainment.

Ever since I was a kid, I haven't been able stand to be unclear in my mind about things I care about--it affects me like having a pebble in my shoe. I also am not satisfied by making up something plausible...I have to kick all four tires good and hard, and am still on the lookout for reasons that I might be wrong about it.

I remember wanting to build a tube-type audio amplifier (about 1970, when I was about 11) and while I could wire one up correctly, I couldn't figure out how to design it, and that made me *nuts*. I went away and read and thought, and after awhile I could do it. (Most of the reading was data books and app notes, plus various ARRL handbooks.)

That attribute and a lively curiosity has taken me to some pretty interesting places in technology, among other things. If you have a kid that refuses to give up, don't entertain him, challenge him.

Cheers

Phil Hobbs

Hmm, might be, I don't really know.

Yes, HP did this -- there was one firm in town that was effectively captive to HP. (I think they did fill positions for a few other employers as well, but the thing was that if you wanted a temp job at HP, there was one and only one firm where you'd sign up as a temp.)

That's pretty much how it was with my master's -- work paid tuition, but it really had no impact on my salary (which was fine by me at the time).

Hopefully they'd promote some of the really good techs who were clearly capable of doing engineering work to engineering positions as well, regardless of their academic background.

---Joel

My point was that you can pose problems without the pressure of a "test" situation. I have found many people "freeze up" when confronted with something that is *obviously* a "test". OTOH, those same people when presented with "problems" in a more casual setting can demonstrate lots of ability.

Give a problem that has lots of -- relatively easy -- answers. See how they approach it. See if they settle for the first answer they come up with. See if they can critique their own "solution", etc.

I.e., once *an* answer (which is not incorrect!) is out there, the "pressure" is released. Now see how they can deal with

But, in business, you don't always have access to all the "hidden" requirements. When I grill clients like this, it often becomes too threatening. *They* know what they want. (unless they *don't* -- in which case, that is usually said "up front" and the reason for my hire). Often, I can be made privy to some market research. Very often *not* informed of longer term strategic goals ("insider information" :> ).

As an *employee*, I found many managers threatened by this approach. "Cuz I'm the boss!" attitude. It's too easy for "Questioning" to turn to "Skeptical" then "Obstructionist" and eventually, "Disgruntled".

The *best* teams I have worked on/with are those that *implicitly* trust each other's abilities. No need to quiz each other on the "why" -- unless something looks *really* wrong (in which case, the person questioning often ends up chagrined at some issue that he/she was completely ignorant of). In these environments, you can concentrate on doing what *you* need to get done without worrying about whether your partners will do their jobs correctly, interfere in your job, etc. Very exhilarating when N different subsystems meet for the first time on a lab bench and actually *work* together! :>

Makes one wonder how good he is at *testing*! :