Recently I have been helping a friend practice interviewing, and a reader also wrote in to ask about interview technique. My own background is honestly not that impressive. If anything, it is fairly weak. After graduating in 2012, I applied to more than 800 environmental engineering jobs and ended up with only 3 internships. In 2015 I came to California for Hack Reactor (see my earlier post, “Coding Bootcamp: A Shortcut From Zero to Hired in Silicon Valley in Three Months?”). After the program I applied to nearly 180 jobs. Recruiters contacted me about 63 of them (35%). I reached the technical phone screen at 38 (60%), 11 companies invited me onsite (29%), and I finished with 3 offers, a rather sad offer rate of 1.6%. After working in Silicon Valley for a year and a half, I interviewed again at the end of 2016. Because I was working, I only tried 5 companies. All 5 advanced me to the technical phone screen, 3 invited me onsite, and I received 2 offers. That was real progress compared with the first two searches, although friends of mine have landed 5 to 10 offers in a single run, and some people on the 1Point3Acres forum collect offers from every big tech company at once. My experience is not especially remarkable. Precisely because my path was not smooth, though, it gave me more chances to learn. Here is what I took from it.

The Job Search Series

If you are interested in the job search series, you can read my earlier posts:

  1. Which Programming Language Should You Learn? If I Want to Join Google and Never Studied the Language They Use, Will They Accept My Background?
  2. An Introduction to the US Software Engineer Interview Process
  3. Waiting to Be Discovered: How Recruiters and Headhunters Find You, Why Standing Out Matters, and Whether LinkedIn Really Counts
  4. Going on the Offensive: I Am Job Hunting Now. What Do People in the US Use, and Which Platforms Give Me the Most Interviews?
  5. Interview Preparation: What to Practice, and How to Balance Practice With the Search
  6. Grinding Problems: The Data Structures and Algorithms Round Every Software Engineer Interview Includes
  7. You Got the Offer: What to Watch For, and Can You Negotiate More Salary, Stock, or Vacation?
  8. I Still Have Questions! A Silicon Valley Job Search FAQ

During my intense interview period in 2015, I sometimes had as many as 5 phone interviews in a single day. Some were first calls with HR, others were technical phone screens where I wrote code on a site like CoderPad. For a long stretch at the beginning, most of my results were rejections. So I asked friends to review my interview technique, and I also gained some experience interviewing others at SolarCity and Facebook. Here is what I concluded.

1. English Expression

Every interview will ask you to introduce yourself. This is a warm-up. It lets you tell your own experience and story, settle down, and do well on the questions that follow. It is basically free points, so prepare it properly. When I say English expression, I mean you do not need advanced English. You only need the interviewer to understand you. At first, when I got nervous, I would unconsciously speed up and my words would blur together. Later I made a large sign that said “Slow down!” and put it in front of me during phone interviews, reminding myself to answer each question slowly and clearly instead of rushing out of nervousness.

2. Be Confident, and Do Not Keep Mentioning That You Changed Careers

Early on, I would bring up the fact that I had switched into this field midway. After many rejections, a friend suggested I did not need to emphasize it. You never hear a dentist say he learned dentistry as a career changer. Even if he did, it is visible on the resume anyway. In an interview, I should show what I can offer and bring to the team and the company. My ability matters more than my background. Present that ability with confidence, and back it up with the substance of my answers.

3. Pace Your Communication: Answer Briefly First, Then Go Deeper if Needed

Interviewers have an expected pace for each question. Some questions only need a short answer. Others invite more detail. When I have been the interviewer, I have watched candidates spend a long time on small questions, telling detailed stories and examples, and eat into the time left for the far more important coding challenge. A better approach is to give a simple answer first and signal that you can say more if the interviewer is interested. Let the interviewer decide, based on time and the flow of the interview, whether to hear the details. You will not burn precious time that belongs to more important questions.

4. Show That You Stay Flexible When Things Change

Sometimes an interview includes an especially hard problem. Do not panic. Many interviewers want to observe how you face a difficult, uncertain problem under pressure. If you can analyze the problem logically, begin offering ideas, and construct an approach step by step, you often meet the interviewer’s expectations. You do not need a perfect answer to pass.

5. Prepare Your One or Two Biggest Achievements

Many interview questions can be led back to your past achievements. Interviewers often ask about a hard problem you faced at work, what kind of work you enjoy, what your strengths and weaknesses are, or whether you have similar experience. For example, if you are asked about a difficult problem, you might say that you joined a large cross-department project where conflicting schedules and goals slowed everything down. You kept communicating with the leaders of the different departments, helped design a plan everyone could execute, got every department on board, finished the project on time, and brought the company $5 million in new revenue. Support your achievements with evidence and numbers, then use that example to answer the hard questions.

6. The Whiteboard Coding Challenge

After the interviewer describes the problem, first confirm the input and the output. Do not immediately say how you would solve it, and do not start writing code. The input and output must be completely explicit. Write them on the whiteboard instead of glossing over them in a few words, and confirm them with the interviewer. Once they are confirmed, talk through your approach and discuss it before you begin coding. While you write, keep communicating. Explain why you are writing the code this way. If your first solution is a preliminary one, mention that it can be optimized afterward. An interview tests whether you are technically qualified, and also whether you are a team player who can communicate with team members. I have seen several candidates put their heads down and code from the start, barely communicating. Some of their mistakes went unnoticed precisely because they never talked them through, and in the end they did not pass.

Those are my six takeaways from my own experience. Is there any part of interviewing you would like to understand better? Feel free to leave a comment or write to me.

This post was originally published on my former blog, 「半路出家軟體工程師在矽谷」, on June 13, 2018. The blog is now offline, and the text is preserved via the Wayback Machine. It has been lightly edited for this site.