Skip to main content Skip to search box
UC Berkeley homepage Career Center homepage

Featured Article

Engineers: Prep for Technical Interview Questions
January 16, 2004
Looking for a job? At some point in your search you will likely encounter technical questions. Learn from recruiters what they look for and suggestions on how to prepare.

The advice below comes from sources at ALZA - a Johnson & Johnson Company, ChevronTexaco, Applied Signal Technology, ExxonMobil, Schlumberger, and The Dow Chemical Company.

What are some basic strategies for answering technical questions?

  • If you know the answer, then go ahead and do your best. Be sure to use pictures and diagrams if it will help. Use the white board, or draw on a pad. When you finish, ask if that was what the interviewer was looking for.
  • Often, technical questions will be asked and you won't know the answer. The interviewer will direct the candidate to go ahead and try to answer. Remember, that the interviewer is evaluating your process for approaching a problem just as much as your answer.
  • For technical questions be direct, solid and assertive.
  • Most important is how you answer the question in addition to what you say. We try to assess your thinking process and delivery of the answer. Logical and reasonable thinking is preferred over a one-line response.

Would you be able to give some examples of technical questions?

  • Questions can range from, "Please explain the concept of polymorphism in an Object Oriented development." to viewing a selection of C++ code with an error in it and being asked what will happen when this code is compiled and run, to something as seemingly innocent as, "Why are manhole covers round?"
  • It is impossible to predict what type of technical question you will be asked. The best way to prep for technical questions is to review the skills you listed on your resume that relate to the job. It's likely the technical question will come as a result of what kind of work or research experience is on the resume; therefore, prepare by reviewing any kind of project or experience that is in the resume. It is almost a given that the questions will come from it, such as, "Could you tell me more about your role in the 'X' intern program? How could you apply this research to the oil and gas industry?"
  • Another way to prepare is to read industry specific magazines, internet sites, or even talk to people in the industry; e.g., if interviewing for the Pharma sector, be sure to have an understanding of what's going on with the pharmaceutical business and most importantly with the company with whom you are interviewing.

What do you do if you don't know the answer? What will recruiters think of applicants who don't know the answers?

  • First, be sure you understand the question and what the interviewer is trying to find out. If you are not sure, ask the interviewer for clarification. If you don't know the answer, be honest. "I don't know" is always preferred to erroneous information in an engineering environment.
  • Come clean; don't try to BS. If you do, the interviewer will lose confidence in your ability to contribute positively to the engineering team. Erroneous answers are more harmful to product development than, "I don't know, but I'll find out and get back to you."
  • I recommend if you don't know the answer to simply say, "I don't know." It is better than making something up. It shows honesty - which is a trait all employers highly value.
  • If it is a "difficult" question, ask for some time to think about it. If you do not have an answer, be honest about it and let the interviewer know that you really don't have an answer, maybe because you have never been in such a situation, etc. Remember, for the recruiter there is no WRONG answer; each candidate has their opinion and perspective on a question.

What do you look for when students answer technical questions (qualities, skills, etc.)? Can you offer suggestions on what to emphasize?

  • Good communication skills are a necessity in an engineering environment where we work in teams and must communicate our designs to team members. This includes written as well as oral communication skills. In the workplace, engineering concepts must be captured, documented, and presented.
  • Other key issues include an ability to understand the question being asked, to think clearly "on your feet," and to be able to explain a technical solution clearly at the appropriate level of technical detail. Keep in mind the background of the interviewer, e.g. if the interviewer is technical or non-technical, if the interviewer has a PhD in Engineering, etc. If uncertain, the student may want to ask the interviewer how detailed they wish a response to be.
  • We also look for clear and organized thought process as well as aptitude and enthusiasm for their engineering discipline.

Final thoughts:

  • Make sure you do your homework before going into an interview. Read the posted job requisition and if it calls for a skill that you may be rusty on, brush up on it before the interview. For example, if the job requires proficiency in C++ and Object Oriented Methodologies, you should read up (even if it means picking up a book, or downloading articles from the web) and practice some examples.
  • Understand the job description and technical expectations of the job. Have a good ability to explain your technical strengths and how they match the position. Prepare yourself to answer this question: "Why should we hire you?" An interview is a sales pitch and the product is you, so be able to sell yourself and your value-added features (i.e., knowledge, skills and abilities).
  • Target your resume for the job you are applying for. If the job posting is for a Software Engineer, don't put in your Objective (yes you should have an Objective), "To find a Software or Test Engineering position."
  • Do not put anything in your resume that you are not prepared to talk about. If you are asked to elaborate (and you will be asked) and you can't, you will lose confidence points. Often the reviewer is looking for what your contribution was on projects. If you can't talk about it in depth, it will appear that you weren't a key contributor or you didn't really know what you were doing.
  • My best advice is, "be prepared, be yourself and use your common sense."
                    UC Berkeley Career Center | Contact Us | About Us | Search | A-Z Index | Questions & Answers
Privacy Statement | Copyright 2014 University of California, Berkeley | Student Affairs
This page last updated 9/15/2005 (ag/lh)