From: D Yuniskis on
Hi Joerg,

Joerg wrote:
> What I find sad is not the lack of knowledge since that can be fixed.
> What is sad is the lack of interest to invest the effort, in getting to
> know complicated stuff.

*This*, IMO, is the real problem. To many, "it's just a job
(paycheck)... a way to get money to do what you *really* want to
do (tweet your friends at all hours of the day/night)". There
is an "engineering mindset" that seems to have gone away.
These folks could just as easily be accountants or BEE KEEPERS.
They aren't motivated by the challenge but, rather, by the
paycheck -- "How little do I have to do in order to get paid?"

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' :-/ )
From: Jim Thompson on
On Mon, 19 Apr 2010 13:29:24 -0700, Joerg <invalid(a)invalid.invalid>
wrote:

>miso(a)sushi.com wrote:
>> On Apr 19, 12:40 pm, Joerg <inva...(a)invalid.invalid> wrote:
>>> Nico Coesel wrote:
>>>> Joerg <inva...(a)invalid.invalid> wrote:
>>>>> Nico Coesel wrote:
>>>>>> chris w <ch...(a)smartjack.com> wrote:
>>>>>>> I've been interviewing a few new BSEE graduates for a junior engineer
>>>>>>> position, and based strictly on what we're looking for, here is some
>>>>>>> random advice to juniors/seniors:
>>>>>>> Get some experience with current microcontrollers. I have a
>>>>>>> preference for Microchip, but Atmel or an ARM variant would also be
>>>>>>> good. I know teaching the 68HC11 still has value, but knowing parts
>>>>>> Most of the basics are still the same.
>>>>>>> Networking is important. Lots of new products these day have some
>>>>>>> connection to the Internet. Understand TCP/IP and ethernet. MAC
>>>>>>> addresses, netmasks, ARP, default routes, NAT... Even getting into
>>>>>>> the upper layers might be good, especially HTTP.
>>>>>>> Linux would be nice to know. Embedded Linux continues to grow.
>>>>>>> Knowing how to compile a linux kernel, build a file system, or
>>>>>>> whatever would be a useful skill.
>>>>>> Engineers who know about analog design, programming, digital circuitry
>>>>>> (programmabe logic / FPGA perhaps), Linux and networking are very very
>>>>>> scarse. Usually an engineer masters a few areas. The biggest challenge
>>>>>> is to put a good team together.
>>>>> I never had a problem putting teams together. BUT, the average age of
>>>>> such teams was usually well over 40. Companies that think that everyone
>>>>> over 35 is past prime are going to face one project failure after another.
>>>> I agree altough its nice to have some youngsters around. We have some
>>>> interns working at my employer at the moment. They usually come up
>>>> with interesting ideas and new methods. One of them brought quite a
>>>> handy logic analyzer:
>>>> http://www.zeroplus.com.tw/logic-analyzer_en/products.php?pdn=1&produ...
>>> Oh yeah, young people have fresh ideas and we also have an obligation to
>>> groom the next generation. It makes no sense if we design cool stuff,
>>> some day end up in a nursing home and then ... poof ... it's all gone.
>>>
>>> What frustrates me at times is how quickly young folks give up when they
>>> don't immediately understand a circuit. Once I had an intern sit in on
>>> one of my design reviews. From the facial expressions it became clear
>>> that the other guys (none of them being from the analog world)
>>> understood the stuff but the intern absolutely didn't. So afterwards I
>>> offered to explain in detail, and that I wouldn't bill the client for
>>> the time that would take. The answer was "no thanks, this stuff is way
>>> over my head" :-(
>>>
>>> --
>>> Regards, Joerg
>>>
>>> http://www.analogconsultants.com/
>>>
>>> "gmail" domain blocked because of excessive spam.
>>> Use another domain or send PM.
>>
>> Now that is sad, but you have to realize they don't teach much analog
>> these days. Even classic control theory is glossed over for digital
>> control. The problem is some systems (amplifiers for instance) need a
>> knowledge of classical control theory.
>>
>
>This was a switcher. A bit unorthodox but not complicated, in essence
>regular PWM stuff.
>
>I know universities are letting people down these days when it comes to
>analog know-how. However, back when I was a kid at around 15, a TV
>technician in our ham radio club offered to teach a crash course on how
>a color TV works. About two dozen signed up, half of them under 20. We
>sat there with wide open eyes, gobbling up all the info, asking
>questions, and so on. He was an excellent teacher, I understood the
>stuff, and from then on felt comfortable repairing color TV sets.
>
>What I find sad is not the lack of knowledge since that can be fixed.
>What is sad is the lack of interest to invest the effort, in getting to
>know complicated stuff.

Around 1970, I couldn't find a technician to hire. Offered to teach a
course for free at Scottsdale Community College. Declined. Even
though I already had my MSEE, I had no teaching certification :-(

...Jim Thompson
--
| James E.Thompson, CTO | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |

The only thing bipartisan in this country is hypocrisy
From: Joel Koltner on
"Jim Thompson" <To-Email-Use-The-Envelope-Icon(a)On-My-Web-Site.com> wrote in
message news:s7gps5l9fl8ornafs62qdov5m8fvc8j2cu(a)4ax.com...
> Around 1970, I couldn't find a technician to hire. Offered to teach a
> course for free at Scottsdale Community College. Declined. Even
> though I already had my MSEE, I had no teaching certification :-(

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?:-)


From: Jim Thompson on
On Mon, 19 Apr 2010 13:51:13 -0700, "Joel Koltner"
<zapwireDASHgroups(a)yahoo.com> wrote:

>"Jim Thompson" <To-Email-Use-The-Envelope-Icon(a)On-My-Web-Site.com> wrote in
>message news:s7gps5l9fl8ornafs62qdov5m8fvc8j2cu(a)4ax.com...
>> Around 1970, I couldn't find a technician to hire. Offered to teach a
>> course for free at Scottsdale Community College. Declined. Even
>> though I already had my MSEE, I had no teaching certification :-(
>
>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?:-)
>

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

...Jim Thompson
--
| James E.Thompson, CTO | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |

The only thing bipartisan in this country is hypocrisy
From: Nico Coesel on
D Yuniskis <not.going.to.be(a)seen.com> wrote:

>Hi Brent,
>
>brent wrote:
>> Good advice.
>>
>> Personally, I would not be so concerned with how to use a particular
>> software package but would make sure of three things:
>>
>> 1. Did they have proper exposure to theoretical courses in college?
>
>That's usually easy to verify.
>
>> 2. Can they think. This is hard to quantify, but ultimately , it is
>> the most important thing.
>
>Agreed. I'm not a fan of "tests" in interviews. Having

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

>There are myriad "simple problems" that you can pose that
>don't *act* like "tests" yet allow you to examine the
>individual's thought processes *and* attitude -- is he/she
>intimidated by a problem being thrust into his/her lap or
>does he/she relish the challenge, etc.
>
>I like seeing how people can adapt to problems from the
>"wrong" perspective (e.g., thinking outside the box).
>Do they dismiss the problem as "unsolvable"? Do they
>bombard me with "Why would you want to do that?" (which
>I see as a stalling tactic -- "Why do *I* have to justify

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.

>I would add:
>
>4. Try to assess their honesty.
>
>I am frequently disturbed by how often folks pawn off
>the works of others as their own. It's fairly obvious
>when you ask them *probing* questions about some of
>their claimed "accomplishments" -- and they can't come
>up with the "details".
>
>I once had an applicant proudly present a "listing" of
>one of his "programs" under the pretense that *he* had
>done it. After looking at the code and recognizing the
>product in question, imagine his surprise when I asked
>him, "What part of this did <John Doe> do?" (naming the

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

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico(a)nctdevpuntnl (punt=.)
--------------------------------------------------------------