The Recent Grad’s Guide to Interviewing

During the past year at ResIM, we’ve received numerous resumes and met with dozens of applicants. This is what we didn’t see enough of:

Submit code samples, discuss what you’ve built and how you’ve built it. Whether you’re hoping to work at a AAA game development studio, or wanting to join a small agency, be prepared to show examples of your code. If a company doesn’t ask — or seem to care — about your previous work (whether in school or part-time jobs), they might not be terribly reputable. Interviewers will view you similarly if you show up empty handed. In university, we heard a story about a student who brought his laptop to an interview at Electronic Arts Montreal. Not only did he receive a job offer based on a quick game demo built for an assignment, but the two other students he worked with were offered positions as well.

Keep it professional. We want to get to know you — your interests, your hobbies, your passions. There is, however, a line. For the love of all that is good and holy, please don’t tell us about the time you were fired from a job because you moved in with your boyfriend. Please.

Show you care. Unless you’re the next Zuckerberg, showing up in flip flops with an “I don’t give a shit” attitude is not going to make us think you’re hot shit. We’re going to honestly and truly believe that you just don’t care.

Prepare for a technical interview (just in case). With major tech companies some technical component is almost a guarantee. You’ll be asked a series of questions featuring everything from first year computer science theory to algorithm design and optimization. Practice, practice, practice. And then practice some more on a whiteboard. Writing on paper in the privacy of your room or dorm is not the same as writing on a giant whiteboard in front of hungover senior developers from a Fortune500 company. Trust.

Show passion. Most companies want to hire individuals who love what they do, are passionate about the work they produce, and want to improve their ‘craft’. Be honest about your skill level, but also about how you either plan to— or are currently — improving yourself. Whether it’s with Treehouse classes, hoarding textbooks or just building pet projects to learn new languages, employers love enthusiasm.

Know your industry. Have a sense of who works in the industry, who you admire, who you aspire to be. Why are they awesome?!

Keep your resume relevant. Even if you don’t have a lot of work experience, I firmly believe in excluding that summer you worked at DQ while home for summer break. Instead, pad your resume with examples of school projects. Use your school experience as supplemental work experience. As much as I may envy how closely you worked beside the soft serve machine, I care much more about the hours you spent fiddling with the GitHub API.

Hold the BS. In this industry, it’s not as easy to bullshit your way through an interview. You may think that exaggerating the knowledge you have about web security will impress your interviewers, but they know which questions to ask. Catching you in a lie will not only make you look really really bad, but will make everyone feel awkward. Besides, an interviewee who lied their way through an interview could mean an employee who lies about the amount of work they’ve completed at code review time. Avoid it — please.

Dear Senior Developer,

I have heard an overwhelming number of stories regarding senior developers badmouthing juniors to other coworkers. As a developer, and someone who has mentored less experienced developers and students, this upsets me.

I can understand the frustration of working with someone who likely has much less experience, but shouldn’t this be viewed as a prime opportunity to educate rather than berate?

If you have a problem with someone’s work, or the way in which they complete that work, shouldn’t you privately consult with them and offer suggestions? Bitching to other coworkers about an individual’s work is not only counter-productive, it’s destructive. I feel as though development ‘teams’ are considered teams for a reason: we work together, we push through server crashes, bugs and yes – sometimes incompetence – together.

But if you no longer feel respected by a coworker on your team, you may stop asking questions for fear of being berated — whether publicly or without your knowledge. When we stop asking questions, we stop learning and we stop growing and our productivity flatlines. Do you remember those teachers or professors who criticized students for ‘stupid questions’ or publicly shamed them for answering a question incorrectly? Do you remember how awful that felt, because you were genuinely trying to learn? What difference is there between that educational relationship and the relationship between a senior and junior coworker? I don’t think there is any difference.

Every single professor in each of my Computer Science classes reiterated that we would do much more learning in the workplace than in the classroom. Our degree gave us the foundations and knowledge that we needed to be employable, but much of our growth as developers would come from learning from other, more experienced coworkers.

I’m pretty sure that at some point everyone was new in the industry. Apprenticeship programs exist for that very reason: to help newcomers gain experience under the guidance of a senior. I want to learn, I want to improve and I want to grow as a developer. This is likely the case with many other developers in the industry — whether senior or junior.

So, why have I heard so many stories of senior developers incessantly complaining about their less experienced coworkers? I see it in memes, I hear about it in work environments in real life, I see it on television.

The addition of tutorials to our office was incredibly beneficial for me when I first started at ResIM. Our senior developer took an hour during the day (for several) to explain the inner-workings of our in-house framework and best practices surrounding implementing certain aspects of the framework. Not only did it help with interpreting each other’s code in the future, it also gave us a better understanding of exactly how we should be using the framework for our projects. It increased productivity, at least for me, and helped me to feel confident that I was implementing the framework in such a way that it wouldn’t need to be changed by someone with more experience.

I understand that coworker frustrations are often a necessary evil in a work environment. I understand that sometimes people lose their temper, coworkers disagree on how a project should be approached, etc. But why aren’t we respecting each other enough to discuss issues respectfully and help each other improve? Wouldn’t that actually improve the workflow and the quality of software produced? Wouldn’t it be great if the next time a junior implemented something they did so correctly because they had been corrected? Isn’t that the point?