Advice to BSEE juniors and seniors...
in [Design]
|
Prev: History of communications
Next: Women + Laptop + Coffee cup + Kids + Ball + Hairdryer = Bad situation =D
From: brent on 19 Apr 2010 19:11 On Apr 19, 7:08 pm, "k...(a)att.bizzzzzzzzzzzz" <k...(a)att.bizzzzzzzzzzzz> wrote: > On Mon, 19 Apr 2010 09:06:17 -0700, "Joel Koltner" > > > > <zapwireDASHgro...(a)yahoo.com> wrote: > >"mpm" <mpmill...(a)aol.com> wrote in message > >news:11c6a47c-5162-49bf-8fc0-5fc1ebe50b40(a)z11g2000yqz.googlegroups.com.... > >On Apr 18, 5:32 pm, chris w <ch...(a)smartjack.com> wrote: > >> Well, maybe if you specialize in the right niche, or perhaps, venture > >> out with your own consulting firm. > > >Yes, analog and RF are your friends here. > > >And there's actually plenty of demand for *good* digital/embedded software > >guys, it's just that there are so darned many out there, and the *average* > >quality is so low, that many companies just start outsourcing, contracting, > >etc. > > >> Put simply: Electrical Engineering has become project based. > >> Companies bring on a team of engineers, and dump the whole lot of them > >> when the project is over. > > >Not universally true, by any means, although it'd be interesting to find some > >statistics on what percentage of U.S. EEs are "serial contractors" vs. regular > >employees. > > >I suspect that it's the large companies that go for serial employment more > >than the little ones. > > I think you'll find it's the other way around. > > >I used to live in Corvallis, Oregon where the largest > >private employer is HP, and a very large chunk of the employees were temps... > >they did this dance where they could only work for something like 10 months > >and then had to be off for 2 months or somesuch to maintain their "temporary" > >status. Some of the temps (especially the younger ones) actually liked this > >arrangement, but the older ones/those with kids/etc. were constantly vying for > >the limited number of permanent positions that would come up each cycle. > > 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. > > >HP also had some interesting ideas about "continuing education" -- in school > >(Oregon State University), there were a lot of HP employees who were taking > >classes to "advance" their careers, yet seemingly HP sometimes only cared > >about people getting a degree and not what they were actually learning -- I > >had a project partner in an antennas class (we built a classic Kraus-style > >helical antenna) who was a marketing manager for ink, and I'm pretty sure she > >would have been just as happy learning about the mating cycles of honey bees > >with their exploding testicles and all as she was about array factors and > >elemental dipoles... but she was motivated by the promise of a raise when she > >finished the degree. > > 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. I would hope so
From: krw on 19 Apr 2010 19:13 On Mon, 19 Apr 2010 11:05:27 -0700, Joerg <invalid(a)invalid.invalid> wrote: >mpm wrote: >> On Apr 19, 11:30 am, "Joel Koltner" <zapwireDASHgro...(a)yahoo.com> >> wrote: >>> "Joerg" <inva...(a)invalid.invalid> wrote in message >>> >>> news:833dkfFhu1U1(a)mid.individual.net... >>> >>>> I haven't seen Linux to be important at any of my clients, in decades. >>> That might say more about the kind of people who use Linux than about Linux >>> itself. :-) >>> >>> Heck, John is using Linux these days... we use Linux at work for, e.g., >>> Bugzilla (but not for anything embedded yet -- a few of us hardware types >>> wanted to, but for some odd reason the software guys think they want to use >>> Windows CE...)... it's (by far) the most popular platform for web servers on >>> the Internet, etc. >>> >>> That being said, if you pick the right versions of Windows (say, XP or Win >>> 7 -- *not* Vista, ME, etc.), it works just ducky too. There are various pros >>> and cons of each, depending on just what level you're designing for. >>> >>> ---Joel >> >> Unless I were applying for a software game-development type job, I >> think I'd have a huge hangup about even mentioning the word >> "zilla" (in all its assorted falvors) in any job interview >> situation. :) >> >> Probably just me, though.? > > >Nah, no problem. Companies use programs such as Filezilla, it's normal. We use Bugzilla too. Not a Linux machine in the place, though. > >> Beyond my obvious disdain for the practice, zilla to me sound a bit >> too reminiscent of the dot-com bubble. >> Just put a dot-com on the end and investors will throw money at it. >> So, just use a "z" in your company or product name and viola': instant >> mystique. > > >To say it in teen-speak, that's sooo last week. The rage today is >"i-something". Got to have it, or you may be considered a geezer. You mean you need an iMax to go with your iPad? <...>
From: Phil Hobbs on 19 Apr 2010 19:49 mpm wrote: > On Apr 19, 2: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.- Hide quoted text - >> >> - Show quoted text - > > 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 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 -- Dr Philip C D Hobbs Principal ElectroOptical Innovations 55 Orchard Rd Briarcliff Manor NY 10510 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net
From: Joel Koltner on 19 Apr 2010 19:58 <krw(a)att.bizzzzzzzzzzzz> wrote in message news:03ops5l5e81o45bvk4djqautck2v9je4jr(a)4ax.com... > On Mon, 19 Apr 2010 09:06:17 -0700, "Joel Koltner" > <zapwireDASHgroups(a)yahoo.com> wrote: >>I suspect that it's the large companies that go for serial employment more >>than the little ones. > I think you'll find it's the other way around. Hmm, might be, I don't really know. [HP using temps] > A lot of large companies don't hire contractors for this reason. 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.) > 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. 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). > There rarely was either for engineers. Tecnicians would often be > promoted to engineer upon receiving a BSEE, though. 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
From: D Yuniskis on 19 Apr 2010 20:06
Hi Nico, Nico Coesel wrote: > D Yuniskis <not.going.to.be(a)seen.com> wrote: > >> brent wrote: >>> 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. 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 *that* answer without feeling as if they are having to defend it or as if it was "their grade". >> 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. 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! :> >> 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 <frown> Makes one wonder how good he is at *testing*! :< |