Back when I began interviewing for internships, it seemed like questions were asked at random with no real goal in mind. Some questions would be more open ended, some looking for a specific answer, and others technical in nature. As I have continued in my career, I have not only had many interviews but I have now been on the other side of the table interviewing people for open positions, and it brings a whole new light into how and why certain questions are asked. Over the past two years or so I have had many opportunities to interview and be interviewed. Through which, I have accumulated notes on how people interview, what types of questions they ask and why. So, here is my experience with it:
The questions that I have always found interesting are the behavioral questions. In asking different people why they ask these types of questions during interviews, most have told me it was to evaluate how I would react in different situations and to determine if I would be a good cultural fit for the team. Here are a ew behavioral questions that I have always loved to be asked and to ask:
- If you had to be a fruit/dessert, what would you be and why?
- Explain a time when you had to be a leader on a project or at work. How did you take on this role? What did you learn?
- Explain a time when you had to educate others on a technical topic? How did you approach this? How did it go?
- Discuss your experience with public speaking.
- Favorite type of music / instrument / band and why?
- You are on a sky lift that has a tight turn radius and 24 seats. You are at the bottom getting on the chair. There is a chair at the top coming down. How many chairs do you pass on the way up to the top?
- Explain your volunteer work. What do you do outside of work?
The next set of questions come from the technical side but range in what is asked and how. From my experience, these are the types of technical interviews I have had and what I learned from each:
(Time: 1-2 hours, Questions: 3-4)
The online code tests I have taken are the standard tests that ask a handful of questions (typically 3 to 4) in a coding language. Depending on the company, some require a specific language to be used while other don't. Most of these resemble the algorithmic questions you would get in a college coding class. They expect a specific answer to a problem. Some companies will send out the code test to be completed while others will have you complete the code test while being monitored. I have found that the tests in which I am monitored, it is best to take many notes and have an open dialog during the process to show how you're thinking through the problem.
(Time: 1 week, Questions: 1 mini project)
Code tests that I have taken in this format are much more open ended. They provide a problem and desired output, and it is up to the coder to develop a function or set of functions to complete the task. When I take these types of code tests, I read through everything carefully and build up a set of questions / assumptions I have about the problem and verify that what is expected on their end is the same as what I expect. I find it is best to have good communication in these types of code tests, to clear up any misconceptions that could occur while developing the code.
(Time: depends on interview length)
The next type of questions I have seen in an interview is more open ended questions during a 30 minute talk with a team member. These questions have ranged anywhere from basic problems and how you would solve them, to explaining key features in an application. I have found these problems to be the most interesting of the coding questions as it allows for an open dialog with both the interviewer and interviewee. You can bounce ideas off of one another, openly discuss solutions, and explain your thinking as you go. These can also lead into more questions or further discussion.
(Time: depends on interview length)
The last type of technical interview I have been in was very open and more focused on my own experience. When placed in these situations, I have had one or more team members in a room asking about personal experiences, basing questions off the discussion, and diving deeper into the projects or work discussed. I have found that an interviewer may push further into specifics on a project or work experience if they want to test your knowledge or understanding of it. I try to include as much detail as I can on these discussions and allow room for further discussion and ideas to flourish. Sometimes many technical minds in a room can give light to new ideas as you discuss projects you are tackling!
After all of their questions have been answered, it is time to begin to ask your own. I find this is a good place to have researched the company and the product(s) that they specialize in, in order to go in with a good set of questions to ask. If it is a multistep interviewing process, I make sure to review all notes and previous questions asked in order to make a new list of questions for each person or interview I walk into.
A few questions I love to ask no matter the place include:
- Why do you love to work at you job? What keeps you motivated to stay here?
- What do you believe to be a key feature or asset of the product / company that sets you apart on the market?
- Ask in-depth questions on the product, how it operates, and what functionality may benefit the company moving forward.
I love to ask the first question of almost everyone I interview with. I began asking this question this past year or so because I wanted to find a place people enjoyed working for and a team that enjoys each other. Making people think about their team and company can tell you a lot about the environment they work in. This has helped me filter out companies that I feel do not have a great culture fit with what I am looking for.
The next question helps me determine what a company is really striving for and where they are headed in the future. I ask this question of different people to get a better understanding of how they view the company versus what is posted online about the company or on the company site. If it is a startup, I also like to ask what began the company? What was the motivation behind building this product in the first place? Sometimes the answers may surprise you.
Lastly, I like to dive deeper into the product itself to understand where the company is now, where they are looking to head, and how the position I am applying for helps reach those goals. If there is not a clear understanding of where the role fits into this development, I take that as a warning. I look for positions that offer growth, learning, and development, not only as an individual but as a company.