Resumes are dangerous
blog.alexmaccaw.com
blog.alexmaccaw.com
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.
Honest question, who's code would it be then?
EDIT: here's an example: http://legalblogwatch.typepad.com/legal_blog_watch/2011/01/w...
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
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.
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.
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.
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?
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.
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.
However like it or not you need to build up your github account.
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.
"...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.
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.
Not your, you're, it's a contraction, knowing the distinction shows you're skills are awesome.
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.
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.
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.
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.
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.
If you want people to see your value, you'll have to find a way to show it to them.
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.
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
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.
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.
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.
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.