Advice to BSEE juniors and seniors...
in [Design]
|
Prev: History of communications
Next: Women + Laptop + Coffee cup + Kids + Ball + Hairdryer = Bad situation =D
From: miso on 20 Apr 2010 01:42 On Apr 19, 6:51 pm, Joerg <inva...(a)invalid.invalid> wrote: > Phil Hobbs wrote: > > 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. > > Much more dangerous: Entitlements and pampering to the hilt. When I > needed anything fancy in electronics I had to work my butt off to be > able to buy it. Meat factory and similar pleasant jobs. Today's kids get > cell phones, TVs, gadgets, even whole cars with doing anything. So often > they just don't do anything. > > In hindsight I am thankful to my dad that he did not simply plunk down > $400 so I could buy a used ham radio transceiver. I had to earn every > penny of that in a factory during school break. There was a clear > choice: Having fun and not being able to buy the thing, or working and > being able to. > > > 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.) > > With my first tube amp I made a hole in the ceiling plaster. Found out > the hard way there there is such a thing as ESR for capacitors. Of > course, I absolutely had to have the biggest honking tube amp the town > had ever seen and at around a kilowatt one of the electrolytics decided > to take a hike. I could only afford 15 of those and I guess that was a > bit skimpy. > > > 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. > > Certainly true. > > -- > Regards, Joerg > > http://www.analogconsultants.com/ > > "gmail" domain blocked because of excessive spam. > Use another domain or send PM. The only problem with ARRL text is they are not all that disciplined. AM sort of equals double sideband in their book. Little stuff like that annoys me.
From: brent on 19 Apr 2010 07:00 On Apr 19, 1:08 am, chris w <ch...(a)smartjack.com> wrote: > On Apr 18, 5:40 pm, brent <buleg...(a)columbus.rr.com> wrote: > > > Personally, I would not be so concerned with how to use a particular > > software package but would make sure of three things: > > Agreed, but it seems most of the candidates we talked to couldn't > layout a PCB. The ability to read a schematic, understand a BOM, > navigate Mouser/Digikey/Newark/* to select parts, layout a simple pcb, > and assemble prototype boards all seem like things someone with a BSEE > should be able to do. > I agree. Regarding the PCB, in our company the electrical designers are comfortable with the design aspects of circuit layout, but we have specialists that actually do the layouts because there are so many details to getting a board truly correct that it is a job specialty in itself. > > 1. Did they have proper exposure to theoretical courses in college? > > In general, I would rather hear how they used what they learned in > classes to build things to know they took a DSP class, or two digital > design classes. I'll take for granted they took the theory-- now tell > me if you tried to apply it to anything. > > > 2. Can they think. This is hard to quantify, but ultimately , it is > > the most important thing. > > > 3. Do they Building things - figuring out how things work. > > Everything from their car to how an appliance works. They must have > > the "I'll be dipped if I would pay someone a dime to do something I > > can figure out myself" attitude. > > Great points. I've too often worked with that certain someone who had > to be shown every step. I want to be a team player too, and if I'm > really stuck, it's great to have someone to bounce your problems off > of, but sometimes you just want to say, "I've barely got time to do my > job, let alone yours too". > The whole team player thing is a tricky one. Most good engineers are more self reliant in their approach to things, which makes them not so good at team stuff, and yet the team stuff is important. > With an entry level engineer, I think it's usually pretty easy to tell > how good they are at problem solving by asking the probing questions > about their projects. I haven't resorted to any sort of "test" > questions. > I have a question. I am in a company that does not have all that many entry level engineers so I don't know, but my question is: Are the younger engineers beating their heads against the lab bench to get their stuff to work for the first five years or so of their careers like it seems we had to? I sense they are not. > -chris
From: brent on 19 Apr 2010 07:04 On Apr 19, 4:30 am, TerryKing <te...(a)terryking.us> wrote: > These are good indicators of many of the other issues:>> 3. Do they Build things - figuring out how things work. > > Everything from their car to how an appliance works. They must have > the "I'll be dipped if I would pay someone a dime to do something I > can figure out myself" attitude. > > >>5. Try to assess how "multi-dimensional" the applicant > > is. Is he/she a "one-trick pony" who will help solve some > *particular* need of your organization? Or, can he apply > ideas from one technology/area to other areas to give you > "future benefits" as your needs evolve. > > I believe all the really interesting and challenging designs / > projects are multidisciplinary. I would ask, "If we need you to do a > design with some analog, digital, microcontroller and probably DSP > components, applied to an area that you have no background in, such as > real-time analysis of Volcanic Ash and Smoke from an airplane, how > would you go about learning about the new area?? > > I'd want to hear a mixture of online, database, library, usenet, PLUS > "I'd walk down the hall and talk to people and ask their advice". > They have to be able to personally CONNECT, not sit in an office. > > And I'd ask, "What did you build yourself when you were 10 years old? I would have answered that I can tell you all the stuff I broke by the time I was ten : A microphone, A television set, a speaker, and I blew out a transformer by putting a switch in my radio to turn the light out at night (I simply shorted the bulb out - haha) OK, I was building plastic models I guess. > What did you learn on your own when you were 12 years old? What stuff > did you drive around and buy when you were 17 years old? If you had 4 > weeks off to do some personal project, what would it be? > > I'd ask, If you come up with a proposal for a solution, and some one > says, "You're just naive about this", is that Good or Bad?? > > Sigh.. Last night I led a meeting to organize a "Community Workshop" > group at a huge new University in the Middle East (http://www.kaust.edu.sa). > Like this:http://kcomm.wikispaces.com/CommunityWorkShop > > Not too great a turnout.. And where were the enthusiastic guys from? > The guy who had spent a day searching through Jeddah, with no Arabic, > finally finding 4 shops with actual component-level parts and chips: > (Bangladesh). The guy who showed us intricate wood carvings, with > real artistic merit: ( Pakistan). The guy who is building MEMS > motors, but waiting for that critial machine: (Britain). The guy who > is laying out and ordering installing all the core Lab equipment, CNC > machine shop, Glass Shop, etc. who is forcing machines through Saudi > customs, marking the mounting holes on the floor, asking us what CAD > software we want on the lab computers: (China). > > Which country removed the shops from most of it's high schools in the > 90's, reallocating those resources to Computer Literacy, with classes > labeled "Technology" in which our sons and daughters learn how to use > Microsoft Office. (USA). > > GGrrrrr..... > > This Summer I'm building a metalworking Forge with my Grandchildren... > > PS: READ THIS!http://www.amazon.com/Shop-Class-Soulcraft-Inquiry-Value/dp/014311746...
From: brent on 19 Apr 2010 07:07 On Apr 18, 7:40 pm, D Yuniskis <not.going.to...(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 > said that, I *do* heartily believe that you can pose a > problem to an applicant (even if that problem *looks* > like a "test" -- write a routine that does... design a > circuit that does...) and then ask them to explain their > solution. See what criteria they used to come up with their > solution. Ask them how they could improve upon it. Ask > what it;s strengths and weaknesses might be. Etc. > > 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 > an approach to you? *You* are the one being tasked with > the problem" -- and possibly indicative of someone who will > grumble later about some "decision from management" and > not give 100% towards trying to *meet* that goal) > > > 3. Do they Building things - figuring out how things work. > > Everything from their car to how an appliance works. They must have > > the "I'll be dipped if I would pay someone a dime to do something I > > can figure out myself" attitude. > > This is a special/different breed you're trying to identify, > here. It may not be necessary for the position that is > being filled. > > OTOH, I am seriously impressed by folks who do (or think > about) things that are *out* of the ordinary. E.g., don't > try to impress me with a digital alarm clock that you > *assembled*. Rather, show me how you used some OTS parts > to design a clock that counted *backwards* -- and, tell me > *why* you felt the need to do so! > > 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 > actual designer of the product -- "Oops! I bet you > weren't expecting to encounter someone who *knows* > <John> andn is familiar with *his* work...?" :< ) > Agreed. A real engineer cannot be a BS'er. It is important to screen those guys right out. > 5. Try to assess how "multi-dimensional" the applicant > is. Is he/she a "one-trick pony" who will help solve some > *particular* need of your organization? Or, can he apply > ideas from one technology/area to other areas to give you > "future benefits" as your needs evolve.
From: D Yuniskis on 19 Apr 2010 08:32
Hi Brent, brent wrote: > On Apr 18, 7:40 pm, D Yuniskis <not.going.to...(a)seen.com> wrote: >> 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 >> actual designer of the product -- "Oops! I bet you >> weren't expecting to encounter someone who *knows* >> <John> andn is familiar with *his* work...?" :< ) > > Agreed. A real engineer cannot be a BS'er. It is important to screen > those guys right out. I just don't understand why they would even *try*!? E.g., if you are discussing something "abstract" (art?), you can handwave and be imprecise. You can avoid being pinned down because often the concepts involved are too subtle to express definitively. But, with engineering, its *all* about the details! You can't just say, "We kinda did this..." without being able to show what *exactly* "this" was. And, *why* you did it. Over the years, I've talked with lots of employers and found that this is actually a common problem in hiring; folks misrepresenting themselves (even on things that are *so* easily verified -- like school attended, etc.). (sigh) I guess it's a calculated gamble? "Maybe they won't question me too thoroughly..." I recall one employer (*post* hire) discussing a patent with me (in a field which he knew me to have some "alleged" experience) and how to avoid infringement thereon. He was taken aback when I lectured him on the independant claims made in that patent (from memory) and how, exactly, to work around them. ("Yes, I *do* know the things I claimed to know..." :> ) I think, nowadays, misrepresentations are easier to catch. I know of firms that do complete background checks on prospective hires. And, savvy employers will exploit the smallness of the (their?) Industry to find folks who know the individual personally (or, friends of friends) to obtain information that can't be garnered oficially from "Personnel". |