Mastering the Art of the Technical Interview

From Anita Borg Institute Wiki

Description

Panelists: Ellen Spertus (Google and Mills College), Cecilia Aragon (University of Washington and Lawrence Berkeley National Laboratory), Erin Chapple (Microsoft), Tamara Holden-Gurin (County of Alameda, California), and Taylor Van Vleet (YouTube)

Computer science majors applying for their first jobs often do not know what to expect from or how to prepare for their first technical interviews. A group of experienced software professionals with extensive interviewing and hiring experience at different sized-companies will explain through presentations, mock interviews, and question and answer what companies are looking for, the different ways candidates are assessed, and how best to prepare.

Slides: File:Technical-interview.ppt, File:Technical-interview.pdf

Session Notes

Taylor Van Vleet (YouTube)

Hiring from the company perspective.

It is a numbers game. Hundreds of resumes to only find one candidate that may not even accept that offer. A good way to filter through the mass of resumes is company employee referrals, so it is good to keep a large strong network.

Hiring from recruiter perspective.

Run in conjunction with hiring committee, can often accommodate external deadlines, so let them know if you have other important scheduling commitments. Expect range of interviews: peers, seniors, intra versus extra team. May do several interviews in a week. Generally, find interviews to be one of the more stressful day to day activities. Interviewer should be polite and courteous. If they are not, don’t take it personally, (it’s them) so prepare for next one with clean slate.

Hiring manager perspective.

You may encounter 0, 1, or more hiring managers in your interview. Ask the recruiter if you will encounter a hiring manager. Look at them as you prospective boss and get a feel for that.

Hiring committee perspective.

Interviewers may only provide written feedback, delay between last interview and decision, may meet on demand several times.

Cecilia Aragon (University of Washington and Lawrence Berkeley National Laboratory)

Preparing for a technical interview.

Industry, government, academia, etc. are all different. I will focus on software developer here. Do your homework on the type of place you are applying to. Government research labs are often more flexible and work on more interesting projects, hire more even during recession.

Keep your notes and your textbooks - it makes a great refresher when you want to review your technical skills that you learned from them.

While you are still a student - make contacts, people you meat here at GHC, ask if you can visit for a day and talk about the work they do - this can give you a clear idea of the job and if you want to do it or not. Make a resume that looks like the job you want. For example, if you were in technical writing but now you want a developer job, you may not want to include your technical writing skills, however extensive they are, on your resume to avoid being pigeon holed into that niche.

Medium term - a book Programming Interviews Exposed is a good preparation resource. Go back to the basics and be very familiar with them.

Short term - research the company, talk to friends, bring extra hard copy of your resume to the interview.

Ellen Spertus (Google and Mills College)

Interviews are artificial.

You may be a great software engineer but that won’t come through in the interview. Good news is that interview skills can be learned.

Be prepared to discuss

background: past projects, debugging, leadership & teamwork experience, resolving differences with coworkers.
programming: white board coding: practice on paper without IDE. It’s ok to not remember exact library routines, interviewer wants to evaluate how you think, so think aloud. Even short silence can feel very long, so verbalize your though process. Balance confidence and humility. Interview questions may be ambiguous so make sure you understand what you are being asked and ask to clarify. Write down some examples if the clarification questions do not come to mind right away. You are not expected to be perfect, so don’t panic if you don’t know the answer, interviewer will keep asking questions until they hit your limit.
algorithms: make sure to review before going to an interview.
system design: class structure, scalability, ask to clarify on what to optimize, etc.
product and industry ideas: “how could one of our products be improved?”, don’t say “it’s perfect”, think in advance about these things.

Tamara Holden-Gurin (County of Alameda, California)

Interview starts before the interview.

You are interviewing them as well! Research the company, be careful who you ask questions, don’t ask 25 questions from the hiring manager.
Dressing up: makeup - use if it makes you feel comfortable, attire - one notch above the company dress code.
Learn as much as you can about the company, make your self comfortable: shoes, water, time of day.
Give yourself ample time: arrive 15 minutes early, leave 1 hour after the interview free.
Interpersonal skills: scan the room - am I in tune? Be confident, enthusiastic, don’t forget eye contact, smile, see how they respond, be a team player. If you talk about a certain thing and people start looking at their watch, move on to another subject.
Cultural fit: when I ask “tell me about the project you are most proud of?”, I am looking for how they are going to fit in our environment, what drives them.
Loaded questions: what to do when client calls you with a tech problem.
Different cultures
- established software company: variety of tools, highly developed SDLC process, learn a lot;
- startup: high intensity, minimum bureaucracy, lack f specialized job roles.
Inappropriate questions: age, race, pregnancy. The rule is: do not offer more information than u need to. If asked about being pregnant, don’t get defensive, reply with a canned answer, switch to talking about the future.

Mock Interview

Erin Chapple (Microsoft) interviewing Ellen Ellen Spertus (Google and Mills College)

Erin (R): Let’s look at your coding & problem solving skills: reverse the words in a string for me.
Ellen (L): (writes down an example) how should I treat punctuation, numbers?
R: As chars
L: What language should I use?
R: C, or Java
L: I like C for string manipulation
L: (writes code), Let’s test it on my example (verbally walks through working out an example)
R: How confident are you in your code?
L: (takes a pause) I think it works
R: what happens if I give it a NULL string?
L: (talks about how it will handle the NULL string and what needs to be added to the code)

Comments: you should discuss the API for the function with the interviewer; when writing by hand, leave ample space to add corrections as needed; she forgot error handling - real programmers care about error and exception handling, so should have verbalized that and probably would have gotten help with that; don’t state that you are completely confident in a piece of code you wrote by hand under stress, say that given a compiler you would have had a chance to check, and ensure that it’s correct; practice with friends where one is pretending to be the interviewer and tries to break your code; It’s OK to ask the interviewer questions if you are not sure about something, they expect that, good thing to walk through the code verbally with the interviewer.

R: You might be responsible for transition a doc management system from one system to another
L: I’m not sure what a document system is
R: (explains)
L: (gives ideas of a replacement/design system, taking into account her knowledge of the company: i.e.: multiple branches)
R: Let’s think back to different people from different branches scenario, what other considerations may be need to think of?
L: (discusses possible issues arising from distributed company)
R: (asks about concurrent updates issues and versioning)
L: (discusses what those may be and how may be managed)

Comments: very well done - considered not only coding, but environmental aspects, different uses, considered globally; used technical terms and understood what they meant, however, did not mention anything about the cloud which there is a lot of hype about at the moment, should talk about transitioning there and possible issues; if you can get on a whiteboard and draw diagrams that would help, feasibility of a design usually comes down to numbers, e.g.: how many users will be accessing at the same time, how many documents to store, etc. - ask about those upfront to get a better sense of the problem.

Q&A

Q: Often asked: where do you see yourself in 5 years, what is your plan for the future? What is an appropriate answer?
A: Don't be dishonest, keep in mind the sensibilities of people you are interviewing with.

Q: What do you do if you have no idea about the question you are asked?
A: It’s OK not to know things, but asking questions to clarify is OK, be careful on what you ask, say “I’m not sure I fully understand what you want me to do, are you looking for ‘this’ or something like ‘this’?” never say “I have no idea”, repeating the question back helps, if it is a coding question, writing down helps; Don’t say “I don’t know, but I can Google it”, don’t say you are an expert in something unless you truly are.

Q: What is considered a good candidate?
A: Senior interviewer should be able to hit your limit - basic question, intermediate questions, and something you may not know; self-awareness, and ability and willingness to learn are important.

Q: For coding questions - is it important to have full working code or showing your approach is good enough?
A: Will depend on the company and position. Ask if they want pseudo or working code. May want to talk to HR manager going into interview on what the expectations are.

Q: Resources to prepare for a research interview?
A: Usually requires a job talk - talking about your research (your adviser will help with that), followed by at interview talking about research, how you can apply your research to company’s problems. Be specific in your talk on what was your individual work and what was done by the team. Practice talks with your friends and students. In a research interview you are expected to take more of a lead, you should be leading the interview.

Q: On technical interviews when writing code we often fall short on time, how to deal with that?
A: Let the interviewer know that, nobody can write perfect code in 10 minutes and you are not expected to; some code is better than no code and if you are verbalizing solution as you are going it’s good; if the interviewer tells you to move on, move on, don’t say “oh no I have to finish this”.

Q: I do well in phone interviews but flop in face-to-face ones.
A: Rehearse, do it in front of camera and then review.

Q: When asking for leadership examples how do you know people didn’t make it up?
A: Interviewer will start to probe on some aspect they may want to know more about; it’s hard to make up that much detail on the fly while you are sitting there. A good measure of future performance is to look at past performance.

Q: At the end interviewers ask what questions do you have for us now? What are they looking for?
A: Important part of the interview! From beginning of the interview I may have questions and I may jot them down, don’t ask about the lunch program; ask either technical questions about something you may have encountered earlier in the interview or a cultural fit question.

Recommended books

Programming Interviews Exposed: Secrets to Landing Your Next Job by John Mongan and Noah Suojanen. Wiley, 2000.

One of:

Effective Java (second edition) by Joshua Bloch. Prentice Hall, 2008.
Effective C++ (third edition) by Scott Meyers. Addison-Wesley, 2005.

Fun Links

Google CEO Eric Schmidt rhetorically asking presidential candidate Barack Obama how to sort a million numbers, a famous Google interview question

Cartoons: