The Internview

“Are you registered for the internship program?” is my opener for almost every student I talk to at career fairs or open houses. Depending on their response, I pivot one of two ways: 

“Awesome! Are you applying at zu?” or “Huh. Well, we all make mistakes.” usually followed by an awkward chuckle and maybe some finger guns, depending on their expression.

A bit of context for the uninitiated - every year, zu participates in the University of Saskatchewan’s Computer Science Professional Internship Program. It’s how I got my start at zu and it’s something that we have been doing for over a decade. It’s an incredible opportunity for students that provides an accelerated boost into the job market while allowing zu to form a working relationship with a local up-and-coming developer.

While I could ramble on about the upsides of the internship process, it does come with a series of hurdles that can appear daunting. Cover letters, resumes, applications, job fairs, topped off with perhaps the most anxiety-inducing obstacle of all: the interviews themselves. 

While interviews can be stressful and nerve-wracking all on their own, they all end up scheduled in the same two-week period forming a gauntlet of stress and panic. During my internship application, I foolishly made the mistake of applying to every company that seemed vaguely interesting and as a result, ended up with a week of 3 midterms and 12 in-person and over-the-phone interviews. 

Spoiler for that chapter of my biography: I did not do well on those midterms. 

Today, I find myself in the privileged position of being on the other side of the table and have a different challenge to face. I now have the pressure of ensuring that the next intern is going to succeed. I have to ensure that whoever we choose isn’t going to drop a production database during their first week, while also making sure that they have an interesting performance for the zu talent show.

In an effort to atone for my current role of adding more interview dread to the world, I’d like to talk through our internview process—highlighting some of zu’s big questions, what I hope(d) to hear and what’s surprised me in years past. This year we’ll use a different set of questions, so if you’re an aspiring intern looking to game the system: first of all, great initiative. Second, try and learn the lessons and tune your brain to start thinking this way and I’m sure we’ll get along just fine.

zu’s Developer Internview Process:

So that the rest of this article makes sense, our intern interviews in 2020 were typically 45 minutes long and were a mix of both technical and personality questions. I represented the technical side of things while Deidre, zu’s People Strategies Director, was there to make sure I didn’t bite anyone. 

We structure the interview by beginning with traditional interview questions before quickly diving straight into the deep end with our technical questions, which form the majority of the interview. We then wrap up with a practical whiteboard question, review any lingering personality questions that came up during the conversation and finally give the internviewee a chance to ask us questions.

A sidebar from a robot-brained developer—don’t stress the personality questions. You’re the best expert on you, so relax, be honest and reflective and you’ll slay this part of the interview. If you’re at the point where you’re sitting in the room with us, we probably already like you.

Homework

I don’t love traditional take-home interview questions. Personally, I’m the type that would stress over them and come to the interview with a killer answer, while neglecting to prepare adequately for the rest.

Beyond the anxiety they introduce, we’ve all read the horror stories of companies using applicant’s interview solutions as a way of boosting their own productivity. It’s terrifying and all things considered, I’ve just never been a big fan. The issue is, however, that not all applicants submit portfolios and those who do don’t always have as robust examples as we’d like to see. The power of a good portfolio goes a long way in demonstrating the depth of a candidate’s abilities but they are also time-consuming to put together. All concerns aside, there’s a lot of value in allowing the candidates to prep something for the interview.

Last year we tried something a bit different. We decided to give two high-level discussion questions in advance to give the applicants the chance to think about their answers in more detail while allowing us to get to the meat of the conversation faster. As part of the homework, I gave instructions stressing that I didn’t want or expect any sort of code or development to be done but just wanted people to feel comfortable having a conversation with me about the questions.

The Questions

In order to understand the reasoning behind our questions, it’s important to understand what zu does at a technical level. The easiest way to explain us is that we are digital problem solvers. A large part of the technical issues we solve are oddball issues or requests from clients. Those questions can come through to development with a wild scale of variance. One of the primary jobs of a developer who is going to be working at zu is to be able to quickly digest the problem and start mentally trying to solve it while identifying strategies that we can use and problems that we need to overcome.

The questions we sent out last year to our intern applicants were meant to simulate these situations. 

Some general thoughts I had when crafting the questions:

1. Just as the conversations we like to have with our clients, these questions are raw and unrefined. Both questions contain a really good idea surrounded with some maybe incorrect presumptions.
2. I wasn’t looking to have a specific conversation with the interviewee about technology choices. Whether someone builds a Vue.js app for this or wants to code up a Swing GUI is irrelevant for the question. Familiarity with technology is important, but it’s also something that usually comes up in conversation and when talking about the candidates’ personal projects.

Mixtape Mayhem

Let me set the stage of the basis of this question—Kevin, a senior developer here at zu, asked me a more specific version of this question while we were loitering at the bread counter - our office’s equivalent of a water cooler. His wife recently found a box of old burnt CDs and wanted to listen to them in the van in a more portable fashion. That problem became the basis for the first question we sent home to our applicants:

Imagine you have a stack of 100 burned CDs filled with mixes of songs that your friends have given you. You don't know the tracklists or what the names of the songs on the disc are. 

You've just purchased a new vehicle and want to listen while you drive, but it doesn't have a CD player.

How would you go about transferring all the songs to a streaming music service as a set of playlists?

I really like this question. It’s actually really straightforward and achievable in scope, but it’s delightfully complicated in its execution. As I see it, there are two major problems (three if you don’t have a readily available disc drive):

1. How do you identify the title and artist of a song when you rip it from a homemade mix?
2. How do you automatically get the identified track on your streaming platform of choice?

The second problem is the easier of the two. Here, I was mostly hoping to hear candidates talk about something like an API or other means of communicating with a standalone piece of software. Whether Apple Music even has an open API or not is another question. I’m just hoping the students are wondering about themselves or took the initiative to check. 

The best responses were from students who took the time to research the available methods and formats that their provider of choice supported.

The first problem is the more difficult, by far. To the best of my knowledge, the only way to develop this is through digital fingerprinting and amassing a large database of fingerprints for popular songs - something that is far outside the scope of a simple app. What I was looking for in the discussion of this problem was a recognition of the scope problem and just how big and expensive it might end up being. 

This reinforces one of the primary skills a zu developer needs to have: be able to forecast technical hurdles that are going to end up being time sinks. 

The best solutions I heard for this problem were to find out a way to piggyback off of an existing music identifier such as Siri, Google Assistant or Shazam—similar to how I’d attempt to tackle it. My favourite answer for this problem came from an applicant who took the time to research a combination of python libraries that could be used to do the digital analysis on the files and who came up with a theoretical way to build the fingerprints. This was way too heavy of a solution but it was interesting to read and theorize about.

As an aside, Kevin did end up assembling a prototype app that would solve this problem. He ended up using a pretty nasty mess of Apple Scripts and the Shazam Mac app. The last time I heard, it was working really well with the exception of a bug that was triggered when Shazam failed to find a song and would instead substitute Lil’ Jon’s Taco Tuesday as the default song in the playlist. 

Content Discontentment

For the second question, I wanted to give something that was as big as the first question was small. We asked our applicants:

Your friend asked you to build a web-based app that would help them track what TV shows are on which streaming service (Netflix, Amazon Prime, Crave etc.). They want the ability to look up a show and know if it is streaming in Canada. They also want to allow users to create an account on the app and then have it automatically subscribe and unsubscribe them from services just by toggling them from within this new app.

What questions would you have for your friend to clarify what they're looking for? What technologies would you use? How would you host it?

The most memorable response when I asked the applicant for their take was: “Well I don’t think I’d want to be friends with this person anymore if they wanted me to build this for them.”

This question is something that I think has widespread appeal. It’s an attractive pitch, but when you start digging into it at a technical level it’s a mess.

When you start thinking about the technical problems, they quickly get out of control:

1. Is this even legal? Does this violate the terms of service for those platforms?
2. Can we register and unregister users?
3. Where does the content come from?
4. How are you going to securely store the payment info?

And the list could go on and on...

As I pointed out in relation to the first problem, a big part of the developer’s job in tackling a pitch is to help identify areas of risk. This question is full of risk, but it also gets at something that is essential for staff at zu: the willingness to tackle a seemingly impossible problem.

The ideal developers, for us, are the type of people who, even when presented with a seemingly impossible question with dubious foundations, start to look for new angles to make it [the project] both possible and successful.

The best answers we received here were along the lines of: “This is a terrible idea, but here’s how it might be done. ...just to reiterate this would probably be really complicated.” 

My favourite ideas were the ones that veered to unorthodox solutions: building a calendar of subscriptions, partnering with the companies to develop APIs and hosting partially-automated solutions that would help streamline the subscription and unsubscription process.

If I were to tackle this one, I’d spend some time researching new open providers of movie and TV data. I’d completely punt the option of dealing with subscriptions and payment in favour of a service that sends reminders to users informing them of when their subscriptions will renew and reminding them to cancel.

Finding our Unicorn

There’s a running joke among the developers at zu that hiring a zu developer is a bit like finding a unicorn. It’s almost impossible to find someone who is an existing expert in the wide variety (and ever-expanding) technologies that we work in. At the end of the day, you’d have an easier time finding a unicorn than a developer who is a preexisting expert in Drupal, iOS and Ember.js.

While we do still look for them (developers, not unicorns), we’ve also found that it’s best to look for people who are teachable, flexible and have the motivation to learn while being an expert in something applicable to our business. Once we’ve found those people, they naturally gravitate toward the leaders on our development floor who can teach them what they know. Through this process, we find that we can end up finding some pretty amazing people and mentoring them so that they become incredibly successful zu developers.

So, I suppose we’ve learned that instead of finding unicorns, it’s a better idea to find an eager horse and turn them into a unicorn. This also, apparently, is where the analogy appears to break down.