Technical interviewing: from an engineering student’s perspective
by Kaitlin Schafer | April 14, 2015
Technical Interviewing: from an Engineering Student’s Perspective
The technical interview can be a scary hurdle between you and the dream job you’ve always wanted! In order to set yourself up for success, you need to study and know what to expect during the entire interview process. Below you’ll find two OSU engineering students who shared their technical interviewing experience during the internship/job search.
David Finn is graduating in May 2015 with a B.S. in ECE. He recently accepted an offer with Amazon as a Software Development Engineer.
Ria Sugembong graduated in December 2014 with a B.S. in CSE. She is currently working as an Application Developer for JPMorgan Chase.
Based on your experience, at what stage of the interview process did companies conduct technical interviews?
David: I had very different experiences with different companies. With the bigger more technically oriented companies (Amazon, Microsoft, Google, Epic), they would often start conducting technical interviews in the first round. If I was interviewing at a smaller company or for a specific team at a company, they would usually wait until after a behavioral interview to do a technical one. The technical interviews varied in style. Some were phone interviews where you would talk out 1 programming question over 30 minutes. Some were 30 minute phone interviews where it was more like a quiz with many smaller general questions. Some did timed online tests, where they would give programming questions and you would write your actual code. Then there were the on-site interviews. These were the last round interviews. The company flies you out to their location and you spent the day touring the site and getting interviewed. There were usually 4 to 5 interviews that lasted an hour each and were with a different person each time. The interviewer would present a programming problem and you would write your solution on a whiteboard.
Ria: Company recruiters usually contacted me via phone to find out my interests and skills. If they felt I was a match for their company, they followed up with technical interviews. My first round of technical interviews were usually conducted by phone. Companies often conducted 1-2 phone technical interviews for 30 minutes – 1 hour long. Some companies asked me to code and some just asked technical questions without having to code. For companies that asked me to code, I was provided with a text editor like Google Docs. I was asked to explain my thought process, algorithm, running time, etc. while typing my code in a text editor. At the end, I had to test my code by going through the code. Some other companies asked me to complete a coding task with a time limit with a given link that they provided. If I passed the first round, I was flown to their headquarters for the onsite coding interview which had 3-5 round of interviews. These on-site experiences were basically the same process where you have to write code but on a white board and explain your thought process, the algorithm, the running time, and then test the code. Additionally, if I was at a career fair, and a company liked me, I was directly given an on-site interview and did not have the initial technical phone interviews.
How did you prepare for technical interviews?
David: I prepared for these by reading the books Cracking the Coding Interview: 150 Programming Questions and Solutions and Programming Interviews Exposed, doing a lot of practice problems, and going through old class notes. These books do a good job of breaking down what the interviewers are looking for and how you should attack problems. I think these books are what really improved my interviewing skills the most; they especially helped my in-person interviewing ability. It was also good to go over old class notes because they can ask anything, so it's nice to be ready for anything. I specifically remember once being surprised by how many questions were asked about operating system concepts in a phone interview. It made me glad that I went over my Systems II notes beforehand.
Ria: I practiced by reading books or websites for technical interviews. Two books that I recommend are Cracking the Coding Interview: 150 Programming Questions and Solutions and The Google Resume both by Gayle Laakmann McDowell. I tried my best at knowing what to expect before the interviews. I knew that some technical interviews could be repeated. I also knew all the algorithms and running times. I familiarized myself with all information listed in my resume. Everything on your resume is fair game during interviews!
How did you demonstrate your technical knowledge and skills?
David: Getting the right answer to a technical interview question is good, but to really stand out you have to show more than just the final answer. The interviewers want to see how you think, so I told them what I was thinking. I explained my thought process at every step: why I picked one data structure over another, the performance differences between different algorithms, the different edge cases I would have to handle, etc. This was also good when I didn't know the answer right away. It gave me a chance to talk out different options which helped me realize what the answer was in the end.
Ria: Interviewers want you to have a good experience during the interview, so don’t be nervous! They also want to see if you have good communication and team work skills. Employers do not want just to see someone that can only code but can work as a team. When interviewers asked a question, I first showed the interviewers that I understood the problem. It is expected for you to ask them a question back in regards to the initial question. I tried my best to not make assumptions. I showed my thought process and did not think silently because interviewers want to know how you approach the problem. I asked the interviewers questions if I didn’t know something. I found it better to be honest, rather than staying on a subject that I was not familiar with or didn’t understand. If I really could not solve the problem, I let the interviewers know so we could move on to the next question, where I had a much better chance of solving the problem. Interviewers want to help you to get to the solution to a problem, so don’t be afraid to ask!
I also explained which algorithm that I wanted to use, and why I chose that algorithm and not others. I discussed the pros and cons of each algorithm. My algorithm was not always perfect. It is better to finish with a solution that you can enhance rather than coming up with a perfect solution that you haven’t finished solving. After explaining the algorithm that I used, I coded the solution while still explaining what I coded. I asked the interviewers if I ever forgot a method. After I was done with the code, I tested my solution by going over line by line. Test all possible inputs. Make changes if you found a bug. It is perfectly normal to have bugs when writing code the first time. I explained the running time of my solution. If I still had time, I tried to enhance or made a better solution.
How did you handle tricky questions?
David: It's an awful feeling when you get stuck and don't know what to do next. When this happened to me, I would start discussing every option I thought I had and then start ruling out the options that I at least knew weren't right. A lot of times, doing this would lead me to the right answer. If I was stuck on developing an algorithm, I would try specific examples until I noticed the pattern. If you're really stuck on a tricky question, the interviewers will often nudge you in the right direction; however, it's not good if they have to nudge you a lot.
Ria: Remain calm and try to think about all the knowledge you’ve acquired thru classes and projects. During tricky questions, I always found it important to explain why I picked my approach. The interviewers usually led me thru the problem if I got it wrong.
What advice or tips do you have for students regarding technical interviews?
David:I think the biggest thing is practicing. Find a whiteboard and do example interview questions the exact way you would if it was a real interview. Talk out loud explaining your thought process and don't peak at the correct answer before giving it a serious effort. You also get a feeling for the kinds of questions that interviewers ask, so you're less surprised when they ask them. After my first big programming interview didn't go well, I spent hours doing practice problems on a whiteboard. By my next interview, I was much more confident and relaxed, and I did so much better! It makes a huge difference.
Ria: In every interview, even though you know you are smart, don’t come across as overconfident. Interviewers want to see smart and humble people that they can work with on a daily basis.
"Success is the sum of details."
-Harvey S. Firestone