Advice to BSEE juniors and seniors...

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?

1. Can they think. This is hard to quantify, but ultimately , it is the most important thing.

2. 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.

That's usually easy to verify.

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)

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:

1. 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 do?" (naming the actual designer of the product -- "Oops! I bet you weren't expecting to encounter someone who *knows* andn is familiar with *his* work...?" :< )

1. 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.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Absolutamente! Don't go out on the web asking if someone has the footprint for the xyz gizmo. Make it.

If hardcore analog design is (part of) the goal I think the candidate should know SPICE inside and out. LTSpice is very good, and free of charge from the LTC web site.

Seriously, I have diagnosed tough field failures where the underlying spikes were next to impossible to measure with any reasonable equipment. Either because they were too faint or because they only happened once in a blue moon. SPICE showed it. Sometimes this was met with skepticism by client engineers but miraculously the field failures were gone after changing the circuitry.

[rest snipped, all very good advice]

Now I wish some decision makers at universities would read your post because that would soon double the design productivity in our country ...

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

I like the idea of a new Jr. hire knowing Altium or whatever, because I'm not likely to assign a task that involves heavy-duty circuit analysis right off, but PCB design and some simple circuit design is probable.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

I have an even better suggestion for soon-to-be EE grads... Go back and switch your major to medicine or law.

In today's job market, you're probably lucky if you can land a career in what I like to call "serial-contract-employment".

It used to be an EE was your ticket to a rewarding career with a well- known firm, rock-solid job security and juicy retirement benefits. Nowadays, every teenager with a PlayStation-3 knows more about the latest and greatest than you ever will. And that little doo-dad technology changes every 15 minutes. You can't hope to keep up.

Well, maybe if you specialize in the right niche, or perhaps, venture out with your own consulting firm. (Very few of whom will actually hire green engineers as consultants.) Then there's all the Indians and Pakistani's vying for what few jobs there are.

At best, you'll work your ass off in some mid-level engineering job only to be outsourced or downsized. 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. Times have certainly changed!

Assuming the candidate is from a decent college this shouldn't be a big problem.

Assuming a design job (not all are), can they design. Have they? Show me.

Except that I want them to pay to get their car fixed. I want them *here* solving my problems. ;-)

I'd been on so many interviews where they didn't give a test that I didn't even prepare myself for a test, until my last one. The other engineer gave me a bunch of analog circuits to analyze, even though they wanted a digital guy (I've done nothing but analog since I've been there ;). I was kinda set back on my heels, but did alright. It would have been an easy "test" if I'd expected it. Maybe I was tired, too (didn't get in until 2:00AM and didn't have anything to eat since the previous noon). Every other interview, since the interview from hell, in college, asked what I'd designed and how it worked (and, of course, *my* responsibilities).

Yep. That's how I always interviewed candidates. 95% of the interviews I've been on have been the same. I loved interviewing because there was always a challenge and something to learn (The Kodak high-end ink-jet printer interview was a lot of fun).

Even better if some holes are left open and let them ask for them to be filled in.

Not really. Engineering is all about how things work, even non-design positions.

You'd hire SkyDuck? ;-)

Yep. Nothing else is as important.

Check references, too.

Oops!

Depends on whether you have one trick to solve or you're looking for a generalist.

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.

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.

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".

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.

-chris

These are good indicators of many of the other issues:

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.

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

Like this:

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!

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.

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.

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.

ild things - figuring out how things work.

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.

a).

/014311746...

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".

Well, there are many things that I *know* I can't "fix". But, that doesn't stop me from poking around inside to see how things *work*. I.e., "It's already broken, what have I got to lose??"

OTOH, I also have a history of taking things apart that

*aren't* broken -- *yet*! :> My father enjoys retelling stories of how I "broke" his 3 day old car as a child by defeating the interlocks that prevented the electric window from being raised while the door (tailgate) was open -- and swearing that he was never able to get the rattle out of that door as a result. :-/

I don't think it even has to go that far. I.e., he needn't be expert (or even *competent*!) in all those fields. Rather, he should at least be *conversant*. He should be able to understand the *types* of issues that those around him are facing (mechanical engineers, industrial designers, etc) and able to see how *his* field and skillset could be brought to bear on solving or *morphing* their problems to more manageable solutions.

E.g., I was involved in the design of a printer that employed thermal dye transfer technology (basically, a sheet "ribbon" that was coated with ink-impregnated wax which was selectively melted and then fused to the paper). Detecting "end of ribbon roll" was being done with an optical switch. This posed a problem for the user as he would have to thread the ribbon through the optical switch when replacing the ribbon.

Another individual on the team was designing the "take up motor" drive system (constant torque on the ribbon). In our weekly review, I pointedly asked him:

- "What would happen if the load on the takeup motor eased?"

- "My servo drives the motor harder until it 'felt' the same load" - -

- "And, if the load disappeared entirely?"

- "The servo would drive the motor to the limits of the supply *looking* for that same 'feel'"

- "So, if the ribbon were to deliberately fall off the *supply* spool -- say, AT THE END OF RIBBON -- then all we have to do is wait for your motor to start freewheeling to sense that fact... which we can do with a simple comparator looking at the drive voltage across the motor..."

I.e., I was responsible for neither the mechanical design of the switch nor the electrical design of the takeup motor yet could bring some insight to bear on how the two could be related.

Too many folks tend to become "expert" in just one discipline and never get the vision to see beyond. "If all you have is a hammer, then everything looks like a nail".

There are some firms who give time off regularly for folks to pursue outside interests (well, not really time *off* but, rather, time when you don't have to be working on your "assigned" project). Some folks advocate taking a year off every decade or so (!)

We spent the night dining with a guy who makes fine furniture (oriental look) by hand (no power tools). Exquisite designs. All are "gifts" (non-commercial). Interesting to see how he decides what to make, how to "finish" it, etc.

Apparently, many of the "standards" that we (I) grew up with in school are no longer present. E.g., math, science, "english" and phys ed every year. American history every two years (world history other years). "shop"/drafting. Even the "art"/music classes.

I wonder how kids actually *do* occupy their days? Note how many can't make change for a dollar :<

Cool! I'm hoping to get my niece and nephew involved in replacing their kitchen sink, fixing the damage to the ceiling and tuckpointing their chimney (I suspect my sister will complain about that last -- since they're only 8 years old and it's a long way to the ground from the chimney! :> )

*Your* challenge will be to see what sorts of possible uses your grandkids might conceive of for that forge!

things - figuring out how things work.

When I was 6 or 7, I fried my first "crystal set".

"How can I make this thing LOUDER? Hmmm... two wires coming out of it. Two *holes* in that wall socket. I wonder... Mom, can you come here for a minute?"

Good stuff, Chris, although I'll make a few comments...

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.

Yes, absolutely.

...unless you really want to be strictly a software guy... :-)

Oddly, I've worked at places where the "engineers" were strongly *discouraged* from picking up a soldering iron because, "we have techs for that." 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 tend to agree, even for analog-types, if only in that hybrid digital/analog systems are ubiquitous today.

Well, if your job involves software, yeah... you again seem to be heavily leaning towards people wanting to do embedded digital stuff here...

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.

---Joel

You're probably right about this, although keep in mind that some applicants might have already had experience with customers where there's often a huge difference between what they initially *ask* you to do and what they *really ned*. Asking, "why would you want to do that?" can help to ferret out what they *really* want and make for a much better working relationship (although the phrasing could certainly be better). Indeed, I'd be quite leery of any engineer who just goes off and takes a customer request completely at face value if some of the specs included are very challenging/time consuming for no clear reason. (Remember what they tell you about the GRE? "Hand questions have hard answers?" -- It's kind of the same way, "Hard engineering tasks should be due to having an actual hard problems!")

:-) I recall a resume where a guy claimed to have extensive experiences with "Xylinx FPGAs." Um hmm. Sureeeee you did...

---Joel

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.

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 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.

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.

---Joel

It always amazes me how many companies run huge simulations on 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.

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.

That would be a concern.

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.

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.

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

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.