Interview and Resume Advice

Here is my interview advice. It actually applies to both sides of the interview (you as interviewer, you as interviewee). It is my opinion and all numbers are made up. Much of the basis for this advice comes from the book Smart and Gets Things Done which is mostly about high-end software hiring. You can read more at the author's blog. I've modified it a fair bit to suit my own experiences and perceptions.

As a basic rule of technical interviewing in engineering people should be looking for three things.

1. Are you smart?
2. Do you get things done?
3. Are you a reasonable person to work with?

1. is generally going to come from grades colored by how well you answer technical questions. Sometimes the answers are more important than the grades, but not normally.

2. is generally going to come from discussions about work you've done. So have a project or two ready for discussion. Class projects are less than ideal, but your senior design project will generally be just fine. They are looking to see if you pulled you own weight and actually understood what you did as well as the context for the project.

3. is generally about social skills. Sometimes they are looking to see if you are fun to work with. Other times they are just checking to see if you are a jerk. It depends. People who you are going to be directly working with will generally weigh this more heavily than a general engineer who will be working on the other side of the building.

The way these three criteria are weighed varies by company. I'd say that 40/40/20 or 45/45/10 isn't unusual in a large company and 20/50/30 isn't too unusual in a smaller one (again, I'm making up these numbers). But something like 60/35/5 isn't unheard of (company hires smart people and figures they can work with them to make them productive). A certain large software company is legendary for ignoring #3 as a metric unless the person is so bad no one can imagine working with them. I think that is just a myth (no company could survive that way and those who have to work with the person will always weigh 3 fairly highly) but probably a myth with a bit of basis in reality.

Exact skills

Wait you say, you've completely ignored "has the skills we need". Yeah, yeah I did. I'm assuming the interviewee has been screened and has a general background in the field in question. This doesn't mean, for example, "knows Java", "knows VHDL" but rather "knows how to program" or "knows HDLs" or even "knows a lot about signal processing". Language/tool-specific things can be picked up fairly quickly (2-10 weeks is a reasonable guess depending on the person and the language). But if the interviewee has never designed or debugged hardware in their life that does raise the bar quite a bit for a hardware gig (for example). In some fields there really is only one language (perhaps Matlab for signal processing?) and so in that case it's reasonable to expect skills in a specific language.

If the interviewer needs someone right now so they can get started without a 2-6 week lag then the exact skill set can matter. But as an interviewer remember that you're playing a pretty high long-term price by hiring the person you need today rather than the one that will be better in three months. And as an interviewee, be really worried about a company that thinks that short term. Sometimes there is a good reason ("We just got a $50M contract and we need it done in 6 months! Go hire people now!") but generally it implies a lack of planning that could be scary down the road. Small companies sometimes are forced to do this (we need this problem solved NOW and no one here can do it), but it's still not a good sign in general.

So, what do I do?

As an interviewer, it helps if you are clear on what you're looking for. Smart? Gets Things Done? Try not to focus on the exact skill set unless the time frame is really dire. Of course it's easier to interview people who have the same skill set you do and there really isn't much you can do about that. It's easy to miss a great worker whose skills are a bit different than yours and it's also easy to get snowed in that same situation.

My favorite interview question, taken from a good friend of mine, is "I see on your resume you built/worked on/designed a thingy. Tell me about it." And every time they stop talking ask for more details about what they did and what the larger context was.

As an interviewee, be sure your resume includes project work. If you've done a fair bit of project work it should probably take up 20-35% of your resume. Be sure you are ready to discuss your project work. There is also the more basic advice: know what the company you are interviewing with does and what the job they are interviewing you is about. Figure out which of your skills and projects are the best match to them so you can be sure to highlight those.

Resume

Be sure your resume is solid. A statement of purpose is handy (no matter what anyone else says) so at the least people know if you are looking for an internship, coop, or full-time job. Keep it simple and not restrictive "To find a full-time job in the field of software engineering" is fine. After that include your educational background (degree, expected graduation date). I generally prefer to see list of courses (by name, not course number) that are relevant. 5-8 in general is a good number for a senior, putting the more advanced or relevant ones first.

Then comes the GPA part. If your GPA is solid, put it out strongly. If it's weak (below a 2.5, maybe below a 3.0), you have a hard call. First see if there is a reasonable way to get it above a 3.0. For example "3.1 GPA in technical coursework" or "3.2 GPA in last 4 semesters" is generally fine. If there isn't (and no, "things like 3.4 GPA in courses starting with a B" isn't legit though "3.3 in circuits courses" might be if you are a circuits person) then I'd generally suggest you leave it off. (Though it's pretty tricky to figure out what to do with a GPA between 2.5 and 2.9. Don't list it and people will probably assume it's worse. Do list it and people might throw out your resume as not meeting some HR requirement.)

Now comes work experience and class project experience. In general cool internship or research projects should go first and get a lot of the text. Next major design projects or open-ended projects should be listed. Spend a few sentences on which ever project you lead with. As a senior, avoid listing your Engin 100 project unless you really want to talk about it, in which case list it but keep it short, probably not mentioning on the resume that it was a freshman project. Spend some time working on this section because unless you have a stellar GPA (and even then to some extent) this will be the largest differentiator you've got. You should have 2 to 5 projects listed even if they are fairly lame (everyone can list their EECS 280 projects, but if you don't have anything else, list it anyways).

Next list those language and tool proficiencies. For software people this is generally pretty easy (list programming languages and if you've spent a lot of time using a specific tool or IDE list that). For hardware people you should not only list languages but also list tools (Synopsys' VCS for example). This is not only to clear your way through the HR folks who are playing "buzzword bingo" (that is looking solely to see if you have the buzzwords they are looking for), but also to get a technical person aware of what you've used and feel comfortable with. Of course, don't list things you can't answer basic questions about...

At the end comes the leadership roles and clubs and stuff. Technical clubs where you actually did something are important as are leadership roles in nearly anything. In general though, avoid listing divisive clubs (political parties, religious organizations etc.) People are looking for leadership skills and a true, outside-of-school and outside-of-work, interest in technology as well as a hint of real leadership and organizational skills ("Gets Things Done").

And then the small things. Have a peer and parent/older person proofread it. A resume with a spelling error or a poorly formatted resume says something about your work ethic. Next, you may need to have more than one resume (say one for hardware jobs and one for software jobs). It always feels a bit odd to do that, but it's important to sell yourself to the right audience. The difference should not only be a matter of ordering (listing software classes and software project first for example) but also how much space you spend on each thing.

Finally, good luck and I hope this helps!