Github is my resume | Hacker News Reader

Github is my resume

pydanny.blogspot.com

154 pointscraigkerstiens67 comments

A fair bit of discussion here, perhaps much of which misses the point:

A resume has just two purposes: first, to help you get an interview, and second, to get you past an HR hurdle.

It is not the job of your resume to go further than those objectives. In particular: it is not the job of your resume to establish a valuation for yourself. No one document can do that; in fact, no document can: you have to do it yourself, preferably face-to-face, by understanding in each interview what the "buttons" are, what the language of benefits that company speaks is, what things they find important, and how your prior experience can be phrased in ways that push those buttons and communicate those values.

More importantly: resumes, in any form, are bad at getting you interviews. A resume comes into play at the earliest part of the recruiting funnel, when the hiring team has the smallest number of cycles to spend on each candidate. Your primary strategy for dealing with recruiting funnels: jump the fucking line. It's never been easier to do this! Ten years ago, you'd have to track down someone who worked with someone who worked for someone at the same company as the hiring team. Today, in tech, you just go search Github for projects your hiring team contributes to and start sending pull requests.

Keep your resume simple. If Github does it for you, gets you in the door, great.

People spend a lot of time thinking about resumes. It's easy to see why. Resumes are the key ego document everyone in our field gets to work with. They are, admit it, fun to tinker with. That's fine. But don't obsess. The resume is literally the least important part of the search for your next role.

I don't do the initial screening, but I do use resume's as an ethics test and guideline for interviews. If you list a lot of random crud on your resume and don't know much about it then you don't get in period. In the end every team has a different process, but I don't care what you have in GitHub and I do care what's on your resume so don't get to infatuated with what you hear random people say on HN or anywhere else.

The less fodder you, as a candidate, give an interviewer for structuring the interview, the better.

In most companies, interviewers are trained to "screen" candidates with a series of tech-out questions (and maybe some culture-fit stuff).

As a candidate, your interests are best served by (gracefully) taking as much control over the interview as possible. Turn the interview around on the interviewer. Ask the interviewer questions about tech problems they've run into, and then ask if you can talk about how you'd address them. Guide the interview to questions that push the interviewer's buttons.

If you sit back and passively accept the interview as it's offered to you by a screener, you put yourself on a level playing field with everyone else being interviewed for the role. Which is a bad thing.

I want to echo Thomas's sentiment here about asking questions of the interviewer.

It really is of tremendous benefit while interviewing to be the one driving (or at least steering) the interview. Even aside from any psychological power dynamic, it's a really good way to make sure you get to cover the things you want to cover.

If you've ever come out of an interview and said "Oh man, hopefully that went good; but I wish they'd asked me to talk more about area 'X'.", you know it can be nerve-wracking.

Being able to have an actual conversation, where there's interplay between the interviewer and interviewee will do wonders for your anxiety level (which considering how stressful interviewing can be for some people, can be a big deal).

Agreed! The last few that interviewed me noticed I had a Github account and perused the projects just barely afaik- not enough to ask questions about any of it.

Github and any other open source repository you link to are a badge of "I did open source development". What the first page in Github, etc. looks like in that first 0.15 of a second of the 5-10 seconds they spend looking at it may be on average only 2% importance to the hiring decision.

Do NOT stop doing what you want to do or start paring projects down just for looks. Sure maybe it will help, but don't sacrifice your work and what you've done just to look GQ in an attempt to get a job. Instead, try to work on what you do have and make it better.

One of the most frustrating things for me, I feel, is that hardly any of the code I have written is on Github for various reasons (NDA, proprietary code, etc). So when an employer asks me for my Github, what do I do? Do I send him my account showing off my code from 3 years ago containing only a script I didn't really care about?

I don't mind a Github being used in conjunction with other resources (the projects I've worked on / Linkedin / etc), but god help me if it ever becomes the standard -- I'll be unemployable.

> One of the most frustrating things for me, I feel, is that hardly any of the code I have written is on Github for various reasons (NDA, proprietary code, etc). So when an employer asks me for my Github, what do I do? Do I send him the my account showing off my code from 3 years ago containing only a script I didn't really care about?

The not-so-easy answer is: find time to contribute to the open source community. This is difficult if your time is already spent though.

Weirdly, I find myself contributing to about 6 open source projects, and none are on github.

I imagine few large projects have moved their infrastructure to github. Therefore my github page is almost empty.

This is why I'm on Ohloh. You can just give them your Ohloh link instead and see a dashboard of your contributions across projects. And its free.

   This is difficult if your time is already spent though.

Exactly. In my spare time I program, but many times it's on client projects that are on top of the 40 hours I work at my job, both of which probably wouldn't want me to post my code on Github. I have a passion for programming, but I'd rather a potential employer focus on what I've done -- just because my Github is empty doesn't mean my portfolio is as well.

That goes for me too. In fact, you could flip the advice: if you're such a great and experienced programmer looking for work, why have you spent so much time being paid well to do commercial work? Why have you not spent your time working for your employer and resting outside of work?

When I've spoken to (good) recruiters, they've downplayed the whole github/blog thing. We might use that (they say), but it will depend very much on the job we're going for. Usually once I talk to a techie for a while they get a pretty good idea of what I'm about technically (and vice versa). If they're not a techie, then github/blog will be of only limited use.

Or don't, and just be really really good with marketable technologies. The opposite of your advice also holds: you can spend a whole lot of time doing excellent open source and still end up with a crappy job.

So you're saying that he would be a better prospective employee if he spent less time working on his primary job and instead spent more time writing other code? That seems totally counterintuitive to me.

He asked what to do if an employer asks for his Github and he has nothing current on it. I answered with "fill it with your open source contributions." You're free to draw whatever conclusions you want from that.

Not all employers care for open-source code samples. But the ones who do are looking to hire people with a deep passion for programming: developers with a passion so strong that they're willing to spend hours of their free time writing open-source libraries and contributing to the open-source world.

I really don't think you have much to worry about. A track record of open source contributions is one of many calling cards a developer can have today. The fact, however, is that there aren't enough excellent developers for all the roles that need them. It's a seller's market.

Having said all that: no matter what you've been doing for the last 5 years, proprietary or open source, most developers suck at "goal-directed" networking. One way to overcome that obstacle is to make targeted open source contributions to projects your preferred future employers pay attention to, as a way of meeting people who can recommend you for a role in the future. If you're like most developers, you may find this easier than the standard networking approach of asking people out for coffee, even if it involves extra coding effort.

I wonder how many employers actually search for (or would look at) GitHub repos? We are a bit biased here, right? Lots of folks working on bleeding edge projects leveraging lots of little open source projects--so, of course, we think "does candidate X have a GitHub profile?" But I reckon in many markets, many programmers might not even know GitHub exists.

Personally, I'd do some searching on a candidate, and would be rather happy to find code of theirs online, but I won't hold it against the candidate if the search doesn't find anything interesting.

That's my feeling too, that this stuff is hot for the startup / dotcom hiring people which is a minority of the programming jobs out there, which are mainly intranet business stuff.

My experience supports this. Most of the software we write is so far from the bleeding edge that you could safely lick it.

In all the years I've interviewed, I have only once interviewed someone with OSS experience (he was hired, BTW, but not specifically for that reason). I've seen resumes that listed OSS contributions that didn't make it past the phone screen though.

I've often wondered if it was just that many programmers don't think that their open source work is worth putting on a resume since it wasn't done in the context of a day job.

Whether you want it to be or not, Github is part of your online resume and smart employers look at it. I would recommend having an empty account rather than an account with 3 year old code that you don't care about.

Your account doesn't have to be filled with projects, but a few patches to open source projects you are using can be really valuable for someone who wants to read a little of your code before investing time and energy in an interview.

This is exactly why Github will not ever be the standard. It's fine to show off what you play around with in your spare time, but the very best and most productive workers actually won't have an extensive up-to-date Github repo. This is because they're been gainfully employed and have spent the vast majority of their coding time kicking ass at their real job.

In short, while people with impressive Github contributions can generally be good employees (but not always!), many good employees simply don't have time or interest for open source / side projects.

It's fine to show off what you play around with in your spare time, but the very best and most productive workers actually won't have an extensive up-to-date Github repo. This is because they're been gainfully employed and have spent the vast majority of their coding time kicking ass at their real job.

Coming from the Rails world, this isn't true. Through my job, I fix problems with Rails or plugins I encounter. This may only account for say two percent of my development time, but that is significant enough to have a trail of pull requests.

> This is because they're been gainfully employed and have spent the vast majority of their coding time kicking ass at their real job.

I disagree. I've fixed and contributed to projects I've been using in my real job. In fact, I found the bug while I was working on the real job.

I'm not sure that's what he's saying; I for one find my open source contributions decrease when I'm doing work I find fulfilling during the hours of 9-5...

Don't worry about it... at all.

Most of us work in jobs where we don't share our code with the public. Most of us work in jobs which take up all of our time, and we try to have a life away from the computer when we're not at work. That's what makes us interesting people.

Work is a social environment. If all you do all day is code at work, then come home and code all night, you're not going to be a very interesting person. Go see movies, read books, meet with others, meet a girl/boy, learn to cook, develop a hobby... etc.

If you have to show code in an interview, just take some of your proprietary code which shows that you know how to program, remove/obscure all business-specific information (inline docs, comments, variable names), and use that. Of course, don't select the one algorithm that makes your current company special, rather pick some typical/mundane code that shows what you can do.

The bottom line is that this is the situation that most people are in, and we understand this situation when we're interviewing you for our company. Don't sweat it.

Yeah well it is not and never will be mine. This isn't to say that I wouldn't want to use it to host software (I won't but only because bitbucket is free with private repos) but because I know that appearances matter. As does the ability to selectively show what you have -- you wouldn't want anybody to look at the repositories for that porn scraper you wrote, or that half-finished stuff or what you play around with in other languages.

Finally you will want to be able to have something in PDF format or that you can print and show to your prospective employers.

Apparently github is my de-facto resume, because I got emailed by a headhunter just the other day saying he found me on github, and my Java-related experience would be a real benefit to them.

Wait, Java-related experience? I'm pretty sure there's not a single line of Java in my entire github repo. Oh wait, that's not true - there's my trivial benchmark script that shows Java is slower than python in some cases. :)

I've gotten two kinds of offers because of my Github account. The first is a genuine, honest-to-goodness message written by a human in HR that thought my skills were a good match for their company.

The second arrived late last night and appears to be an automated message from Githire[1], though a real name was used in the From field.

I think this is a new trend and while I don't mind it at all now it could easily get out of hand.

[1] http://githire.com/

I just got an email from them today for a "Senior Java Developer" position. I can't figure out what the deal is, because I have a) very little public Java code anywhere (I have the roughout of a Swing GUI in my github repos) and b) no mention of Java on my resume at all.

Yeah, the "GitHub jobs" aren't well targetted, but that's just like Dice, etc. Recruiters are the real source of the spam, not the job site. Fog Creek's job site Careers 2.0 is pretty quiet, but when I do get something, it is usually a direct company hire that is also mismatched. As someone else said, if you want a good match, you need connections, or an excellent or lucky recruiter.

github complements your resume in providing evidence that you can write good code.

Anyone who's been employed for a while will not be able to share the bulk of their source code, and source code doesn't typically give a high-level overview of career development and accomplishments.

Agreed. Things people write for fun are often quite different from what they write for work. I've written a few compilers and interpreters for fun but that doesn't mean I have the chops to do it for a living. I could learn to do it, but toy languages differ greatly from SpiderMonkey, V8, or LLVM. It's the difference between Ruby <=1.8 and JRuby or Rubinius.

As somebody who doesn't use Github regularly, it's a horrible alternative to a resume. Looking at his profile[1] it's hard for me to figure out what he's actually done and it's a bigger time investment on my part. If somebody on my team forwarded me that link instead of a one page resume, I doubt I'd talk to him.

He has 58 public repos, but I can't see if he's had significant commits to them. Picking some commits at random from the activity doesn't help much either.

If you are going to restrict your job hunting to people who use GitHub and who contact you, it may be ideal, but why restrict your potential audience so dramatically?

[1] https://github.com/pydanny

Agreed. A large portion of "his" repos are forked from other people's. You can't tell what his level of contribution to any of them is at a glance. Also, he's got an absurd number of files for a project called "Hello World".

Perhaps a better alternative is to keep using GitHub to host your code, but then use your resume to highlight specific projects that you want to show to hiring managers. If they're really interested in you, they might look at some of your other stuff.

Actually you can tell, at a glance, how many commits are by the "owner" of a repo. They appear as dark blue in the timeline. If he has forked a project and made his own commits, his commits will show up as "owner" (e.g. for pydanny, he has made numerous commits to his fork of django-crispy-forms)

Ah, good call. I'm just used to only seeing dark blue, so I didn't look very closely.

You raise an excellent point. My Github account doesn't clearly indicate the other projects I've worked on that the Python/Django community knows I lead. Such efforts as https://github.com/opencomparison/opencomparison, which powers http://djangopackages.com. I have admin rights there and in retrospect, perhaps foolishly push directly there.

When I'm asked to provide code examples, I link to these projects. But now, in retrospect, I should fork the things I commit regularly to and provide that to possible employers.

That's is the idea behind Masterbranch (https://masterbranch.com). Masterbranch creates profiles based not only in information from GitHub but also other forges like BitBucket, GoogleCode, Sourceforge and almost any independent reachable repository out there (we support Hg, Git, SVN, and CVS).

Because not everyone has FOSS info we also have hooks to have information about private code without sharing the actual code so you don't have to worry about broken the IP, NDA, etc. And other stuff like StackOverflow reputation, etc. You can even give "free beers" to other developers as a thanks/kudos/good work

We are currently working on a new profile, less resume, more dashboard, you can take a look to it here https://masterbranch.com/drbrain/cool-new-stuff

So, the main idea is an identity (not just a resume) for the developers merging all their identities in one place and give them a tool (not only to find a new job) to stay connected to their peers, know what's hot on technology, discover interesting projects, etc.

we also have hooks to have information about private code without sharing the actual code

I'm interested- how do you achieve that?

Right now we use the webhooks on Github and Bitbucket. Webhooks send to Masterbranch information about the commit, the message, the files and the date of the commit but never the code, in that way we protect the privacy of the code. This allows us to have a taste about what you are working on.

Due to the feedback right now we plan to release tools to upload full commit history and also hooks for the SCMs without having to host the private code on Github on Bitbucket. (already working on the git hook https://github.com/masterbranch/Jolly-Roger)

I agree with Danny here. In fact, part of the reason we built Work for Pie is to address this issue.

I also agree with some of the other comments - Github certainly isn't the end all be all. But, we're all trending away from traditional education, and software developers are on the leading edge of this trend. There may be a fairly standard path for "finance guy," but great developers can (and often do) come from any background. Resourceful developers can learn all they need for free via sources outside of a CS degree someplace.

So the question for a company seeking great developers becomes "how do I evaluate these non-traditional folks?" Resumes don't get there, but open source work can work to fill that gap. It's certainly not key for everyone - there are plenty of folks who stand on their own without a public repo in site. But, increasingly, it replaces more traditional indicators of talent like CS degrees.

Just my 2 cents, and I'm admittedly a bit biased.

I haven't found CS degrees to be very well correlated with being able to program, so I think this need applies even to people who got an education in the normal way.

> I haven't found CS degrees to be very well correlated with being able to program,

That's only true if you artificially restrict your population. It's like saying that music degrees aren't well correlated with being able to play an instrument or sing, because most people I meet at my local jazz joint (including customers) can play an instrument, though only a minority has a music degree.

Right, what I mean is that they are not very well correlated among people who are applying to make software for my employer. I'm sure that a more uniform sampling would produce a very high correlation in favor of people with CS degrees, but it would also be a lot less like anyone's hiring process.

From the comments it seems like there are three points of view:

1) Yeah this is dead on. Employers should only care about the code you've written.

2) No your always need a resume because your job history is more important.

3) GitHub complements your resume.

I'd say that this is totally situational. It is like a cover letter. You position yourself for the jobs you want. A lot of startups would probably put more emphasis on your GitHub account then on a resume. If you want to get into the enterprise world then they'd probably care more about your resume.

None of this is needed. It is simply your way of showcasing yourself to get the job you want.

What GitHub (and others) are for the developer is leverage. There's nothing worse than going into a job interview that you know you are (over-) qualified for and being given fizzbuzz because the person interviewing you doesn't know if you are a rock star or a fraud.

Handing them your GitHub commit log lets you walk in on more equal terms. If they are interviewing you, they already think you're good enough for the position from a coding perspective.

It's fizzbuzz. Why would you optimize around it? Just write the silly fizzbuzz answer and move on. We don't "fizzbuzz". We have a more realistic interview challenge (with a similar purpose). But we apply it uniformly, even for candidates that come in with lots of code in their Github accounts.

Why? If they have code samples and you think they are good, why are you giving them a pop quiz?

Because of what kstenerud and robododo wrote below

http://news.ycombinator.com/item?id=3622191 http://news.ycombinator.com/item?id=3622441

Interviewers don't owe you anything. If you are over-qualified then within five minutes of talking you should be able to prove to them that you are worth skipping over the bullshit.

If the person still wants to go forward then that would decrease the value or working at that company in my mind.

To verify that they can bang out code when they need to, not just when they're in the right frame of mind to create code samples. Also, ours is domain specific and measures multiple things about the candidate (but the primary one is just that they can produce sane code).

In this case, we're talking about FizzBuzz. The point of FizzBuzz is that it's a test that can be passed by literally anyone with an elementary ability to code. Optimizing for it is silly. Just bang out the fizzbuzz answer (make fun of it if you like) and get on with your life.

I'm obviously against any quizzes in an interview; it puts the interviewer and the interviewee on unequal footing, but that's not the point in my comment. I'm not optimizing for fizzbuzz here. I'm optimizing for "I'm not some guy off the street here, here's some proof". I'm optimizing for "let's skip past the bullshit".

Except that it's not bullshit, at least not in the traditional sense. Think of it like your most basic unit test. Regardless of what the evidence suggests, can the candidate bang out a quick algorithm, without aid, in your presence?

Interviews are a HUGE time sink for companies; not just in the interview itself, but also in the examination of candidates, their resumes, their code, their references, discussions among team members to decide if they'll be a good fit, etc, etc. One interviewee can blow away two days work easy. So we're not in the mind to lose any more time than we have to.

Fizzbuzz is a sanity test. To the candidate it may seem absurd, but once as an interviewer you've dealt with enough fakers, or even people who honestly believe they can code and yet can't, you begin to appreciate the simple elegance of a 5 minute fizzbuzz test as a kick-off to the interview.

You're assuming that the person interviewing trusts your absolutely in your statement that that code is yours. They can't assume that. It would be irresponsible of them to just assume that that is proof of your abilities. Whilst fizzbuzz doesn't prove anything either, if you fail it then they know that you are lying. It's better than just blindly accepting it.

The unfortunate truth is that there are fraudsters out there who will attempt to cheat or bullshit their way in. Fizzbuzz is so utterly trivial that you could bang it out in a few minutes. And yet it's amazing how well it weeds out non-programmers, no matter how much they bamboozled over the phone or built up a web of deceit online. You should treat fizzbuzz or the like as a secret handshake, where you write it and then everyone nods with a grin as a member of the fold is recognized, after which the real interview begins.

Totally agree.

A shockingly small number of candidates I've interviewed have heard of fizzbuzz. The first time I mentioned it to someone, I assumed they already knew it and would just chuckle and crank it out. However, that's actually kind of rare.

When I do talk to a candidate and get that "knowing grin", my estimation of them jumps up a couple of notches. It seems to actually mean something outside of coder forums.

The real downer is how dismaying it as that candidates clearly have never prepared. How could they have done any research ahead of time and NOT seen fizzbuzz?

Actually I don't consider lack of exposure to fizzbuzz a problem. The whole point of it is that it's trivial to implement, even if you've never heard of it before. But a non-programmer (or a "programmer" with no grasp of simple algorithms) will struggle with it.

It's basically a "secret handshake" that non-programmers simply cannot do, and competent programmers can figure out in less than a minute.

Do you really think someone is going to fake a GitHub account, including thousands of commit messages? I just don't buy that. To me that's definitely enough.

If you take a look at my github account you might think it's nothing special. But what you'll also see is that I have several commits per day, despite working a 40 hour/week job and a 15 hour/week job. So at minimum it should be obvious that I really like coding. If you think my code sucks I'm fine with that, please don't invite me to your interview. But at least the company I apply for will know who I am going in.

I've examined a lot of github accounts while hiring, and seeing thousands of commits is rare. If I'm satisfied that there's no chance someone is faking, I'll forego fizzbuzz, but really in the end it's nothing more than a 5 minute formality (and I make a point of telling the candidate that it's just a formality and yes it's trivial, and we both laugh at the absurdity of the situation as he scribbles it up on the white board). At that point the real interview hasn't even started yet.

Summarizing the main points I've picked out of these comments. Anything I'm missing?

A) Github does not cover a lot work that is done because developers are prohibited by NDAs (for their day job) and/or don't have time/inclination to contribute to open source; furthermore OSS is less hot outside of silicon valley

B)Github is an important piece of an overall portfolio; for most employers it is not stand-alone in screening a candidate

C) A code portfolio (github or otherwise) is a complement to the information found in a resume

D) Resume should be used to highlight the most significant code contributions (in github or otherwise)

E)Control is important - developers should be able to hide some projects in order to control the image they want to project; it is important to position oneself for the specific jobs one is targeting

F)For hiring, you need a summary (that's easily printable) of everything that you bring to the table

G) For employers, interviewing is a huge time-sink; there's huge value in only bringing the most relevant people into an interview

I feel some of this discussion misses the point. To date the best predictor of the future is the past. And the best way to measure the past is by reviewing work done - not a self-declared history of yourself. If Github does not get you there, then creating some kind of show and tell for anyone to review is necessary. The other stuff you would assumed you can get out of a CV, ie cultural fit, etc you can only assess by meeting the person and working with him/her for a while. At the end of day Github is the best catch all for "show your work" for programmers

Candidate's only "resume" was code would be a huge red flag for me [I hire Python engineers btw]. Outside of startup / few persons / open source projects, code is actually a small part of an engineers job. And not that rare/hard of a skill.

Communication, being able to work on and contribute to a team (and not just a team of developers), understanding business, being able to estimate, being able to understand, articulate, and extract requirements from/to clients/non-technicals/management, etc, etc. Are all much more important and difficult to find.

I think your resume and GitHub account can complement each other — which is why I keep my resume on GitHub :)

I had mixed feelings about making its history publicly available, but I’ve come to agree with the OP — how you’ve changed is at least as important as what you are right now.

I tend to agree with this point of view: whiteboard interviews fail to predict how you will write real code once you are hired, your actual code is definitely a better indicator.

Asking candidates their github usernames is starting to seem a common trend, in my experience.

I have seen a lot of articles on HN that would suggest that someone somewhere is using github for hiring, but I have not heard of anyone actually doing it.

A corollary: Github is the first thing we look at when someone applies for a job and we do a cursory review of it before reaching out to an engineer.

The door swings both ways though: forking lots of projects / not understanding Git are red flags.

So what happens if someone is employed? Do you just not hire them? Do you expect your employees to spend lots of time coding random stuff outside of work? That's not generally a quality I would put a lot of weight on.

GitHub is the best resume. I've been saying that for years! http://news.ycombinator.com/item?id=1472985

Reply on news.ycombinator.com