In my opinion, interviews are the most stressful part of a computing science co-op (or any co-op).  In this post, I will cover the different areas of an interview, specifically catered to Computing Science Co-op students.

Applications

Of course, the precursor to any series of interviews is an application. Check daily and apply often to the jobs that interest you, even if you don’t quite meet all of the requirements on the posting. If there’s a dry spell where none of the posted jobs interest you, at least apply to some of the ones you think might be interesting. Sometimes you might not know whether a job is a good fit just by looking at an application form. Sometimes it takes an in-person interview to know for sure whether you’re interested in a job, and this leads me to the single best piece of advice to take away from this section: an interview is a conversation, not an interrogation. It’s just as much an opportunity for you to learn about the company as it is for the company to learn about you and decide if you’re a good fit.

Personality Interview

From my personal experience (and from the experience of those I have talked to), computing science interviews usually fall into one of two categories: the personality interview, and the technical interview. Personality interviews are usually conducted by a university relations specialist, a member of human resources or sometimes a manager, and are focused on why you applied to the company. They’re less about discussing your engineering skills and more about discussing your interest in what the company does. For example, If you applied to Boeing because you built model airplanes as a kid and you love flying and reading about aircraft as a hobby, be sure to advertise it since it shows that your genuine interests are aligned with what the company does. Just remember that it’s a two-way conversation. Ask questions about the team to see if they are a fit for you. What are their interests? What backgrounds do they come from? Whenever I enter a personality interview, I make it a goal to leave that interview with a very precise vision of the company’s culture and its employees. The company culture will have an enormous impact on how much you enjoy the job (possibly even bigger than the nature of the work itself), so it’s important that you know as much as possible to make the right decision, if you get the offer.

Technical Interview

Not all companies will devote an entire meeting for a personality interview, but all of them will ask for a technical interview, and this type is much more challenging. This is the interview where you show off the techniques you’ve learned in courses, from past jobs, open-source or side projects, and your engineering and design sense.

Interview Questions

So, what kind of questions can you expect? Almost every computing science co-op interview will contain some basics that you should be ready to answer off the top of your head. Make sure you know the concepts behind object-oriented and perhaps functional programming paradigms, including all of the terminology (inheritance, polymorphism, etc. – think CMPT 125) and especially why those concepts are useful in the paradigm. Some programming languages support class inheritance not just because inheritance is “cool”, but because it helps us reuse common code. You should also be familiar with data structures and abstract data types, including their operations and implementations for asymptotically optimal run-times (think CMPT 225, or CMPT 307 if you’ve taken it). All of these are basic knowledge for interviews and are covered by coursework. The real challenge of the technical interview is advertising the value of your skills.

Stand Out

For the most part, all of the other candidates have the same basic course knowing that you do. So how do you set yourself apart? Think of the times you actually applied that knowledge to great effect. Think of the projects you can discuss, whether they are from courses, open-source work, past co-ops or even personal work. Think of what kind of problems you faced, how you overcame them, and what you learned from them. If the project involved other people, be sure to clearly advertise the value you provided to others. This last point is important, and it’s a tip that greatly improved my interviewing skills. Let’s suppose that in your last co-op, you radically improved the team’s automated testing pipeline. During the project, you probably learned a lot about testing and the team’s feature set, which is great to mention in an interview because you provided lasting value to that team. If the new testing pipeline saved every tester two hours of setup and manual testing per week, and your team has five testers, then that means you saved the team ten hours per week! That’s a significant amount of value and shows that you can produce effective results, which is something your interviewers will want to hear.

Of course, you won’t always be asked to simply describe what you have done. Most of the time you will be asked to solve an engineering problem or write some code on the board in the middle of the interview without reference materials. In my opinion, these are the most challenging parts of the interview. Answering basic knowledge questions that you’ve learned about in courses or describing the projects you’ve worked on are straightforward, but you can never anticipate the sorts of problems you will be asked to solve on-the-fly. With that in mind, it seems impossible to prepare for these situations, but there are a few tips I keep in mind that certainly help. First off, remember that the interviewer is not necessarily looking for a perfect solution right away. They often pose a programming problem in order to see how you solve problems, not whether or not you can solve that particular problem. Because of that, it’s a good idea to openly talk about the problem with your interviewers. Ask questions to clarify anything you’re unsure about, and make sure you walk your interviewers through your thought process while you attempt to solve the problem. If you need time to think, then ask for a moment to quietly think about the problem. Providing a well-thought-out plan but arriving at the wrong answer can often demonstrate more skill than arriving at the correct answer with no plan, since it shows that you can do more than a program – it shows that you can clearly articulate technical concepts and put forethought into a situation. These are important skills to have when you’re part of a team, since software engineering is rarely a solo effort.

The End of an Interview

At the end of every interview, you will have time to ask some questions of your own. Always prepare questions to ask beforehand. The exact questions you ask will vary depending on the company and your interviewers, but I always try to ask deep questions that suggest I’m interested in more than just a co-op job, making sure the questions encourage a conversation rather than one-sentence answers. Before an interview, I often try to think of the types of questions that a manager might ask about the well-being of their company or their team.  Here are some examples:

• How does the team operate? (i.e. its development cycle)

• Has the team always functioned this way and if not, why did it change?

• What are the best qualities of the team and what aspects could be improved?

• Are there any specific challenges you (my interviewers) have personally faced and how did you resolve them?

On one occasion, I was interviewing for a company that had been bought by a much larger corporation. I asked how the buyout affected the day-to-day life of the team and learned of many things that improved as a result, but I also learned of a few obstacles that it introduced. This gave me great insight into how the team operated and I was complimented for being the first applicant to take an interest in the company’s history. Remember: your questions give you (mostly) free reign to examine how the team works internally, so be sure to take advantage of the end of the interview and learn as much as you can so that you can make an informed decision if you get an offer. Good luck!