I’m a developer, but I’ve always spent time helping with recruitment for the various companies I’ve been a part of. I’m even doing that to a lesser extend as a consultant. Based on this experience, I think I can say that we should stop saying that a developer doesn’t need a resume of any kind and that Github alone is enough. I thought this was a closed subject, that we stopped believing that Github is your developer portfolio, but I still see people applying with a Github account and almost getting offended if I ask if they have at least a Linkedin profile.
I’m not going into details regarding why not having something ressembling a resume is a poor idea on general. James Coglan already did it in the great article “Why GitHub is not your CV”, that can be summed up with this quote:
So really, your GitHub profile displays two things: how ‘influential’ you are, and how easily you can be coerced into constantly working. It’s honestly about as relevant to a decent hiring decision as your Klout score.
I also recommend Ashe Dryden’s article: “The Ethics of Unpaid Labor And The OSS Community“.
Instead in this article I’ll focus on why, if you apply to a job without something resembling a resume, you’re making the life of the person in front of you harder and generally make the whole process more painful than it needs to be.
Why A Resume Is Useful To Me
Of course, standing on the recruiter side, I can do without a perfectly formatted resume. However I do need a place to look up what you did before contacting me. A Linkedin page is fine, but it needs to be somewhat up to date and with more than just the company names. I don’t need this to be annoying, but because of multiple small problems that occurs when I don’t have this document.
Note: from now on if I mention “resume”, I really mean “something resembling a resume, meaning a timeline of experiences and list of skills with basic descriptions”. Linkedin is fine, so is a personnal website with a decent about me section.
Memory
I can end up talking to a lot of people about a position, and my memory is not perfect. It’s great to have a document that I can check to remember if you spent 1 year or 2 at company X, or if you do speak fluent german or not.
I have my notes, of course, but if I have to write down every single detail the interview process is going to be painful for the both of us. I’d rather listen to you and ask meaningful questions than write down the number of years you spent in a given company.
Multiple Interviewers
I never hired a developer without having them see at least a couple more people than myself. In this case I often brief the other interviewers in order to not have the candidate repeat over and over their previous experiences. If I don’t have something resembling a resume, this becomes an more tedious task.
Later, if you have a few interviewers seeing a few candidates, having a resume to look at when discussing is also more convevient. It’s a clearer starting point for discussion than just a name and our respective notes.
Better Interviews
Having a timeline of a candidate’s experiences is also a great way to guide a first interview. It’s easy to follow along when the candidate is explaining their background and previous positions. It also makes going back to something that was said earlier simpler, as company names, technologies, dates and projects are written down in front of me as we speak.
Having a resume can also lead to better conversations. For instance I could notice a past experience in a company that I know about, or a piece of technology you used that I’m interested in. Candidates without this would have to mention their whole work experience out loud in order to get the same effect.
Why Github Often Wastes My Time
If you look at my github account, you’ll see that it’s a mess.
There’s all kinds of randomness going on: my dotfiles, this site, a very old but somewhat popular jQuery plugin, terrible hackaton code, a few backups, a couple of forks that were merged (or not), projects I gave up on, projects still running, demo repositories for when I give classes…
I don’t really mind though, because I wouldn’t apply to a job with this. Most developers are just like me in this, most of our best work is private… but still, why so many people send their Github account when there is nothing relevant on there?
To be honest, I totally gave up on looking at Github unless the candidate explicitely points to a given repository. If I do browse the code on my own, it will always ends in a discusion like this one:
Me: I’ve looked at your Github account since you sent it with your application. On project Y I wondered why you made this choice…?
Candidate: That’s an old project I don’t even remember.
Me: Okay, well on project Z I found a couple of situations where I felt like the code was subpar. What lead you to write it this way?
Candidate: This project was done during a weekend, it’s hacked together so the code is terrible. I’d rather not talk about this one.
Me: Is there a repository I could look at?
Candidate: Not really, most of my best work is private.
Me: (ಠ_ಠ)
Looking At Code
To make it clear, I do want to look at code a candidate wrote. I value that way more than what they could do “on paper”, their past experiences and the university they attended 5 years ago.
That’s why I like to be able to look at relevant code rather than whatever is on the candidate’s Github. For instance, here’s what I usually ask a candidate to bring:
- Code written during a previous job
- Maintained open source code
- Pet project actually running in production
- Freelance work
- A homemade technical test done before the interview
- Technical tests made for other companies
From this starting point, we can then discuss tradeoffs, architecture choices, their understanding of the codebase, how they maintained it over time and so on.
I also value code written in a context closer to their future day job more than what I could ask the candidate to write on the spot. That’s why I don’t make developers write code in front of me, under pressure or ask them to write actual code on whiteboards…
I’d much rather discuss what they wrote in the past and other interesting technical topics. I feel like it makes for a more interesting interviewing experience and allows me to better judge how the candidate is going to perform in real situations: someone can be very good at interview riddles and coding puzzles under pressure, but still be a terrible developer.
Experience And Code
So really there are two subjects: past experiences and actual work accomplished. When I’m looking for a person to join my team, I want to know about about the two.
If you’re a prolific open source developer or a very junior programmer, I might find both on your Github. However, if you’re like most people, it’s better to stick to a resume or update your Linkedin.
Since you scrolled this far, you might be interested in some other things I wrote: