The Freshers Interview Guide

Jeff BrowerSeptember 19, 200720 comments

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!


[ - ]
Comment by white5502October 5, 2007
nice point
[ - ]
Comment by abhisheksgumadiOctober 13, 2007
Very True. I have a DSP interview in the near future. Now I know how to be prepared better for it. :-) Thanks Jeff
[ - ]
Comment by creekOctober 21, 2007
thank you very much ! i am sure the time i spent reading this is worth it :)
[ - ]
Comment by jacobv05November 4, 2007
Now pay attention you youngin's --- the above is solid advice.
[ - ]
Comment by aravindhaNovember 30, 2007
Hello Jeff, Thank you for the excellent post. Keep posting.
[ - ]
Comment by jasmanJanuary 16, 2008
hai jeff thank you for the advices. i'm so impressed as newbie in this blog
[ - ]
Comment by jubairJanuary 23, 2008
a really helpful article
[ - ]
Comment by xh6354March 13, 2008
Hello Jeff, Thank you for these good idears.
[ - ]
Comment by Srinivas_BApril 25, 2008
Every sentence in the article is a great tutor for job aspiring freshers(even for experienced)..Hats Off to you Jeff. Keep posting
[ - ]
Comment by chandsaJuly 31, 2008
Hi Jeff, Great article! Wish this had appeared a long time back when I was fresh out of school. I am extremely happy to read your point about debugging and documentation. After working for 5 years I am still trying to come to terms with software that was written by people before me, without absolutely no trace of any documentation. Not documenting one's own work is probably one of the worst things that an engineer can do. Anyway, before I digress too far, are you still hiring ;)? Thanks!
[ - ]
Comment by mayuri2585September 22, 2008
Awesome...every sentence is true...thanks a lot for your valuable advice..:)
[ - ]
Comment by binuOctober 29, 2008
thanks a lot
[ - ]
Comment by jayakarthickDecember 7, 2008
nice one Jeff.... thanks a lot
[ - ]
Comment by cpshah99March 25, 2009
Amazing article!!!!!
[ - ]
Comment by sgayathri7August 6, 2010
Hi Jeff The articel was very informative. Thank you.I am a new grad actively looking for jobs and this article means a lot to me..thanks again!!
[ - ]
Comment by swaroop.bhushanJanuary 11, 2011
Great facts for everyone to know. The essence of your article is true when interviewing in any field.
[ - ]
Comment by amith.kamathApril 21, 2011
Probably the most important points in a complete idiot's guide to the perfect interview! Great for a newbie looking for a rewarding career!
[ - ]
Comment by ahmadagha23November 25, 2011
Hi Jeff, I hope to work in your company (signalogic) with such a manager
[ - ]
Comment by vedaantamJanuary 31, 2012
Definitely one of the most informative articles of the information age.... No bolshevik :)
[ - ]
Comment by ank881October 30, 2012
thanks a lot for valuable advice..
as i am working on implementing an ITU based codec on TI 6713DSK, so can you help me how to proceed and start in correct direction..

To post reply to a comment, click on the 'reply' button attached to each comment. To post a new comment (not a reply to a comment) check out the 'Write a Comment' tab at the top of the comments.

Please login (on the right) if you already have an account on this platform.

Otherwise, please use this form to register (free) an join one of the largest online community for Electrical/Embedded/DSP/FPGA/ML engineers: