[Originally written on July 14, 2015 on LinkedIn but now all articles on LinkedIn are closed to the public]

I review countless résumés and give many mock job interviews a year: to students, to people in their 40s and 50s. I really enjoy doing them. People really appreciate them. I naturally enjoy mentoring and coaching. It is no surprise that those I mentor and coach land great opportunities. In September and October (as that is the busy college recruiting time), I am frequently asked: “how do I prepare for a technical interview?”

First things first, be yourself. Here are the questions that I, and many good interviewers, will ask:

Tell me about yourself. A dreaded and open-ended question. The purposes of this question are to see if the candidate has a pulse, can communicate clearly, is prepared at all, and is interest in the job and the company.

I understand that you have worked on [put project here; bonus if it is a side project]. Explain why you did [some function or task] this way. Can you do better? One purpose of this question is to understand the candidate’s thinking process. I also want to see if the candidate can make tradeoffs. I can also determine candidate’s passion especially if response is related to a side project. Look, there are lots of smart people out there. Passionate people are another breed, very hard to find. For the latter question, I want to see if the candidate has reflected on the work. As my friend Bill Langenberg said: “People who are passionate about what they do will always find things to improve, whether that’s the actual product or how they approached the problem.” For deeper technical questions, if candidate responds “I don’t know” that is a good thing, not a bad thing. There is nothing wrong with admitting to limited understanding of a deeper and specific technical question: it is a fair and honest answer. Admitting to not knowing something is always better than bullshitting through the response.

A follow-up question if project is a software project or tool: did you use revision control for software project? A red flag if the answer is “no.” The reason why it is a red flag: revision control is a fundamental skill in software development –to keep track of changes and for communications. Not knowing how to use revision control means you will need to spend time on the job to learn it (e.g., Git, Subversion), and it is not a skill to pick up overnight.

How and when did you first get involved with this field? There are three things I aim to dissect from your story: your passion and enthusiasm, your intellectual curiosity, and you are not going into this field for the money.

Do you have any questions for me? Your questions (or lackthereof) will reveal how seriously interested are you, how badly you really want the job, and if you did your research on the position and on the company. Serious red flag if the candidate does not have any questions.

Notice that I did not list any “cookbook” technical questions (e.g., “Given a recursive function, can you make it into a non-recursive function?”). The reason: they can be Googled. Generally, I find little very value in them. Knowing or remembering facts doesn’t tell me much about the candidate’s problem solving skills, situational awareness, and most importantly, personality. One question I do find value in is the infamous FizzBuzz problem to check if the candidate can actually program, code (if a project the candidate talked about did not involve code which is extremely rare). Last spring, a number of students thanked me for stressing this question as this question was asked on their interviews.

A few important notes:

  • A thank you note goes a long way. You don’t believe how few people do this. Interviewing candidates is time-consuming and tiring.
  • There are so many candidates that look amazing on paper. However, few candidates have “something to show for it.” A portfolio of some of your work will set you ahead of the pack. There is a reason why GitHub has become a de facto résumé in the tech industry.
  • If you know who your interviewers are, there is nothing creepy about gathering information about them via Google, Facebook, LinkedIn, Twitter, etc. It is expected. Doing this means you are “doing your homework.”
  • The converse is also true. Assume that the interviewer(s) will know everything about you. The interview serves a confirmation of what they already know.