A design manager's respond for "interview help". [zt]
A design manager's respond for "interview help".
By Jeff Brower From ASICDESIGN@yahoogroups.
I keep seeing these request for "interview help".
As a manager with many years of experience, I can say these requests are in the wrong direction. As a new grad or intern, you don't know much and you will not for a few years -- that's just the way it is. Trying to study or "cram" before an interview is a waste of time.
What you need to focus on is this:
1) Be sharp and quick. When you know something, explain it concisely (fewer words is better), and with confidence.
2) When you don't know something, just say so. Don't ever, ever try to bullshit. 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.
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.
3) Make your resume solid and accurate. 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. Then I ask: what was the exact TI DSP part you used? What tools? 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.
And what about those resumes from an MSEE that list every comm protocol invented? 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.
4) Debug, debug, debug. Talk about debug and documentation with as much respect and enthusiasm as you do for design. If you sound like you want to design only, and you're too good for debug and documentation, that's a kiss of death. Debug and figuring what is wrong with your wonderful design is 2/3 of your career, so you need to be prepared.
Sometimes I ask "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 other specifics, then again, I know you did not work on a real project.
5) 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 7 things -- more, I know, than the candidate can remember. If they sit there nodding "ya sure" and don't write it 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.
Ok... that's enough for now -- can't tell you all the top secret stuff :-)
The summary: when you're green, managers are looking for talent, work ethic, ability to learn, and teamwork / 'get along with people' skills. They know you're not a technical expert (yet); you should not try to be one.
Good luck with your interview!
-Jeff
By Jeff Brower From ASICDESIGN@yahoogroups.
I keep seeing these request for "interview help".
As a manager with many years of experience, I can say these requests are in the wrong direction. As a new grad or intern, you don't know much and you will not for a few years -- that's just the way it is. Trying to study or "cram" before an interview is a waste of time.
What you need to focus on is this:
1) Be sharp and quick. When you know something, explain it concisely (fewer words is better), and with confidence.
2) When you don't know something, just say so. Don't ever, ever try to bullshit. 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.
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.
3) Make your resume solid and accurate. 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. Then I ask: what was the exact TI DSP part you used? What tools? 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.
And what about those resumes from an MSEE that list every comm protocol invented? 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.
4) Debug, debug, debug. Talk about debug and documentation with as much respect and enthusiasm as you do for design. If you sound like you want to design only, and you're too good for debug and documentation, that's a kiss of death. Debug and figuring what is wrong with your wonderful design is 2/3 of your career, so you need to be prepared.
Sometimes I ask "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 other specifics, then again, I know you did not work on a real project.
5) 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 7 things -- more, I know, than the candidate can remember. If they sit there nodding "ya sure" and don't write it 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.
Ok... that's enough for now -- can't tell you all the top secret stuff :-)
The summary: when you're green, managers are looking for talent, work ethic, ability to learn, and teamwork / 'get along with people' skills. They know you're not a technical expert (yet); you should not try to be one.
Good luck with your interview!
-Jeff
posted by Zhang at 7:45 AM
0 Comments:
Post a Comment
<< Home