Advice to BSEE juniors and seniors...
in [Design]
|
Prev: History of communications
Next: Women + Laptop + Coffee cup + Kids + Ball + Hairdryer = Bad situation =D
From: Joel Koltner on 19 Apr 2010 15:21 "Jim Thompson" <To-Email-Use-The-Envelope-Icon(a)On-My-Web-Site.com> wrote in message news:hr8ps5t1uog0l4gpnj7gc83cl302jgv47j(a)4ax.com... > In the past I've had companies assign a junior engineer to look over > my shoulder and "learn" from me. > > Utterly clueless, "Why'd ja do dat?", etc... never EVER done any > creative thought on their own, no useful math background... :-( I would think a better approach would be... hand the junior engineer some completed and documented design, have him study it, and then ask him if there's anything he didn't understand?
From: Joel Koltner on 19 Apr 2010 15:31 "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote in message news:o32zn.383064$Hq1.37642(a)en-nntp-04.dc1.easynews.com... > I would think a better approach would be... hand the junior engineer some > completed and documented design, have him study it, and then ask him if > there's anything he didn't understand? [Responding to myself here...] One of the things that often doesn't make it into documentation but that's quite valuable when it does is some discussion of things that *didn't* work. It's great to say, e.g., "this new super-snoot circuit here has a tempco of 0.2ppm, surpressing the spec by almost an order of magnitude" but even better if you can add, "the approach we used on the last project, which seemed as though it would be a 'copy and paste' into this one, didn't work because it turns out that this process only has P-well transistors and the performance is awful, simulations indicating we'd miss the spec by a factor of 2" or whatever. The real problem when one is beginning is that you really don't know what you don't know -- the vast bulk of circuit "design" at school is done using rather ideal parts at room temperature.
From: Joerg on 19 Apr 2010 15:40 Nico Coesel wrote: > Joerg <invalid(a)invalid.invalid> wrote: > >> Nico Coesel wrote: >>> chris w <chris(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&product_id=93 > 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.
From: miso on 19 Apr 2010 15:49 On Apr 19, 9:10 am, Joerg <inva...(a)invalid.invalid> wrote: > Joel Koltner wrote: > > Good stuff, Chris, although I'll make a few comments... > > > "chris w" <ch...(a)smartjack.com> wrote in message > >news:a841c586-06cc-4829-be64-3db1227ae18f(a)11g2000yqr.googlegroups.com... > >> I > >> think you're much more likely to use something like Altium than Spice > >> or Matlab (which are also good to know). > > > This depends largely on just what kind of engineer you think you want to > > be. For many digital guys, yeah, SPICE and Matlab don't get much use... > > but for analog guys, SPICE is obviously quite common. Matlab is more > > for, e.g., DSP guys, although I think the analog guys can also save time > > at least using, e.g., MathCAD. > > It always amazes me how many companies run huge simulations on <gasp> > Excel. And it works. Many have built up such a large arsenal of models > and routines that they will most likely never switch to anything more fancy. > > >> Which brings me to my next suggestion-- do some hobby projects on your > >> own. > > > Yes, absolutely. > > >> Learn how to solder. > > > ...unless you really want to be strictly a software guy... :-) > > I am not all that fond of SW guys who aren't able to use the basic > functions of a scope or a solder iron. Just like I think they have a > right to expect me to know how loops work and be able to change little > things in there in a pinch. > > > Oddly, I've worked at places where the "engineers" were strongly > > *discouraged* from picking up a soldering iron because, "we have techs > > for that." ... > > That would be a concern. > > > ... Yeah, and there was a time before word processors where > > writing up a memo used done by chief engineers either because "they had > > secretaries for that." > > I remember that, at my first job. But pretty soon our module specs > became so large that the secretary just couldn't handle the load. But we > still had to share three computers in the basement to write our stuff > and do the CAD. Bought myself an XT for home so I could at least write > my module specs whenever I wanted to. > > >> Get some experience with current microcontrollers. > > > I tend to agree, even for analog-types, if only in that hybrid > > digital/analog systems are ubiquitous today. > > Often it suffices to know the innards of a uC, but know them real well. > Then you can tell the uC programmer exactly what sort of architecture > you want. And if others have the uC under their responsibility and you > request a precious resource such as a timer on there or even just one CC > register be prepared to "contribute". Large bag of trail mix for the > guys, or something. > > >> Networking is important. > > > Well, if your job involves software, yeah... you again seem to be > > heavily leaning towards people wanting to do embedded digital stuff here... > > Also for HW guys. It's good to know where you can find a good layouter, > uC programmer or C programmer. All I have to do is pick up a telephone > or email :-) > > >> 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. > > > OK, knowing how to compile a linux Kernel is something I suspect that > > *well* under 1% of currently practicing engineers could do for you -- > > you're starting to get pretty nichey here. > > I haven't seen Linux to be important at any of my clients, in decades. > It's all Windows, and if they needed a hardcore realtime OS it was > something professional such as QNX. IMHO Linux knowledge doesn't buy > that much for a HW engineer unless it means that he or she acquired > programming know-how that way, know-how that's useful elsewhere. > > -- > Regards, Joerg > > http://www.analogconsultants.com/ > > "gmail" domain blocked because of excessive spam. > Use another domain or send PM. The optimizer in Excel is quite clever. You can set up the target to be dynamic, i.e. a function of the last optimized solution. I used this once to create an arithmetically symmetric bandpass filter. I would force one half of the bandpass to match the other half, i.e. make the target for one side be the result for the other side. Obviously this was a multi-stage design since a 2nd order bandpass has to be geometrically symmetric. Note the optimizer isn't part of the standard Excel installation. It is the only thing I miss in open office.
From: miso on 19 Apr 2010 15:52
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. |