Category: Software

Software

Against Programming Hobbies

Posted on by Zach

[Epistemic Status: Written more harshly than my actual views for persuasive effect. I should also point out that all views expressed here are my own, not my employer’s; when I’m hiring, my first commitment is complying with the relevant Federal, Provincial, and local legislation. My second commitment is to finding the best people. Ideology doesn’t come into it. Serendipitously, I think everything I’ve argued for here helps me discharge both duties.]

In my capacity as a senior employee at Alert Labs (it’s easy to be senior when the company is only three years old), I do a lot of hiring. Since I started, I’ve been involved in interviews for four full time hires and five interns. Throughout all of this, I’ve learned a lot about what to look for in a resume.

I’ve also gotten in the occasional disagreement about what we should look for in in people we’re (potentially) hiring.

When looking through resumes for software engineers, it’s accepted practice to look for independent programming projects. These are things that people do in their spare time, normally to learn new languages or make things that they find cool. I’ve done a few myself. If you look at my projects, you’ll see one where I create a tool for my favourite pen and paper roll playing game, one where I work through math problems, and one where I’m trying to better understand the concept of randomness.

There’s a curious double vision in the profession about programming projects. We all tell ourselves people do them only for fun. Yet we also look for them on resumes.

The second fact means that the first cannot always be true. My projects partially exist for my resume. I’ve enjoyed working on them. But if there wasn’t a strong financial motive to have worked on them, I probably wouldn’t have. Or I’d have done them differently.

As a someone who hires, I can’t claim that programming projects aren’t useful. They give, perhaps better than anything else (e.g. the much-derided whiteboard interview), an idea of what sort of code someone would write as an employee. I’ve called people – especially people without any formal education in CS – in for interviews largely on the strengths of their personal projects. Seeing that someone can use the languages that they say they can, that they can write unit tests and documentation, and that they can lay out a large project makes me have more faith that they can do the job.

When programming projects are used as a complement to employment and educational history, I think they help the field.

But I’ve also argued stringently against treating personal projects as a key part of any hiring process. While I like using them as a supplement, I think there are four good reasons not to rely on them as any sort of primary criteria.

First, not everyone has time for projects. Using them as a screen sifts out people with caregiving responsibilities, with families, or with strong commitments in their personal life. When you’re only hiring from people without other commitments, it becomes easier for a team to slip into a workaholic lifestyle. This is bad, because despite what many people think, studies consistently show no productivity benefits from working more than 40 hours per week for prolonged periods. All long hours do is deprive people of personal time.

(In a world where people with caregiving responsibilities are more likely to be female, overreliance on personal projects can also become a subtle form of hiring discrimination.)

I’m incredibly grateful that I work at a company founded by people with both management experience and children. Their management experience means they know better than to let their employees burn out from overwork, while their children mean that the company has always had a culture of taking time for other commitments. This doesn’t mean that I’m never in for sixty hours in a week, or that I never have to deal with a server failure at midnight. Work-life balance doesn’t mean that I don’t take my work seriously; it just means I don’t conflate being in the office for 12 hours at a time with that seriousness.

Second, requiring people to have programming hobbies sifts out a lot of interesting people. I understand that there exist people that only want to live code, only want to talk about code, and want to be surrounded by people who are also in that mode, but that isn’t me. I joined Alert Labs because I wanted to solve real-life problems, not make tools for people just like me. Having a well-rounded team means that people spontaneously generate ideas for new projects. It means they take ownership for features (like ensuring everything on our website follows accessibility guidelines) that would never percolate to the top of my mind. It makes our team stronger and more effective.

Outside of a few other oddball professions (lawyers, I’m looking at you), no one else is expected to treat their work as their hobby. People can make their hobbies into their work (look at webcomic artists or bloggers who make it big) and this was one of the initial purposes of personal programming projects. It’s not at all unusual to find something you like enough that you’d make a full-time job of it if you could. But then you normally get new hobbies.

People who fall in love with programming are lucky in that they often can turn it into a full-time job. Writers… are somewhat less lucky. I haven’t monetized my blog because I’d find the near-impossibility of making money off of discursive posts about political economy disheartening. Keeping my blog as a vanity project keeps it fun.

 

But we programmers shouldn’t let our economic fortune turn what has always been the path that a minority of people take into our field into a bona fide requirement.

Third, I dislike what an overemphasis on programming projects can do to resumes. I frequently see interesting hobbies shunted aside to make room for less-than-inspired programming projects. I’ve seen people who got the memo that they needed a profile full of projects, but not the memo that it had to be their projects. This leads to GitHub pages full of forks of well-known projects. I don’t know who this is supposed to fool, but it sure doesn’t work on me.

When students send in resumes, they all put the same four class projects on them, in the somewhat futile hope that we won’t notice and we’ll consider them adequately dedicated. I wish the fact that they were paying $8500 per term to learn about CS could be taken as proof enough of their dedication and I wouldn’t have to read about pong sixty times a semester, but that is apparently not the world I live in.

My final beef with an overemphasis on programming hobbies is that many important skills can’t be learned in front of a computer. Not all hobbies teach you how to work together with a disparate team, respectfully navigate disagreements with other people, and effectively address co-worker concerns, but those that do are worth their weight in gold. Software is becoming ever more complex and is having ever more capital thrown at it. We’ve exhausted what we can do with single brilliant loners, which means that we now need to turn to functional teams.

This isn’t meant to conjure up negative and insulting stereotypes about people who spend all their spare time programming. Many of these people are incredibly kind and very devoted to mentoring new members of our community.

I don’t want people who program in their spare time and love it with all their hearts to be tarred with negative stereotypes. But I also don’t want people with other interests to be considered uncommitted dilettantes. And I hope we can build a profession that believes neither myth.

Advice, Software

A Dialogue on Lateral Thinking

Posted on by Zach

Cast: The Hare (interviewer #1), The Coyote (interviewer #2), and The Tortoise (interviewee).

Hare: Okay, that wraps up the technical portion of the interview. Now we want to ask you some lateral thinking questions.
Tortoise: Lateral thinking questions?
Coyote: You know, questions that challenge your ability to come up with non-obvious solutions? Or when you find a solution by throwing out all your assumptions? Here at Acme Corp., we pride ourselves in coming up creative solutions to problems.
Tortoise: Okay…
Hare: We’ll start off easy [1]. Acting on an anonymous phone call, the police raid a house to arrest a suspected murderer. They don’t know what he looks like but they know his name is John and that he is inside the house. The police bust in on a carpenter, a lorry driver, a mechanic and a fireman all playing poker. Without hesitation or communication of any kind, they immediately arrest the fireman. How do they know they’ve got their man?
Tortoise: Hmmm… Well, if they can immediately tell the profession of everyone in the room without saying anything, presumably everyone is dressed in clothes emblematic of their profession. I think the jumpsuits firefighters…

The Hare snorts in amusement.

Image Credit: MaxPixel

Tortoise: As I was saying, the jumpsuits that firefighters wear often have nametags on them. So they arrest him because he’s wearing a jumpsuit that says “John”?
Coyote: Not quite right, I’m afraid. You see, all the other poker players were women.
Tortoise: I don’t really see how… You aren’t next going to ask me the one about the surgeon operating on her son are you? This isn’t secretly the HR section of the interview?
Hare: No, you’re already through that.
Tortoise: Because I assure you, I do think women can do anything men can.
Coyote: We weren’t questioning that at all.
Tortoise: It just seems weird to have a problem that hinges on interpreting fireman in an archaic way. I’m given to understand that it’s essentially gender neutral now, although I thought firefighter was preferred… Sorry, this is a tangent. You said you had more questions.
Hare: How about you ask the next one Coyote.
Coyote: A man lives in the penthouse of an apartment building. Every morning he takes the elevator down to the lobby and leaves the building. Upon his return, however, he can only travel halfway up in the lift and has to walk the rest of the way – unless it’s raining. What is the explanation for this?
Tortoise: That’s a really odd way for an elevator to work. What time period is this?
Coyote: That isn’t important to the question.
Tortoise: Okay, I know this is a digression, but how can more information not be important to the question? Like this is basic scientific method. You formulate a hypothesis that is capable of being falsified by the world. Then you see if the world falsifies it. And you keep doing it until you have a hypothesis that doesn’t get proven false. It’s basically the same as test-driven development, come to think of it. Didn’t you just ask me if I did TDD?
Hare: We do TDD. We also write code on computers, not whiteboards. The interview doesn’t map quite perfectly to the job, but we have found how candidates perform on these questions often correlates well with their later performance.
Tortoise: Okay, if you say so. Um… maybe the elevator uses water as a counterweight, but the counterweight leaks a lot and only really works properly when it rains? I really don’t have a better answer.
Coyote: Nope. The man is a little person. He can only reach the button for his penthouse when he has an umbrella with him.
Tortoise: Couldn’t he just carry an extendable pointer with him and use that?
Hare: If it’s any consolation, I got this one wrong too. Now I like to visualize the guy as the kind of person who is so lazy he won’t do anything he doesn’t absolutely have to, even if doing it would save him time.
Coyote: Hare keeps insisting that getting this one wrong is a badge of pride, because it proves that you have a huge inferential gap to that kind of laziness.
Tortoise: That’s the most reasonable thing I’ve heard in the last five minutes.

Coyote snickers nervously.

Image Credit: Jitze Couperus

Coyote: Um… Well, one last question: Assume there are approximately 7,000,000,000 (7 billion) people on Earth. What would you estimate to be the result, if you multiply together the number of fingers on every person’s left-hands?
Tortoise: Oh wow, that’s… oh, I see! Zero. There’s plenty of people with no fingers, so the result has to be zero.
Coyote: I’m glad you got that one. When people try and write out a solution the whole thing gets out of hand.

Tortoise groans.

Image Credit: Eric Kilby

Hare: Actually, that brings up an interesting point. Are puns a form of lateral thinking?
Coyote: I don’t think so. I think puns are more of a brute force thing. You know roughly what you want to say and what you’re punning off of, so you can do a brute force search in your head for likely combinations.
Tortoise: Puns feel closer than those questions. When I think of lateral thinking, I think of a much less constrained solution space. I felt like those problems just tested my ability to be clever in the exact right way on command.
Coyote: What does having one answer have to do with it?
Tortoise: Well look at your first question. A priori, I don’t think any reasonable person would consider my hypothesis less likely than the “correct” answer. If I was in the room with the police, then obviously my answer would reflect reality less closely than the answer that John is the only man in the room. But without that information, it really is just luck if you stumble onto the one right answer. Anchoring effects mean it’s hard to generate multiple plausible answers. And because you’re anchored onto the “right” answer, you view my answer as obviously incorrect.
Hare: You honestly did fine on this section. You really don’t have to argue about your score.
Tortoise: It’s not about score, it’s about the principle of the thing! Even if lateral thinking is a useful quality in a software developer–
Hare: What makes you think it isn’t?
Tortoise: Lateral thinking, by definition, involves unexpected solutions. Answer me honestly: do you like reading code where someone did the unexpected thing? I’d rather an ugly but conventional solution to an unexpected one that’s “elegant”. I mean, there’s a reason no one uses Perl any more, right? “More than one way to do it” is a horrible philosophy for code that has to be read by many people!
Coyote: Tortoise has a point there, Hare. I remember when Perl programmers used to brag to me that they could write a web server in one line of code. It made me think of the scientists in Jurassic Park. Just because you can do something doesn’t mean you immediately have to go out and do it.
Hare: I don’t think programmers need to use lateral thinking all the time. But aren’t there often places where an unconventional solution saves a lot of time?
Tortoise: Name one.
Hare: What?
Tortoise: Name one unconventional solution you’ve implemented that saves time. Bonus points if you don’t need five lines of comments to keep everyone else on the team from being confused by it.
Coyote: I actually have one! I had to round to the nearest half to enable functionality that the designer wanted. I considered this horrible concept with recursive if-statements. But then I found out there was a much better way to do it. You just multiply your number by two, round, then divide by two. It’s one line and perfectly clear if you think about it for a second.
Tortoise: So why didn’t you ask me about that?
Hare: We have an interview script. We can’t just change whenever one of us comes up with a clever solution to a problem.
Tortoise: Then pick a few examples in your code where you actually had to think laterally and give them out as worksheets. At least that has a chance of accurately measuring our lateral thinking. And if we get it right, you have a convenient baseline in Hare here.
Coyote: Actually, I didn’t come up with the solution.
Hare and Tortoise: Stack Overflow?
Coyote: Stack Overflow [2].
All pause to consider this.
Coyote: Huh. So if I understand you correctly Tortoise, your point is twofold. One, lateral thinking isn’t a very important quality in a programmer. Doing things conventionally is actually more useful, because as Guido van Rossum pointed out when he designed Python, code is read more than it’s written.
Tortoise: That’s a really good way of phrasing it. How would you phrase my second point?
Hare: Actually, can I try this one?
Tortoise: Certainly!
Hare: The way we’re testing candidates on lateral thinking is pretty much invalid because there’s only one right answer and it’s the one we’ve already decided on. A better test of lateral thinking would be to give candidates some of the problems where lateral thinking was actually useful to us. And if we do this, we should be open to solutions that are different (or even better) than ours. Like your jumpsuit solution of the John problem.
Tortoise blushes
Tortoise: I think that sums it up well. And thanks.
Coyote: One thing I still feel weird about is treating lateral thinking as not that important.
Tortoise: I may have overstated my opposition a bit. I don’t think it’s unimportant. But I think there are many other skills that are more important and easier to test. Technical writing is a good example. It’s actually pretty easy to test someone’s technical writing and documentation abilities in an interview and that’s a skill a good programmer will use every day.
Hare: Or time estimation! I bet we could incorporate that really easily into the blackboard task.
Tortoise: Oh, that’s a really good one. I’m definitely stealing that for interviews I conduct in the future.
Coyote: I’ve got it!
The Tortoise and the Hare stare at him blankly.
Coyote: I’ve realized why I felt so bad about us not being enthusiastic about lateral thinking. I read a lot of science fiction and a lot of my heroes (like Ender, Breq, and Miles Vorkosigan) use lateral thinking to win. And you know how it is… when you read books like that, you want to imagine you’re like the hero. Admitting that lateral thinking isn’t that important to programmers feels like admitting I’m not like them.
Tortoise: Actually, I think Ender is the best example of convention being useful. A lot of what Ender did with Dragon army didn’t involve lateral thinking so much as it involved taking what Ender already knew worked from all of his experiments with his launch group practice sessions and putting it into systems where others could easily use it. This is the sort of thing you see really great programmers do. They make everyone else’s job easier by designing really good systems that transfer well. It was systems that let Ender win all of his battles but the last
Coyote: That’s a different way of looking at it.
Hare: It seems like in a lot of fields, lateral thinking is what makes people great, instead of really good. I’m think scientists and pro athletes, for example. And maybe that’s true in ours as well. But it also might be that what makes a really great programmer is their ability to build up systems that other members of their team can use.
Tortoise: And lateral thinking does help! Whoever it was on StackOverflow that came up with that answer, or whoever taught it to them, that person had to do some lateral thinking. And they’ve ended up saving a lot of programmers a lot of time with it.
Hare: But if we’re counting up total time saved, I guess Stack Overflow takes the cake, doesn’t it?
Tortoise: Yeah, Joel Spolsky and Jeff Atwood definitely showed how systems are incredibly useful to programmers.
Hare: Well now that that’s all cleared up, we’re actually out of questions. So do you have any questions for us?
Tortoise: So about your benefits package…

Footnotes:

[1] All puzzles in this dialogue taken from http://www.folj.com/lateral/ ^

[2] Specifically this question: http://stackoverflow.com/questions/6137986/javascript-roundoff-number-to-nearest-0-5 ^

Advice, Software

Resume Tips For Students

Posted on by Zach

I graduated from the University of Waterloo with a degree in Honours Nanotechnology Engineering in 2015. Like all engineering programs at UW, this is a coop program. Over the course of four coop terms, I submitted over a hundred resumes and did about 20 interviews.

After I dropped out of graduate school, moved back to Waterloo, and got a job at Alert Labs I suddenly found myself on the other side of equations. I’ve now had a chance to interview students and look at resumes. Hundreds of resumes. Do you know what looking at 200 resumes in a day does to a person? It’s not pretty.

Looking through all these resumes, I was struck by a bunch of self-defeating things that students did. Some of them I remembered doing myself. The double vision was… enlightening. I considered posting an angry anonymous rant on the UW subreddit, but with some helpful prodding, I decided to make a list of advice instead.

Note that all advice is context specific. These are tips that are guaranteed to work if you’re applying for a job and I’m looking at your resume. They’ll quite possibly work well for jobs reviewed by other UW alumni, who also understand the process from both sides. They’re also tips optimized for software jobs, because that’s what I’m hiring for and that’s what I have the most experience applying for. Follow my advice at your own peril.

As always, the views expressed here are my own.

Overall Strategy

Scientists used to partition animals into r-selected species and K-selected species (it refers to the constants the species ostensibly maximized in a population dynamics equation). K-selected species (like humans) have relatively few offspring, but put a lot of effort into each of these offspring. On the other hand, r-selected species (like rats) have a ton of offspring but give each of these offspring very little care.

Which strategy is superior depends a lot on environment.

In coop, it’s the same way. When you’re in 1A or 1B, it actually makes a lot of sense to have a few general resumes (that you still proof-read like mad) and send these out to as many companies as CECA will let you. As you gain experience and figure out what you want, it can pay dividends to become picky about which jobs you apply for and spend a lot of time crafting each resume to maximize the chances that you’ll get an interview.

r-Selection: Apply for all the jobs

If you’re in an early term and using r-selection, you should still spend some time looking at each job. You can send out a lot of resumes, but not an infinite number of resumes and a few heuristics can maximize your chances of being hired. You should probably avoid applying to intermediate and senior positions (the hiring manager may just ignore all first years).

If your resume is sparse, focus on QA jobs, or jobs in early stage companies that can’t afford to pay you very much; they’ll be the most likely to hire you if you lack some (or even most) of the requirements for the positions. Start-ups that are remunerating competitively because they need someone to hit the ground running will be much less likely to extend you an interview if you lack some of the skills they’ve listed.

In most cases, you won’t want to use a cover letter. The person reading it can tell instantly if you’re sending the same one to everyone (yes, even if you change the names), at which point it becomes mostly useless. If you’re using a form letter, the only reason to send one is if you want to prove to the employer that your writing skills are up to scratch. This means that your cover letter must be perfect. Reading it over a few times isn’t enough. Read it out loud twice, then pass it off to a friend to read. Then incorporate their edits and read it out loud twice more. If you don’t trust your own writing, bring it to the writing centre and have them help you.

Don’t be too married to r-selection though. If there’s a job that you’re really interested in, follow the K-selection advice and put together a really solid package.

K-Selection: Optimize your Resume

When you’re in your later terms, it can pay to be picky. Interviews are a huge time commitment and you don’t want to have to do 20 of them (I know people who’ve been in this situation and they did not enjoy it). Look through job postings carefully. From the information you have, imagine yourself working there. Are you happy? Fulfilled? Excited to go to work? If no, then pass.

In addition to optimizing your resume, you should write a unique cover letter for each job. How unique? My rule of thumb is that approximately half of the cover letter should be specific to the job. Be sure to mention whatever it was you imagined would make you happy at the job. Tell the hiring manager that you expect to be able to do your best job there because of _________. Highlight a skill from your resume that the employer is looking for and tell them (in one paragraph) how you used it in a previous coop term or personal project. Tell them the benefits that that company got from you applying that skill there. You want to sell them the idea that their life will be better if you’re working for them, doing that thing.

If you have any blemishes on your record (a failed coop term or low ranking), you can ignore it. This is easy mode and probably the safest bet. But if you’re feeling adventurous or think your dream job has high standards explain what happened. A reasonable explanation can move a resume from the reject pile to the interview pile. Owning up to failures shows maturity. Introspecting and planning on how to do better shows even more maturity. Trust me when I say most employers are looking to work with mature adults.

On your resume, judiciously prune references to skills that the company doesn’t care about. If there’s something you’re so proud of or skilled in that you don’t want to cut it even though it wasn’t in the posting, move it to the end of the skills list. Make it easy for them to see that you have framework X or language Y. When discussing your past coop terms, reference these skills/languages/frameworks. Give them confidence that you really know it.

If you have hard numbers on improvements that you’ve made, let people know. On my resume, I talk about a script that used to take six weeks to run and can now be run in two hours. Like I said above, you want them to believe that things at their company will be X% better with you working there.

Specific Nitpicks

Here I’ve collected every single resume “feature” that has made me groan over the past week. Please don’t do these things!

Microsoft Office

If I am interviewing you for a programming job, I expect you to know how to use Microsoft Office. Because you got into UW, I can safely assume that you know how to use Microsoft Office. Unless I specifically mention in my posting that I want you to know how to use Microsoft Office, you can use the real estate that mentioning it on your resume would have used to tell me about a skill I will actually care about. Save us both some time here.

I don’t care what CECA says, you are not helping yourself if you apply to a job at a software start-up (or Google, or Facebook, etc.) and take up valuable resume space talking about Microsoft Office. Not even Microsoft cares. Just don’t do it.

Familiar With…

Look, I too was a coop student. And sometimes I would see a really cool job with a technology I didn’t know much about. And I would write on my resume: “Familiar with Technology X”. I never did this with something I’d never used. But I stretched the definition of “familiar” pretty darn far.

I would formally apologize to every employer I did this to, except I’m now 98% sure they all knew exactly what I meant with “familiar with”. When I see your resume says “familiar with node.js”, I know right away that I can’t leave you unsupervised working on a node.js project. Familiar with really means “I used this for a week in class” or “I started to work on a project using this but got pulled off of it a day later”.

The worst part comes when you get to the interview. The most common beginning to a question about anything a student is “familiar with” is “well, to be honest with you…” followed by an explanation of why they only sort of know the language/technology and can’t give me a decent answer to the question. It’s frustrating and disappointing, especially when (against all logic) I trust that you’re actually familiar with it and you crash and burn in the interview.

I don’t have a great solution to this one, because the resume arms race makes it hard not to try and inflate what you know. I think the thing I tried to do (when I resisted the temptation to use “familiar with”) is to give context around a technology. Instead of “familiar with Perl”, I’d write “read and rewrote a Perl application”. Instead of “familiar with Angular.js”, I’d write “created a prototype application in Angular.js”.

Anyway, I guess all I really have to say is that you’re fooling no one with “familiar with” and you’re shooting yourself in the foot for interviews when you use it. If you have a foolproof solution to this problem, let me know!

Nitty Gritty Details

This is similar to and complementary with the previous point.

Anything you put on your resume is fair game for an interview question. Be prepared to expand and explain any acronym you use. Read over your resume and make sure you can do this. Actually do it. Don’t just think to yourself oh yeah, AFM, got that, no problem. Explain atomic force microscopy out loud. Notice how many times you say “um”. Ask yourself if the explanation was clear. If you aren’t satisfied with the answer, practice until you are. Remember that this is easy mode. There’s currently no pressure on you. If you’re struggling now, you’re going to crash and burn during an interview.

If you don’t have time to brush up, then remove the acronym or accept that if you get asked about it you’ll probably lose your shot at an offer (and have no one to blame but yourself). If you can’t explain one thing on your resume, I immediately lose faith in your ability to explain anything else on it. You don’t want me to start doubting your general competence, do you?

Machine Learning

This deserves a heading of its own, because it’s extremely irritating.

When you put down machine learning, you are telling me that you can name a couple machine learning algorithms and speak briefly about the advantages or disadvantages of each. You’re telling me you understand sensitivity and specificity and the receiver operating curve. You’re telling me that you understand overfitting and understand strategies to mitigate it.

If you’ve used someone else’s machine learning algorithm with no thought given to hyperparameter optimization, you don’t know machine learning. This is akin to saying “experience in word processor development” because you’ve used Microsoft Word. Please don’t do it.

I solemnly swear I will never hire someone who puts experience with machine learning on their resume and can’t answer basic questions about it and I doubt I’m the only one who feels this way.

Bullet Point Tense

It’s fairly standard to list your responsibilities at a previous job using bullet points.  I have no issues with this per se. But if you’re going to do this, please (for the love of all that is holy) make sure that you read over your bullet points afterwards.

The most common mistake I see students making here is mismatching tenses. Each bullet point should be in the same tense as the others. Ideally they should all be past tense, but present tense is acceptable as long as you’re consistent with it. If your first bullet point is “collaborate with stakeholders…”, your second cannot be “researched key customer requirements”.

If this doesn’t make sense to you, go talk to the fine people at the writing centre. They’ll be able to explain it better than this blog post can.

Also be careful about how you end bullet points. If one has punctuation, all the others need it too. They’re either sentences or stand-alone thoughts. Either is fine, but don’t use both. This is the sort of thing that 95% of people won’t notice and then the hiring manager for your dream job will and then they’ll start assuming that you don’t really care about details.

These seem like minor nitpicks. And they are! But your resume is more than a list of your skills. It’s a reflection on you. How can you expect me to trust that you’ll care about all the fine details of the job I have for you if you don’t care about them on your resume? How do you expect to convince me that you really do have the “excellent written communication skills” you just listed if you’re messing up basic grammar rules? If I hire you, I want to do it confident that I’ll be able to understand the documentation you write or the panicked 3AM messages you send me about taking the server down. In today’s increasingly text-based world, good written communication isn’t optional.

Bold and Italics

How many times have I used bold and italics so far? Not very many. If I suddenly use it, I’ll get your attention right away. This point is very important! See?

If you bold every skill on your resume, you’ve bolded no skills on your resume. Do this and all I see is this bad looking blur of bold text at the top. You’ve made me less interested in hunting for important skills, not more. Honestly, you can skip bold altogether if you just rearrange your skills so the ones I care about are right at the front. Even if I don’t consciously notice that you’ve helped me out (I probably will notice after slogging through 50 resumes that obstinately refused to do this, but still) I’ll subconsciously register that your skills seem to be a lot better suited for the position than everyone else’s.

If you’re going to use bold, use it only for the technologies that are listed in the job description or to highlight notable achievements. Bold the percentage you decreased outages by or the percentage you outperformed the typical coop by. If you have more than 8 or so words bolded on your whole resume, seriously consider removing some of the bold formatting.

Past Compensation

When we go to interview you, CECA gives us a handy dandy print-out that tells us how much students make (on average). We know roughly what your past compensation is. We know what we’re planning on paying you. Don’t bother telling us what you made during past coop terms. It’s wasted space and isn’t going to influence what we pay you. Just don’t.

School Projects

If you’re in first or second year and really need something to put on your resume, you can put school projects on it. But remember that we’re going to see resumes from your classmates. We’re very quickly going to catch on to the fact that you did that programming project you’ve dressed up as cool because the school made you, not because you wanted to. This makes it of limited value to us, except as a marker of some experience in a specific technology.

Try and write these sections to highlight the technology and what you learned about it. Or if you went above and beyond the project and added to it in your own time, tell us that. Otherwise use this section mainly for plugging white space in your layout and delete it as soon as you have enough work experience to fill a page. If you ever comes down to writing about a work term or writing about a project, do the work term unless the project lets you highlight a language that the job requires that you couldn’t otherwise highlight.

Hobbies

I swear that almost every student in Waterloo has three hobbies picked from a list of ten socially acceptable and academically interesting hobbies. Badminton, Martial Arts, Piano, Hockey, Soccer, Reading, Violin, Archery, Photography, and Video Game Design (which somewhat improbably seems to show up far more often than playing video games).

I have nothing against these hobbies. They’re all (except for soccer) perfectly fine ways to spend time. They also do absolutely nothing to differentiate you. If everyone else has the same hobbies as you, on some level I’m going to believe that you’re faceless and replaceable. Sure, I’ll intellectually know that you’re an individual with something unique to bring to my team. But after 200 resumes, I’m going to have trouble really believing it.

So tell me about the hobby that you’re really excited about but scared put on your resume. Make me remember you as “the student who was brave enough to put Magic: The Gathering on their resume”. Tell me about how you’ve done statistical analysis and stayed up all night trawling Wikipedia to make sure that you’d have the best fantasy hockey team in your league.

If your favourite thing to do genuinely is something really popular and you know that if you simply list it you’ll fade into the background, give me a deeper window into it. Don’t write me a novel, just give me one or two really genuine sentences that convince me that you can get excited about something. Then you’ll no longer be faceless coop applicant #43. You’ll be a person who I’m invested in and interested in hiring.

There’s one last advantage of doing a good job on the hobbies section of your resume. You might be asked about it in the interview. If you play this right, you can talk for a minute or two about a subject you’re extremely confident in and comfortable with. Interviews last a fixed time and those minutes might otherwise be spent grilling you about the nitty gritty details of your technical stack. This is a trade that will almost always come out in your favour, so make sure you can talk about any hobbies you list for at least one minute and make sure you can do it while being visibly excited.

Closing Thoughts

When I was in debate, we learned about the argument tree. It has leaves (these are your opponent’s facts), branches (these are your opponent’s points), and a trunk (this is the viewpoint that underlies your opponent’s whole argument). You have an axe and need to get rid of the tree.

It’s really safe but also fairly ineffective to cut at the leaves. You’ll probably end up doing nothing, in the end. It’s more effective (but riskier) to attack the branches, you may actually even get somewhere that way, but it’s slow going. It’s most effective to hack at the trunk. If you can pull this off (and you won’t always be able to) then you’re guaranteed a win (and you’ll have won with style).

(Incidentally, I recommend debate for anyone who wants to improve their interview skills – it really forces you to think on your feet and improvise and many debaters will be willing to work with you to cut down on verbal tics like “um” and “like”)

Trying to get a coop job has a similar risk/reward curve to debating. You can throw out a lot of acronyms and skills and try and convince the hiring manager that you meet the minimum requirements for the job. This doesn’t really backfire, but it also isn’t going to make the hiring manager excited about you; good enough might be enough to get you a job, but only if someone more interesting doesn’t come along.

You can point out all the ways you made life better at your past coop. This is riskier – maybe you pick metrics that the job you’re applying to doesn’t care about or they decide that you didn’t have the requisite number of three letter acronyms. But it can pay off big time. You can make the hiring manager start to be invested in the idea of a coop with your qualifications and abilities and less willing to settle for just good enough.

Or you can take the time to really craft your resume and cover letter into a story about how you – your skills, experience and personality will make life better and more fun if you’re hired. Now the hiring manager is invested in the idea of having you there. They won’t settle for anyone else, no matter how many acronyms are on their resume. They’ll fight their bosses to get you.

This won’t work everywhere. Some people will find you grating and that sucks. I mean, it’s probably better to find that out before you commit to working with them, but it still sucks. But when this works, it works. I’ve had friends offered extra salary if they ditch other offers. I’ve seen new coop positions created just for people who’ve pulled this off. If you can do this, you’re golden.

On Failure and Second Chances

I read through 200 resumes this week and 185 of them annoyed me in some way. Maybe they applied without any of the qualifications I was looking for. Maybe they said “familiar with” one too many times. Maybe they used a form cover letter, or addressed the cover letter to the wrong person. Whatever they did, I closed their resume in annoyance or disgust.

I don’t remember the name of a single person who annoyed me. If they were to take all this advice and apply again next year, they’d get an interview. In order to screw up memorably, you have to try. Like seriously try. Threaten to hurt us if we don’t interview you. Try and bribe us. Talk about how much smarter you are than us and how you could run our company better. Do one of those things and we’d remember you. But garden variety screw-ups just don’t cut it, not when I have 200 resumes to go through.

I remembered one name at the end of the process. Want to know why? They wrote an excellent cover letter that was clearly targeted right at us. They showed a sense of humour. They didn’t pad their resume at all. They mostly listed relevant skills. They did everything right, but it looked like I wouldn’t be able to interview them anyway, because they didn’t quite have the experience we were looking for.

That was the name I remembered.

Anyway, the point of this story is that if you make a good impression you’ll probably be remembered, but if you screw up a resume in a way that feels horrible to you, don’t worry. It’s a disaster to you, but to us it’s pretty routine. We’re not going to blacklist you.