Hacker News new | past | comments | ask | show | jobs | submit login
Resumes are dangerous (alexmaccaw.com)
54 points by maccman on April 30, 2012 | hide | past | favorite | 56 comments



I'm not a big fan of this development. There's a lot of software developers out there who work on projects for their employers that can't be open sourced. It also places those who lack free time to hack on code in their off hours (perhaps due to kids) at a disadvantage.

For students, it is not clear that the code they generate is their property so posting it on github is legally dangerous. I've also had professors say posting code is cheating.


Some blog entry called this the dark matter of software industry. Hundredts and thousands of developers, working away at hard problems without showing off online at every opportunity, because they are busy solving problems.


Speaking as someone involved in a hiring team for a developer, I am happy to discard people who are not demonstrating ability if I have other people who are. I am looking for every possible signal that differentiates candidates. Don't shoot yourself in the foot by not differentiating yourself.

Github demonstrates knowledge of (1) current trends in open source, (2) using source control, and (3) a project that can be looked over.

(Substitute github with bitbucket or whatever, I don't care that much).

With respect to engineers who are under restrictive IP contracts, all I can say is I'm sorry. You are likely to be shown up by others who demonstrate skills in ways you are unable (by contract) to. Do your best to leave and find a place where you can demonstrate your awesome.


>>Do your best to leave and find a place where you can demonstrate your awesome.

Not your, you're, it's a contraction, knowing the distinction shows you're skills are awesome.


I am unsure if you're being ironic, but the grandparent did use "your" correctly - if you take "awesome" as a thing someone possesses rather than as an adjective.


Possessing an awesome would be ironic because it would be so awesome.


I meant the 'awesome belonging to you'.

It's what I want to see when I look at your job application materials. If you don't have any, or can't show it, I can't appreciate that you are awesome and therefore won't follow up to talk with you.


I suppose that means for people who have restrictive agreements, networking and good CV skills are more important.

If you don't have a github (or whatever online presence is being sought after), you'll lean more heavily on places that use a CV, or through your network. Getting in through a network probably means you don't need the github.

Conversely, if you have an awesome github and an awesome network, then the fact you have a github is moot (unless people only know you because of it). You'll get hired anyway.

So the github only really matters for the portion of people who don't have a network, and are applying for companies who care about code they can review before you even talk to them, which is mostly the HN bubble, and not any megacorps.


You might say I'm in the HN bubble (I am, after all, reading it), but I work at a midsize corp growing towards megacorp, and github is a bonus to your resume here, especially with the more outward looking engineers.


Interesting take, there are places where :

"...those who lack free time to hack on code in their off hours (perhaps due to kids)..."

Is exactly what they want to know, it can be a discriminator for them. I pointed out to the VP of HR (for engineering) at Google that the peer review / committee system of performance analysis did not recognize 'work efficiency' only 'work quantity'. His counter was that it was a zero sum game, that if someone was getting the same amount done in 8 hrs a day as someone who was taking 12 hrs per day, then they were 'equivalent' contributors.

The blind spot however is that the efficient engineer isn't burning out, and the committees were much more impressed with quantity than efficiency so the comparison failed. I remind folks that one can always 'vote with their feet' and in the software industry that seems pretty doable these days.

Of course I also resonate with the notion that having a sample of code you can share with an interviewer and talk freely about that is longer than something you could pop out in an interview is a great thing. So often we are constrained about what we can share on what we're currently working on. A nice Github or Sourceforge project with a bit of meat on its bones can give you an excellent place to elaborate your design taste, thoughts, and choices.

So I think it is always a 'good thing' to have some solid samples of your work out there somewhere. Even if it means taking some extra time one year and spending a few weekends on it.


I think this would only be true for school projects or for research.

Most projects are relatively shallow and uninteresting--they're great for learning, but not good testaments of your skill. The sort of projects professors are going to worry about are the sort where you get an extremely detailed spec and a bunch of code to start from, and all you have to do is fill in the blanks. This sort of project is great for grading--everybody basically writes the same thing--but pretty meaningless otherwise.

If you have a really open-ended project where you get to come up with your own design and code everything yourself, I really doubt a professor would stop you from posting it. I'm working on a project like that right and the professor encourages us to open-source it.

If you're doing research, you may also have issues with copyright. I'm not sure you will, but it's plausible. However, at the very least, you'll be able to link to your papers, which is also good. That said, the research projects my friends are working on are all up on GitHub, so it clearly isn't an issue there.

Finally, especially as a student, you should have some nice side projects outside of class. I don't think you would have any problems posting code that you worked on entirely by yourself. And this is exactly the code that is most interesting.


There is also another and properly much bigger issue -- you end up hiring the people who are the best promoters, not the best coders.

And it is biased towards those who are in webdev, because they are those who share there source code most.

But there is properly nothing we can do to prevent this. Fortunately jobs aren't that hard to come by, these days.


>> For students, it is not clear that the code they generate is their property

Honest question, who's code would it be then?


A lot of university coding assignments are based on starter code provided by an instructor, often with step-by-step instructions for how to proceed. For example, the Pac-Man projects used in Berkeley's AI class (http://www-inst.eecs.berkeley.edu/~cs188/pacman/pacman.html) consist of a lot of pre-written scaffolding to set up a GUI, handle user input, etc., and even the AI portions are broken down in a well-thought-out way into just a few well-specified methods that students have to implement. This is an extreme example but the general pattern is common; my undergrad classes in compilers, OS, architecture, and networks all had project specifications provided by the instructor, sometimes with significant starter code.

I don't know how this works legally -- whether the code written belongs to the student or is considered a derivative work of the course materials -- but if you're trying to evaluate someone's abilities to design and build interesting programs, code written in this fashion is certainly less valuable than a project done entirely independently.


Isn't the same true for using all frameworks then? Surely people don't think every Rails app was written from the ground up?

FWIW I am indeed all lovey dovey about Open Source. I think all code should be "Open and Free". Of course I know that Google's algorithms benefit from being guarded, but a professor's scaffolding? Call me idealistic but I thought education was about you know... education? The more the merrier?


Yes, but Rails is a known quantity; everyone is aware of what's provided for you in a Rails app and can judge accordingly. It's harder to judge someone's work when you know it was written as a school project but you don't know which parts were theirs or how much guidance they were given.

As far as the educational values involved, many profs distribute their handouts and assignments relatively freely, e.g. the Berkley Pac-Man projects I linked above, but are wary of having solutions floating around online since that enables cheating. Personally I think this is probably a lost cause, but you can at least understand why they might be resistant to the idea of having students' solutions posted on github (and it's not reasonable to say that teachers should re-develop new projects every year; coming up with good projects is a huge amount of work and it usually makes much more sense to have a single set of course materials that you continue optimizing/refining over time).

Of course none of this is meant to apply to open-ended, student-driven class projects, or to work that students do on their own time while being enrolled in a university. I think most people would agree that such work is unambiguously the property of the students that produced it.


Rails has an explicit, permissive license. Most of the sample/starter code for school projects does not.



I'm not shooting the messenger, but if that is indeed the case, Universities are in quite a sad state =(


Why? Some prof worked hard to create the starter code for many assignments so the student could focus on a few key parts. After the student completes the few key parts of the assignment it is obvious it is a derivative work of the professor.

Also posting the solution online would obviously make it difficult to use for the next year and I don't think it is productive to make a professor remake an assignment every year when the could be focusing on refining lecture content.


At the risk of sounding difficult, all work is derivative and I think that's a beautiful thing, not a thing meant to be haggled over and fussed about.

But I do get the point of your second paragraph. Ideally students go to class for the sake of learning, so it doesn't make sense to blatantly cheat, but such is not often the case IRL.


It'd be great if the prof made the starter code available on github and the student's code was committed to a fork. It'd be quite easy to tell then who's work is whom's.


Not really. You write pacman as the lecturer tells you, the templates and direction (s)he gave you are not yours.

After two weeks sweat, take what you have learnt and write a game using pygame, or a browser based seduction game using anonymous twitter accounts and pinterest images. Anything really.

That's yours, the skills you have learnt are yours. Thank your lecturer publicly when you IPO


A lot of what I have worked on is closed source so lately I have been looking through all of my old files/hard drives looking for code to post to github. Either A) it is so old that it's a mess. Or B) it's from some personal project that I plan on keeping closed source.

However like it or not you need to build up your github account.


Just out of curiosity: why do you plan on keeping your personal projects closed source?


Not all of them, maybe I should have been more specific. By personal I was referring to apps I have For sale in the App store, apps I developed for clients etc.. What I have decided to do is start offering tutorials/projects showing the really difficult bits that are not on the web. You get pieces here and there but few offer the complete implementation. So I plan on helping pave the way for those who will follow. ;)


Because the fruit of his labor is up to him to do what he wants with.


That's not "because", that's an irrelevant factoid.


* it is not clear that the code they generate is their property*

Could you expand on this?

When you create something, barring some exception such as when you create it as a an employee, you own it. In certain cases, if the code is exactly implementing a narrow problem from a book there might be a question of it being a derivative work of the textbook itself, but when that is true it is probably not something worth publishing anyway. The other case would be that it is a shared copyright if the professor or another student significantly assited, which is fairly common in some grad work.

But the simple status of "student" does not change the rights to your own work. I have known more than one student to go on to publish work that is only a cleaned up version of an assignment and I have heard of others going on to start entire companies based on work they did as a student.


The situation you describe is sane, but it's not the way the law works. Take a look at the GPL for the most obvious example: derivative works are required by law to also be covered by the GPL.


While I think Alex is super smart and usually thoroughly enjoy his writing, I strongly disagree with this post for one reason - the way he looks to hire completely disregards learning, adaptation, and growth in a potential hire, and this is super important.

This is certainly not the first time I've encountered this strategy, in fact it seems to be the dominant mindset among successful companies - 'We are only going to hire people who are super good at what they do already. In fact, I want them to be better than me. We only want the best engineers out there, because we are one of the best companies out there, so we look extra carefully at your credentials and if they are not on par with industry leaders, you're out.' Right?

Wrong. If you invest in some stock for a company that is already doing well, there's a decent chance of you making money off it, sure. There's also a decent chance that you won't. It's a pretty standard and usually safe investment. Where the real money comes from is when you do research and find a company that's not already successful, but that you see a lot of promise in. This is (obviously) the entire driving force behind startups and venture capital, and the strategy behind the success of wildly successful investors.

You are winning when you see passion for learning and potential for growth in a candidate and pick them up based on that. This way you don't have to pay out as much as you would for someone that already is well recognized within the industry, and you get a lot more loyalty, and a chance to build this employee and support them along their path to greatness. In the end, if you can find these kinds of people and grab them earlier on, you profit far more than other companies that fight over the few current industry leaders and burn through money and effort to keep them on board.


We're moving into a world in which people will increasingly be judged by their work product online (e.g., Github commits, Quora answers, etc.) versus what they say about themselves (e.g., their resume or LinkedIn profile). This change won't be overnight and won't be complete of course but over time could create a virtuous cycle where the importance of having a better "living resume" (your online work/portfolio) will drive increased activity for all of those sites which will in turn make those living resumes more robust.


Eh.

I have a measely 150 rep on stackoverflow, have a long-dormant github account, and I don't know what Quora is. But I've worked on some interesting R&D projects over the years, and have written some fundamental code that will stay at my organization (an R&D lab) for a long time. In short, I think I'm a valuable person that is in no way reflected in my github/stackexchange accounts.


In which case, I'd encourage you to find some other way to demonstrate that value. E.g., blogging about your work. Beefing up your LinkedIn resume with testimonies from fellow engineers. Making an interesting toy project that you can publish.

If you want people to see your value, you'll have to find a way to show it to them.


Heh - probably. But I'm far too self-conscious to have a real blog for people to read, especially considering how harshly I judge other people based on their blogs... and think how it makes them look like arrogant pricks who I'd never want to work for.


I better start forking.


Next article will be titled "GitHub is dangerous". Just like in a resume, a candidate can easily embellish. Of course you can't trust what someone claims to know. You must verify it.


I don't think I would enjoy working for someone I was better than. I approach work as a learning experience. I usually pick to work for people I can learn from.


Heh -- Good way to flip it around.


Is it that disadvantageous to prefer BitBucket? When people say they check GitHub is that short for checking for publically available source code, or is Git Hub the one-stop-shop for coding credability?


This questions seems to come up every time there's an article on HN about the general trend of "Github is the new resume" and I really don't think it's that important, so I wouldn't worry about it. If a company asked you to send them a "Github URL" and you replied that you use Mercurial more, so all your code is on Bitbucket, and here's the URL, and then the company said they weren't interested in Mercurial users, would you really want to work there? (I think Bitbucket hosts Git now anyway so this is almost moot)

I can imagine a clueless recruiter doing that, but an engineer? There's no excuse for it, and I just don't think it's happening. I could be wrong of course, this is just speculation. Honestly, even if you sent a link to a SourceForge SVN or CVS repo (I guess that would be like emailing from a Hotmail address?) you might stand out because still relatively few resumes come attached with a portfolio.


I don't think BitBucket is a disadvantage. It also shouldn't bother if you link to your own hosted public repository when it's easily browsable and readable.


The problem with that is that my code tends to start out a mess -- get the shit done. And then it will be refactored into something that is prettish.


You're not testing enough. TDD and BDD coupled with making sure you follow Agile methods even with "hello world" sample code will prevent this. I would explain more but I am just a follower, A.K.A. a lemming. Got to go fork another RoR project on github. BRB. /s


Probably short. At least in the python world, Bitbucket was very popular until recently - and maybe still so.


GitHub is just shorthand for online open-source project hosting.


Regarding github, I have a lot of code on github, I store most of my code that's personal there. As you would imagine, most of it's crappy, or incomplete.

There are however multiple projects that I think deserve priority when looking through my github, but as far as I can tell, there is no way for me to make it clear what those are.

Additionally, if I fork a project, it's likely just so that I can add a fix and issue a pull request, that's additionally something I don't think people need to see.

I worry that someone going through my GitHub profile will see all of my old, incomplete work, and leave before they get to my better projects, any thoughts on how to resolve this.

As an example, here is a link to my GitHub: https://github.com/Arelius


> There are however multiple projects that I think deserve priority when looking through my github, but as far as I can tell, there is no way for me to make it clear what those are.

You should use your user page[1] to draw attention to the things you think are most important.

> Additionally, if I fork a project, it's likely just so that I can add a fix and issue a pull request, that's additionally something I don't think people need to see.

I disagree. Finding your way around a foreign code base enough to make the changes you need is an essential skill for a developer. Repositories you've forked and made pull requests for are a great way to demonstrate that.

[1]: http://help.github.com/pages/


> I disagree. Finding your way around a foreign code base enough to make the changes you need is an essential skill for a developer.

Sure, but a whole lot of the forks are like one line changes, they sit there taking up an entire repo, and aren't particularly useful.


If you're sending a resume to a potential employer, don't just provide a link to your Github account. Provide a few links directly to your best projects, the ones you think are worth looking at.


That's what I was thinking, but I'm not sure I've seen it very often.


Off-topic. How do the "kudos" work? Does it use my IP? Cookies? I tried on different devices on the same network and the vote didn't sync. I cleared my cache and it was still there.


I think it depends on the job market you're in. In the US and Europe an open-source profile is expected, but over here in Hong Kong its fairly uncommon. The good ones have either flown away to the US, or already been snatched up.

But, as Alex says, once we've sifted through CVs to find the best and invited them to interview, the paper doesn't matter anymore. Human interaction, pair programming, whatever, it's all more important than what's written on a piece of paper.


In my company (masterbranch.com) we target this problem. We help developers to showcase what they really know by tracking their code an presenting it in a nice way. We also offer companies reliable information about the candidates, that they can review before interviewing them.


It would be interesting to see how these ideas apply to other non-technical industries/professions.


Often, when I'm reading a resume I'm thinking: “This guy is great, look at all this experience. He clearly knows Ruby and JavaScript like the back of his hand, and this interview is just going to be a formality”

For what it's worth from the other side, I've been repeatedly amazed at how much interviewers have managed to read into or project onto my resume. And I'm not talking about recruiters, for whom a single keyword instance qualifies you as an "excellent match!" but actual working engineers and engineering managers.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: