The Freshers Interview Guide

• Employment

At Signalogic I'm in hiring mode right now, looking for a couple of entry-level engineers. After several interviews over the last few weeks I find troubling patterns... things young engineers should know, but they don't. Things they put on their resume but shouldn't, things they say or do in the interview they should not, and things they fail to say or do.

Then I see questions for "interview help" on DSP and FPGA tech groups that miss the point, asking about how to do "homework" to prepare for an interview, what topics are "must need to know".

Ok, time for a blog! Maybe I can help some freshers out a little. Or at least I can try.

1) First and foremost, please recognize that as a new BS/MS EE/CS grad or graduate student intern, the plain fact is you don't know much and you won't for a few years. That's just the way it is, no getting around it. Trying to study or "cram" before an interview is a waste of time. You can't go in as "knowledgeable", or relying on "credentials" -- what classes you've taken, what lab projects you did, what research assistantship you had, etc. Your objectives should be to go in ready to show you are a quick learner, organized, prepared to demonstrate your problem solving skills (hopefully you've acquired those during your recent education!), and dedicated to a teamwork philosophy.

2a) Be sharp and quick. When you know something, explain it concisely (fewer words is better), and with confidence.

2b) When you don't know something, just say so, immediately. Don't ever, ever try to bolshevik (an abbreviation for a similar word which I presume is well-known). I have cut interviews short, on the spot, because the candidate tried to make something up. Making up even the smallest bogus detail stands out like a huge warning flag to a person with 20+ years of experience. For example, *do not* put acronyms on your resume if you don't know them cold. If you say you know about FPGAs, you should know what FPGA stands for. If you say you are familiar with SIP protocol, then you had better know what SIP means.

3) On the other hand, when asked a technical question you don't know all of, but you know part of, do not hesitate to try and figure it out. Make a sketch, draw a graph, try to interpolate from what you do know. Managers like to see you reason and try to solve a problem. They like to see how you think. The worst new engineer is the one who sits in the lab like a bump on a log when faced with a bug, with no ideas on how to get unstuck and go forward. Any opportunity you have to show creativity -- and willingness and happiness to plunge in and get muddy and figure out the problem -- will win you a lot of points.

4) Make your resume solid and based on what you truly know and have learned. If you put it on your resume, you had better know it. Many times I see something like "Texas Instruments C6000 DSP project for this lab or that internship or that Professor...". Ok, sounds promising! I'm interested. Then I ask: "what was the exact TI DSP part? Was it floating-point or fixed-point? What development tools did you use? How did you get code into the processor to run?" If the candidate cannot remember the device, and specific details about it, then I know he/she really didn't do much of a project. If you truly work closely with a chip, then the device datasheet and manual become your best buddies for a few weeks, and you never forget. A lame answer that finally squeaks out like "well, I was part of a team, and I just handled the C code part, and I don't really know how that C code got into the DSP chip" is not going to cut it.

And what about those resumes that list every communications protocol ever invented by mankind? Because they were covered 15 min each in class? That's ridiculous. If you list even one of those, be prepared for in-depth questions -- you had better know it.

5) Debug, debug, debug, documentation, documentation, documentation. Learn to like those words. You should talk about debug and documentation with as much respect and enthusiasm as you do for design. If you sound like you only want to design, and you're too good for debug and documentation, that's a job prospect kiss of death. Debug and figuring out what is wrong with your wonderful, elegant design -- and explaining it to others -- is 2/3 of your career, so you need to be prepared.

Often I ask a candidate "tell me about your worst bug". If I don't get a real story, with some gory but triumphant details like "I slept in the lab for 3 days" or "it turned out the vendor's datasheet had the polarity backwards" or "the JTAG cable had a loose connector", then again, I know you did not work on a real project, or didn't participate at an in-depth level.

6) Act like you're already at work. Take notes. Ask questions and clarify. For example, I like to ask the person to send me several things after the interview (this or that source code example, a writing example, a web link to something they mentioned, etc). The objective is to ask for maybe 4 to 7 things with enough detail that is more than the candidate can remember. If they sit there nodding "ya sure" and they don't write anything down, then how am I to expect they can handle a blizzard of work instructions in the morning, and not forget anything by evening? Obviously not! I don't want to be impressed by how many items you can remember in an interview, I want to be impressed by your attention to detail and your organizational skills.

Ok... that's enough for now -- can't tell you all the top secret stuff :-)

My summary: when you're green, managers are looking for talent, work ethic, ability to learn, organizational skills, and teamwork type of "get along with people and contribute to the group" ability. Managers know you're not a technical expert (yet); you should not try to be one.

Good luck with your interviews!

-Jeff

Sign in