Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: Recruiters want people who do side projects, yet contracts forbid them?
344 points by uVacCXNiiJCTnYB on July 15, 2021 | hide | past | favorite | 223 comments
I was reading this [Joel on software essay](https://www.joelonsoftware.com/2016/12/09/developers-side-projects/) about employment contracts and side prrojects after it was mentioned in another post here.

It's been frustrating me for a long time that most companies when hiring are looking for people who do lots of side projects and open source work, yet when you are actually employed, you will usually have a contract forbidding you from having side activities, or potentially trying to grab copyright forr what you do on the side.

Most companies also don't let their employees open source their code written at work too.

I get that there is a sort of common understanding between employers and employees that lets people have small side projects, but I've never liked the fact that on paper companies can easily claim ownership of them if they become worth it.

In a lot of jobs, people end up in a situation where they are actively discouraged from doing anything on the side because it's always hard to know if they're even allowed. Learning new skills, having side projects and doing open source is valued in hiring, but strongly discouraged and sometimes impossible when having a job.

Are there any solutions to this problem? Curious what people's thoughts are.



> It's been frustrating me for a long time that most companies when hiring are looking for people who do lots of side projects and open source work,

This is a myth.

The number of candidates I interview who have side projects worth looking at or open source contributions is maybe 1-in-10 at most. Any company that requires candidates to have significant open source contributions is going to have a hard time hiring, because it’s not very common.

Really, the only time side projects are valuable is when someone needs to fill gaps in their resume. For example, if all of your prior experience was writing PHP backend code but you wanted to apply to a React front-end role, it could be helpful to have something like a React TODO app in your GitHub profile to show that you have some minimal experience with React and front-end work. You don’t need a massive open-source contribution that takes months and months of free time, just something small to show that you have some amount of experience that isn’t reflected in your resume.

The side project myth is getting out of control. Most recruiters and hiring managers will never even open your GitHub profile.


Agreed; and there's also a selection bias: The most visible, active, HackerNews population is likely to be (for whatever reason) more involved in opensource and side projects.

Whereas, in the overall population of IT workers, that percentage will be far far smaller.

For what little it's worth - I'm now a middle-manager (ick) in a traditional large IT company (ick ick), and neither myself nor the recruiting / HR teams I work with have ever once looked for, demanded, or even seen side projects. The UNIX SYSADMINs, Oracle & DB2 DBAs, VMWare specialists, application developers, testers, etc... they're all dedicated professionals but not necessarily zealots. Some of them will tinker and do certs and play with stuff off hours, most of them don't, but all I strictly care about is can you do your actual job professionally when and where I'm paying you. We do encourage learning, and have incentives for taking courses, reading books, etc. But we don't expect you to do unpaid work. As a sibling comment indicated, on operations side we work hard enough that I encourage team members to unwind and take care of their family, needs, hobbies, mental health, life goals etc when they're offline.

(My personal 100 Croatian Lipa, all opinions are my own, etc :-)


Careful with the denominations man, I thought the exchange rate crashed to 100 TRY for 'ten cents!'


Good point, corrected! :->


Funny how the FAANG companies never make open source work a requirement, but every once in a while you get a recruiter reaching out from AcmeStartup, having just raised their Series A, listing requirements that boil down to:

* Must be a rock star, experienced developer with at least 100 years experience, but also not too old

* Must have previous experience as lead developer of open projects such as Postgres, Linux, LibreOffice or similar, in addition to full time employment

* Must be willing to work for significant below market wages in exchange for a lottery ticket that might be worth billions


> Funny how the FAANG companies never make open source work a requirement

When I got rejected from Google the feedback was I should do more open source work.


It's a non-commital, actionable, non-specific, diplomatic answer, that is a nicer way of saying: "Practice more."

If an interviewee reached out to me for feedback, and I weren't comfortable giving honest feedback[1], that's probably what I would tell them.

[1] There is no reason I should ever be comfortable giving honest feedback, every bit of interviewer training anyone has ever taken will tell you as much.


> It's a non-commital, actionable, non-specific, diplomatic answer, that is a nicer way of saying: "Practice more."

Yeah it didn't even make sense so I'm sure it was a generic 'you're not good enough' answer. I had hundreds of thousands of lines in a major open source project at the time. Not sure I could really do any more anyway!


they gave you feedback?


After I asked yes. It was given in-person not formally in writing.


Salesforce gave me feedback


all of the ones i know of that did this, ended up hiring some guy that had very strange expectations of what code should look like, coded the company into a corner and the whole thing flopped. ive now had to come in and replace two of these types, rewrite the code and get the company functioning once scale started to happen. ive found that often those with really impressive resume(like the over funded startups like), have a very limited skill set making them not the best candidates for lead positions anyhow.


Then they have early equity, get rich after you fix it, and everyone thinks they're smart.


exactly! the CTO that replaced me, sure thinks he is cool. but i know the code base hasnt changed much and i discovered my SU ssh keys were still working 5 years later. but i bet he got a lot less equity then i walked from.


> Any company that requires candidates to have significant open source contributions is going to have a hard time hiring, because it’s not very common.

Nope.

Logical fallacy.

FAANG needs to hire thousands. Startups I've been at need to hire maybe 1-3 people at a time. Best CEOs I've met spent a ton of time recruiting those 1-3. Best strategy is to look at something others aren't looking at -- any other source of signal. If your hiring process is like FAANG, you're competing with $350k+ compensation packages. If you can find good developers who FAANG can't, and there are plenty, you'll have a much easier time.

A hiring process which selects for 10% or even 1% is plenty fine for a startup. 1% of developers in the US nets you 3000 people.

Best managers I've worked with hire through side channels which FAANG doesn't look at. If I'm a startup CEO/CTO/etc. I can afford to read code in your github. FAANG can't. Indeed, I can afford to browse github to find good people doing similar work, and work on getting them to join.

I'm not going to post my favorite ways to hire, since they'll lose signal if more people adopt them, but:

(1) they typically find on the order of a dozen people (and exclude far more than 1:10)

(2) all the people they find tend to be good

(3) I'll usually need to extended 3-4 job offers before someone takes one


> Best strategy is to look at something others aren't looking at -- any other source of signal.

Better's CTO has several blog articles on this -- a great read!

How to hire smarter than the market: a toy model[1]

Interviewing is a noisy prediction problem[2]

1: https://erikbern.com/2020/01/13/how-to-hire-smarter-than-the...

2: https://erikbern.com/2018/05/02/interviewing-is-a-noisy-pred...


Yeah, I've had my Github or other related things often mentioned by companies headhunting, even though I don't have _that_ much on it.

I literally received a job offer not long ago from a very high profile startup that only has a handful of employees, based on my Github


> The side project myth is getting out of control. Most recruiters and hiring managers will never even open your GitHub profile.

I once interviewed someone who listed authorship of a paper on his résumé. I skimmed it and, curious, asked a question about it in the interview. He looked surprised and told me I was the only person who'd ever even mentioned it.


Most interviewing I've been involved with from large FAANG companies to smaller IT shops basically are just running around with their heads cut off when it comes to interviews. They get resumes from HR, skim them to see if the person is even in the right ballpark, cc: the team asking "yes/no?", then proceed to schedule an interview whenever everyone on the invite list has an open slot.

Everyone then proceeds to examine said resume closer ~10 mins prior to the meeting when their email pings them that they have an upcoming interview scheduled.


This was one of the most fascinating things when I joined the workforce. Schoolteachers all seemed prepared, the world was all neatly scheduled, and they claimed that the real world was even more strict about things.

The most wrong thing I have been told about adulthood. Doing homework at the last minute is hardly just a kids thing.


I'm in my mid 30s. High school—in which I was not, notably, bullied or anything like that—was the most stressful, mentally-unhealthy, and busiest part of my life, to be sustained for more than a few weeks in a row. The only thing that's even come close is having multiple young kids at once, plus a job, and that's still not as bad. College was a vacation.

Meanwhile, adults were telling me it was the best time of my life, or that if I was stressed out and struggling now, just wait until I got to the "real world".

LOL, WTF? The real world is so much easier and less demanding. Even the couple times over Summers or early on when I worked low-wage unskilled jobs, it was easier and less stressful. All high school did was give me mental problems and a decade of nightmares.


For me college was the most stressful. High school was a breeze then all the small anxieties I had in high school just got amplified in university. A lot of it was fear of failure. In highschool you get a bad grade it goes in your nebulous "permanent record"

I went to an expensive out of state school and it just felt like the stakes were so much higher. A bad exam could lead to a low GPA, loss of scholarship, being pushed out a program or major, academic probation, etc.

In the working world I met so many successful people who failed at some point, have a criminal record, poor credit scores, bad employment records, etc. and it never seems to go as bad as it's portrayed.

Even creditors don't scare me anymore. I just tell em to fuck off, verify the debt, and never contact me by phone ever again. A younger me would freak out about my credit score if a collector called. Because I thought that's what mature adults worry about.


For me College was High School but more. The big thing that killed me in college was multiple professor assigning a big collaborative out-of-class project each semester seemingly on the assumption that none of my other professors would do something like that. So I'm trying to coordinate three different big projects with three different sets of students and keeping them all straight, while also trying to learn the underlying concepts. Oh and there is regular homework on top of that.

In the real world I'm generally only working one project at a time with only one group of people. And crucially we can fire people from the project who don't contribute.


Also, in my case, the projects that I found most interesting were those with less scoring value or on what people referred to "easy disciplines", those whose professors didn't bully/pressure us into delivering high quality work. Most of nightmares were doing boring projects which I thought and later confirmed to be majorly bullcrap.


I'm curious, what sort of program were you in that had professors assigning "big collaborative out-of-class projects"?


Mine was CS. Build an application that takes in topo data and produces a 3D plot of the output and allows the user to edit the data on the fly.

Remember this was in the late 90s so it was all OpenGL immediate mode and I didn't have a 3D accelerator so it had to run at a reasonable framerate on a 75Mhz CPU. Luckily we didn't have to texture anything, flat shaded polys were fine.

Another project was a web application with a database backend that was basically just IMDB. Of course this was the 90s so it was CGI.

Sadly there was no Git either. CVS was it, but since everybody was on dialup modem and there were not cloud services you could use it didn't work so well. One had to be good at compartmentalizing mostly. One guy would work on one part and someone else would work on a totally different part and integration was always fun.


Not OP, but engineering did a lot of it.


You're just lucky that things in your life aligned in the right way and you ended up adapted to adult life. What would happen if you couldn't have this job, lower salary, bad management, bad work conditions?


I've worked low-wage jobs and stopped the gas pump before my tank is full because I can't afford more. It's still way lower-stress than high school. It's not even close.


Yep. I do so much less work now that I am out of high school. I work fewer hours. Deadlines are less strict. Protocol is less strict.

Granted, I went to a pressure filled high school, but nothing came close to being as demanding as that, even engineering school.


I think the main problem with high school is that it wastes an absolute shitload of time. About 8 hours of your day shot actually in school, most of which is extremely low value or idle, and then (in my case, at what I think was a pretty middle-of-the-road school) 60+ minutes of homework on top of that every single day, which you're to do after you're already mentally beat from the intense boredom and "pay attention at all times or get in trouble" atmosphere of the rest of the day, with no option to defer it until you don't feel quite as much like your brain is running out through your ears.

As a staunch advocate of teaching the humanities and someone who thinks the "what k-12 education needs is math education that looks more like what the 0.1% of people who are math nerds wish they'd been taught" folks are dead wrong, I still think high schools ought to re-consider having every class be the same length, and maybe cut some of their social studies and history entirely (because it's almost never well-taught enough to be worthwhile) so the homework portion of mid- and high-level math classes can be brought into the school day proper. It'd be a much better use of time, and I think having a teacher available for questions and guidance during "homework" time would do wonders for math comprehension and test scores.

Though how schools would justify giving their coaches full teacher salaries without as many history and social studies classes for them to teach, is an open question.


Since high school, no one has stopped me to check if I was wearing panties before going into a work-sanctioned party.

But at my high school, they did.


You quickly end up not even looking at it 10 minutes before and reading the resume during the interview


"Tell me a little bit about yourself" is the phrase, isn't it?


Definitely have witnessed this many times


Maybe it's because I am hiring in data science, but that's the first place I go to in order to be able to ask deeper questions about what someone knows about. There are some interesting aspects of co-authorship though. A few years ago, I ran into a guy who did not understand the key aspects of a network security paper where he was the primary author. As I kept asking him about, he admitted he didn't know much about the topic!


I didn't do much of research and went straight away into employment. But my wife did and ended up in a bunch of papers in the co-authors just for helping out with a small part of the stuff (sometimes she really was surprised when she found out). So in a way one cannot expect her to know every detailed corner of the papers she has co-authored.


That's why I mentioned the person as being the primary author.


time dependent; i try and spend an hour pre-interview skimming any projects/papers in prep. "Why did you do X?" even when it's a high level/simple question gets the person talking well I think.


Adding to this - I did interviews for about six months and I don't think I ever saw a candidate who had a significant side project or open source contributions (at least not in the last couple years). It signals a potentially strong candidate, but I'd never weeded out someone for not having it.


I stopped talking about them because no one ever cares. Removed from resume and everything. So it's a bit hard to tell if I have side projects, you would have to ask. Nearly all of my skills are from side projects.


I dunno, I'm pretty sure I was hired without technical interview on the power of my GitHub profile. This is for a small startup (post-series-A, pre-series-B), programming in a slightly-less-popular-but-gaining-in-popularity language. Pre job-search I pinned all of my repos (the most popular ones to the top) in that language.

I was sure to carve out exceptions for all of my side projects in my employment contract, they did not argue about it.


The interview for my current job was basically reviewing my GitHub projects and discussing design decisions. I really enjoyed that process but I can also see how that isn't really viable in most cases (A lot of people don't have side projects, nor should they have to IMO).


Companies don't want people who have side projects and open source contributions worth looking at. They just want people who have side projects.

Finding someone who'll learn new things in their spare time for fun is much cheaper than training.


Yes, it is much cheaper than training once employed; however, the company should view training employees in new technologies as something that gives the company a competitive advantage. Technology ages pretty quickly, and if you want to stay at the forefront of technology as a company, then it might be a good idea to encourage your employees to use some of their work time to invest in learning the new tools that will push the company forward. Yes, they might leave once they have "leveled-up"; however, one alternative is that they come to the company and never really grow beyond the skills you initially required but may no longer need.


It's been a conversation in every interview. It's no requirement, but it's made every job easy to get.


I’ve had the same experience too.

A side project is interesting, shows initiative, and if it comes down to you and another otherwise equal candidate - it may well be the deciding factor in a hiring decision.

On top of that, hiring aside: the skills and expertise I’ve gained from a side project have been invaluable, and even for this reason alone I’d say it has been well worth it.


Yes, this.

Most of the things I've had to do at work are very mundane things. Many boil down to shoveling JSONs around from one system to another or dealing with another former coder's bullshit. The actually interesting, hard tech knowledge I have comes mostly from spare time explorations.

I was asked at an interview about CANbus once, and that's not something I would have known from work, but I aced the question because I did quite a bit of side project hacking at reading a car's sensors.


1. As a hiring manager that can code, I'd always open your GitHub if you put it prominently in your application.

2. If there was a lot of work on your GitHub or a really interesting project, I'd riffle through it.

3. If you had a bunch of good public code, that was a good signal, and you'd likely get an interview.

If you didn't put a GitHub profile, no problem. If you put one that was blank, then you at least lost some time from my review of your application having me click through, so it probably hurt you at least a minor amount.


"The side project myth is getting out of control. Most recruiters and hiring managers will never even open your GitHub profile."

I'm pretty sure some job seekers have figured this out, because I've seen some threadbare github repos put forth on resumes.

I also see a related strategy where they're populated, but in a way that will fool someone who isn't familiar with how GitHub works. I always open them if you give them to me because even a glance can tell me a lot, and I've seen a number now that are basically three-ish forked repos, among which there is maybe one commit from the user total that makes a small documentation change or something. I'm thinking some job seekers may have noticed that it's easy to build a github profile in which you have a lot of impressive stuff on it, but if you dig in, the job seeker isn't responsible for any of it. They just pushed "fork" on a few repos and a token commit somewhere.

I reluctantly suggest that this is probably a good strategy in general, though it may knock you out of the running with an interview with anyone clueful enough to notice this strategy, so, you know, consider the costs & benefits for your situation.


I'd say the most important factors that recruiters look at are:

1) current company tier 2) roughly relevant experience (in broad strokes - frontend or backend) 3) university tier (less relevant as you gain work experience) 4) a distant fourth is hackathon/side-project experience (though this is quite useful for college students)


Yup this. I've interviewed a bunch of people and been on a bunch of post-interview discussions of candidates. I've never looked at or asked about side projects, and nobody else has ever mentioned anything about the candidates' side projects either.

From an interviewer's standpoint, it's much better to have a standard set of questions that you give every candidate, so you can judge candidates against each other relatively fairly and objectively. Assuming a candidate has any side projects that demonstrate any expertise at all, it's a ton of work to dig into one of them enough to get an idea of how that person works. It's almost never worth the time, just ask your standard questions instead.


"The number of candidates I interview who have side projects worth looking at or open source contributions is maybe 1-in-10 at most."

It depends on what they are looking for. Some managers don't care what the project is. They want to see that you can learn new things, have a creative mind, have spare time (that they can hopefully capitalize on), etc.

Prior professional work is the important part, but personal projects become important if you're straight out of college. I know my Android apps helped me get a job. They never looked at the code, but I was able to demo the apps right on my phone and comment on some basic stuff.


I actually encourage the people I hire to not work on tech projects on the side. Go take up an artistic hobby or just go play with your kid. Unplugging from work is healthy; grinding side projects until you burn out is not.


Coding is my artistic hobby. :)


Which is a good way to burn out on tech in your early 30s! Speaking from experience here — using the thing you do to make a living as a creative escape isn’t really much of an escape.


I'm 50.


> The side project myth is getting out of control. Most recruiters and hiring managers will never even open your GitHub profile.

For many candidates one just finds fairly empty repositories with 3-4 commits, sometimes Jupiter notebooks from a coursera course, etc. I hardly find it interesting.

1 in 20 candidates may actually mention an open-source project they contribute to or started and I think this is interesting.


Maybe we should turn the premise around. I agree that most recruiters and hiring manages won't look at your side projects.

But as a prospective employee, I'd want to work at a place where those count. I want colleagues who are passionate about their tools and tech. Not just people who churn out "solutions" and "applications" for someone else's problem in a Blub language. I want to work at a place where people appreciate open source contributions, because that's not a place where people violate the GPL or do the minimum neccessary to appease the lawyers. I want to work at a place where people appreciate design taste and are happy that I put in a mere half day more work to make the product polished, instead of rushing it to the door prematurely (in chase of profit now, but detrimentally long term).

So, as a picky job searcher, I would totally put up a portfolio and clean up my GitHub. Even if only to see if they notice.


> Most recruiters and hiring managers will never even open your GitHub profile.

Tech hiring, and most hiring really, is broken.


I dunno. I've had two initial interviews with two different companies in the same short spane of time, where I mentioned that I was trying to gradually adopt functional programming in my Typescript codebases, using fp-ts ecosystem. In both of those interviews they immediately navigated there and noticed that the latest commit in the repository was mine. Even though I immediately told them that it was a minor documentation issue and I don't have major open source contributions (my most popular repo has about 15 stars, so I'm a pretty below-or-average developer in that regard), they still seemed impressed.


Agreed. It's not true anymore. It was true maybe 5 to 10 years ago; especially for startups.


> The side project myth is getting out of control.

I was rejected in an interview last year within seconds of the interview starting because my answer to "what would you do if you suddenly had a bunch of free time" was not relevant enough to the job.

For the record, my answer was that I'd learn basic 2D animation, because I have a deep respect for the people who do it, and I have no real clue how it's done. I also had relevant education on my CV, and the interview was for a graduate position.

That most places are looking for side projects may be a myth; there certainly are, however, at least some places that look for them.


Sorry you experienced that. As a hiring manager I would think that's pretty cool you want to learn 2D animation even if it has nothing to do with the day job. The fact that you have a desire to learn a skill should be desirable to a hiring manager IMO.


When you say “graduate position” do you mean a position meant for a college graduate, or a position in a Masters or PhD program at a university?


Graduate typically means bachelor, though masters may apply.

PhDs typically walk into senior roles depending on what they did for their thesis and what types of code they developed.


>This is a myth. The number of candidates I interview who have side projects worth looking at or open source contributions is maybe 1-in-10 at most.

It's not a myth depending on the industry (software as profit-center vs cost-center) -- or type of company (startup vs mature company).

E.g. HN skews towards startups so the excerpts from the most recent "Who is hiring?" thread[1] often mention Github profile as desirable (but not mandatory).

On the other hand, the programming where IT-as-a-cost-center where development is CRUD work like moving zipcode field on a webpage ... those types of jobs advertised on Monster.com won't mention that they're looking for Github side projects.

All that said... with real-life statistics being what they are... Since most programmers don't have Github side projects, it means that hiring managers that asked for Github side projects may end up hiring 100% staff with no side projects -- because those were the only hiring candidates that applied.

Some excerts from the most recent "Who is hiring?" thread[1]:

>To apply, please send an up-to-date: [...] - Personal website, GitHub profile, or any representative examples of code you have written recently that reflect your engineering capabilities -- https://news.ycombinator.com/item?id=27818013

>Please provide a CV and links to previous work or projects, ideally with contributions visible on Github. -- https://news.ycombinator.com/item?id=27700557

>Please contact evan.scholl@bmc-group.co.jp with your resume. Not required, but side projects and github contributions are helpful and appreciated. -- https://news.ycombinator.com/item?id=27699747

>To apply, send your CV with your GitHub profile and an answer to the below questions to work @ fingerprintjs.com -- https://news.ycombinator.com/item?id=27703097

>Interested? We want to hear from you! Please send resume, Github, or LinkedIn to jobs@blackbird.us. -- https://news.ycombinator.com/item?id=27701022

[1] https://news.ycombinator.com/item?id=27699704


Most of those quotes you selected are very clear that GitHub projects are not required, but will be looked at if you have something to share.

The myth is that most companies only want people with lots of side projects.

That doesn’t mean that there aren’t any companies who will take side projects into consideration, as in your examples. The myth is that side projects are a prerequisite for getting the job, which isn’t even true in the examples you selected.


>The myth is that most companies only want people with lots of side projects. [...] The myth is that side projects are a prerequisite for getting the job,

I do understand your point but just to be pedantic about interpreting op's phrasing of "are looking for people who do lots of side projects"...

I've personally never interpreted that to mean "if you don't have a Github profile, you are unhireable" so the "looking for people" didn't mean prerequisite but simply a weighting to help choose between candidates.

The Who's Hiring excerpts of Github projects being desirable-not-mandatory seemed to match the intended meaning of the op's premise even if their exact phrasing doesn't satisfy language lawyers and makes them appear naive.


As someone who hires for development-as-a-cost-center I see side projects as a demonstration of interest in software development. I don't need to see a good side project, I just like to hear of one existing. I don't necessarily need passion, but if you view developing software as no different than polishing widgets or inserting pimentos in olives, something you do only for the money, I don't want you.


My job is a cost center. They don't specifically ask for a github or any source code, not they will more often than not ask in the interview about side projects. I think they use it mostly to see that you can learn new things, have a creative mind, and other "cultural fit" things.


> Most recruiters and hiring managers will never even open your GitHub profile.

I wouldn't expect recruiters or hiring managers to be able to read code or appreciate its quality or complexity; but what about the engineers who conduct technical interviews? Would they not be interested to learn as much as they can about the candidate, especially if that candidate, if hired, will join their team?


> but what about the engineers who conduct technical interviews?

You will be lucky if they read your resume at all, and when they do, it'll likely be on their phone as they walk down the hall to the interview room.

Resumes are mostly to get past the HR filter, and maybe impress the hiring manager - the engineer interviewing cares how you perform in the room itself.

Also at a lot of big companies, interviewing is not for specific teams, so the odds of someone they haven't specifically headhunted ending up on their team is low.


There's no way to know whether that's the candidate's code or copy-paste or they paid someone else to do it, short of using interview time to evaluate it. However, employers also want to provide a level playing field to all candidates, including those without side projects, so there are common evaluation points that are used for all candidates for each interviewer, meaning that little or no time is left in the interview to have that discussion.

As an aside, unlike other comments, I do read all resumes of candidates that make it to the interview stage in detail and ask questions about it to try and get a sense of whether there's any inflation going on or not.


Nope. My company has a set slate of interviews. I am there to primarily get signal from my specific discussions/questions.

I rarely look at resumes before I start the interview. Even if I did, I’m not going to peruse the candidate’s GitHub profile. The majority are pretty sparse or not relevant, and not worth the effort.


> Most recruiters and hiring managers will never even open your GitHub profile.

This is the first thing I do, because seeing the code you write is the very best story of them all. Maybe every person I've worked with who came in with weak skills demonstrated in GitHub was terminated between 2 weeks and 5 months later.


> Most recruiters and hiring managers will never even open your GitHub profile.

For every ten that don’t, there’s one that does. Probably the same recruiters who lurk on HN.


There is a business opportunity though. You can hire someone to build say 5 side projects of their choosing so you can place them on your resume and feature them in your GitHub profile. Could be a good way to fund open source work for small useful things.


Wouldn’t it be easier to just make up past jobs and put those on your resume? Hiring companies never confirm past jobs.


>Hiring companies never confirm past jobs.

Depends on the company. Many companies use the Equifax Work Number database. Example article about it: https://www.fastcompany.com/40485634/equifax-salary-data-and...

A google search query if you want to dig around some more: https://www.google.com/search?q=Equifax+%22Work+Number%22+%2...


Easier, maybe. Honest.... obviously not. Also most (maybe all) of my employers have confirmed previous jobs listed on my resume.


An honest thing that will get you a leg up when uploading to a system that will scan it for keywords is to use white text with the word not followed by a bunch of keywords not in the rest of your resume. The system doesn't care about text color, so it will match the keywords, when a human reads it, they won't see them, and even if they do you're still being honest with the word 'not'.


Instead of "not" use white text "no previous experience with: buzzword, foobar, latestfad."


Now this is actually pretty good. A sad comment on the state of affairs maybe, but quite amusing nonetheless.


> Hiring companies never confirm past jobs

Very much not true


No? We’re talking side projects not jobs.


> Recruiters want people who do side projects [...] having side projects and doing open source is valued in hiring

I think your premise is wrong and you're vastly overestimating the value of work done outside of your job.

- Having side projects: I was never asked past internship interviews. Even interviewing for my first job after graduation, I talked about what I did during my internship, not about side or school projects.

- Meaningful yet small contributions to open source: I don't remember anyone noticing nor asking.

- Major contributions to a big open source project: I assume these people get hired easily.

Recruiters are not dumb. They know that most good candidates are either not allowed or not willing to work on meaningful projects on the side, outside of a few very specific cases. Don't waste your time with companies that have delusional hiring standards.


> I think your premise is wrong and you're vastly overestimating the value of work done outside of your job.

For purposes of impressing the interviewer or getting the job, yes. For purposes of actually doing the job, I would say formal education and previous work experience are often overrated, and side-projects are underrated. Most of the skills relevant for my job I learned from tinkering, side-projects, and hobbies, whereas I rarely use the knowledge from my PhD (besides meta-stuff like how to organise and how to learn new skills). But the recruiters look at the PhD, not the hobbies. And I know many cases where it played out similar to this. (At lease that's my experience, mainly in Germany.)


> I would say formal education and previous work experience are often overrated, and side-projects are underrated

As a hiring manager, I disagree. Nothing beats actual work experience delivering code in a real production environment to real customers from within a real team environment.

The vast majority of side projects I see from applicants are one-off toy projects that have the luxury of starting from a blank slate, haven’t been built in a collaborative environment, aren’t hosted for significant traffic, and often aren’t user friendly enough to be used by anyone other than the author who knows all of the right commands and steps to get it to work.

Side projects can be good for tinkering and playing with new skills, but someone having real-world experience deploying those skills within a team environment to real customers and experience real-world customer issues at scale will have significantly more experience.


As a senior devloper, I would disagree with you. It's true there are things you learn im a professional environment that you don't learn doing side projects, but the reverse is also true: ina professional context you often have to do things quickly, take shortcuts for speed, choose technologies and techniques you already know in order to reduce risk. In side projects you can slow down, do things properly learn things the hard way.

I'd say 40 - 50% of my value as an engineer comes from side projects , many of which I did before I'd even had a dev job.


Same here. My side projects have literally taught me things that have enabled me to save a company. I was out of the corporate world for ten years churning through side projects and doing research on advanced topics. Hired back into the working world and immediately noticed a deficiency across the board in all the people who had been deploying code for real customers all those years. Passed them all and literally saved the company from a major system crash caused by their ineptitude (a crash that made it onto the Associated Press).

It was all due to not reading documentation, false assumptions, and a fundamental misunderstanding of several libraries, platforms, and technologies. They didn't know how they worked and didn't bother to check on their assumptions. A whole development team of architects and senior devs ruined (still in business but sold/acquired on low eval) a company through pure ignorance.


> The vast majority of side projects I see from applicants are one-off toy projects that have the luxury of starting from a blank slate, haven’t been built in a collaborative environment, aren’t hosted for significant traffic, and often aren’t user friendly enough to be used by anyone other than the author who knows all of the right commands and steps to get it to work.

And every one of these bullet points can tell you a lot about how good a developer can be. Do they know the limitations of their project, what is it that they wish to have done better, why wasn't it done, why did they stop developing, etc, etc... there are so many questions to ask based on the individual contributions that give you a lot of good information about how well a developer can work.

When working as part of a team a lot of developers' short-comings can be hidden by the achievements of the other members.

From my point of view (as not a hiring manager) the only time when the achievements from a work environment are more important than the individual ones, are when we're talking about how well someone can work with others (which is mostly a soft skill you can gauge from conversation alone) and when individual projects can't really exist in the context of the technologies the team you hire for is working with, and you require previous experience with them.


> As a hiring manager, I disagree.

Sounds like you’re bolstering his point that hiring folk care a lot more about work experience than side projects.


>> As a hiring manager, I disagree. Nothing beats actual work experience delivering code in a real production environment to real customers from within a real team environment.

I fully agree with this, except it is difficult to gauge who did what from the outside when interviewing. This is especially true for major projects where multiple individuals work on the same tier. I've see linked-in profiles of former colleagues who wholly took credit for things other people did.

When interviewing, I usually ask a lot of questions on challenges and lessons learned from these projects, but even then, if you have worked alongside a group for a while you can learn enough to claim you did work. I found it difficult to determine in many cases whether someone actually did the work or just managed it or just did the easy portions alongside the hard portion.


> formal education and previous work experience are often overrated, and side-projects are underrated

I partially agree, in my opinion work experience > side projects > education experience. When I'm looking at resumes I pay the most attention to work experience, and that's what I'll dig into in an interview, but for fresh grads and anyone with very little experience I will absolutely go through their github and see what kind of code they write and what projects interest them.


> Most of the skills relevant for my job I learned from tinkering, side-projects, and hobbies

I agree with this 100%. Learning to use tools beyond what you use at work makes you a better programmer, which in turn makes work easier.


> previous work experience

In my experience it's underrated, people prefer to gloss over that in order to ask the all important Fizzbuzz questions.


> - Major contributions to a big open source project: I assume these people get hired easily.

Nope; it depends on market demand for the project. I know a guy who was a major contributor to OpenStack for years. He’s an E5 at a telecom and is having a hard time finding a better job. Turns out there aren’t really that many places with huge OpenStack footprints.

The one place it might matter is in consulting. And only because it’s a good way to signal to clients that you know what you’re doing.

> Recruiters are not dumb.

When it comes to hiring tech talent they kind of are. They usually have no idea what an engineer actually does, so they’re checking boxes off a list the hiring manager gave them.


That's a bit sad, but isn't it at least partially due to OpenStack's decline?

And yes I've come across bad recruiters, but this is a self-solving issue: either external or internal, they'll quickly be unemployed if they don't realize what expectations are clearly unrealistic in a buyer's market.


Yeah, I guess my point is that unless the open source project you contributed to is in high demand itself, your contributions don’t really mean much from a recruiting standpoint.


I want to second this a lot.

Even if I (coincidentally) have a side project relevant to a job opening, I make a point to mention it in my cover letter, and most interviewers still say they haven't looked at it (if they've read the cover letter at all).


I don’t think I’ve ever seen a cover letter from a candidate in over 25 years of interviewing. They’re maybe seen by HR, but long stripped before the interviewer in my experience.


I have seen every cover letter accompanying a job application in every company I have worked for but I have never worked for a company with more than 200 employees or so.


Strange. I've worked in startups my entire career, hired over 100 developers and I can count on the fingers of one hand the number of cover letters I've seen.


Well cover letter has somewhat been replaced by an introduction email, no?


True. But there are still recommendations to email with a coverletter.pdf AND a resume.pdf. Maybe developers in Toronto don't follow those rules ...


For me, it varied. In the beforetimes, sometimes I walked into the first onsite interview and the technical interviewer had printed it out!


I can only think of a couple of times where HR decided the cover letter was worth including with the resume in a very similar time frame.


Depends if you go through HR or not.


Admittedly it's been a long time since this has been something I've had to worry about - but back when I just asked for it to be cut out the contract. Generally everyone was fine with it, especially when you explain "it's how I learn to do stuff that benefits me in the office". I think the general worry was twofold - that a) working on my own stuff would mean I didn't get my actual job done, and b) that working on my own stuff would mean I leave sooner and it's costly to pay for recruiters and refill roles.

It probably helps explaining what sort of side projects you do, how much time they take, your 'real' job pays for you to live and this is the nerdy equivalent to playing 5-a-side football or watching movies.

Anecdotally a (very skilled) dev friend recently got a job with a (UK) challenger bank and was required to sign a similar thing, they were happy to carve add exceptions for a couple of things he was working on.


Yes. Ask. I've never had an employer insist on anything beyond "Let your line manager know about projects you're doing so they can judge if it's a conflict", but left to their own devices the standard contract they've got will reject everything 'cos that is safer for them.

Same for other contract conditions. Had to have one previous employer strike their "usual place of work" condition because it was inappropriate for me, they knew it when they hired me and the people who hired me wouldn't have tried to enforce it, but it's standard text. If I sign it some new manager comes along later and gets to enforce it, no reason to allow that so I had them revise the contract.

In the UK, and I think maybe the US too, the employer actually benefits in a small way if employees get them to tweak the contract. If a court sees the contract as a "take it or leave it" situation - like when you buy a hamburger, you don't get to negotiate the terms of that deal, either buy a hamburger or don't buy a hamburger - then it automatically treats any ambiguity in your favour. But once you negotiate a different text, you had the chance to read that contract, if you thought something was unclear you could have fixed that, so now any defects are as much your fault as the employers.


Making sure the "usual place of work" being head office is struck out is vitally important if you're working remotely in the UK, otherwise you're no longer able to claim travel to the office as an expense due to tax law.


This right here. Tell them to carve it out or even return a signed version where you've done the redactions yourself. Tell them that non-work time is your own time and that previous employers have been willing to waive this requirement without issue.

I've managed to have it crossed out at 3 of my most recent employers.


Getting off on a tangent but crossing something out on a contract is something I've never understood. In my experience most are emailed digitally, and they may even just want the signature page. Even if they have the whole thing they can just take the signature page and append it to an unmodified contract. I'm speaking about job offers, apartment leases, and so on.


If they take your signature and attach it to a different document, that's called fraud. Of course you'd have to prove it.

First, start actually printing out contracts to execute them. It's old fashioned, and you probably don't have a printer (Staples does). But it preserves your right to cross things out and makes it clear that there is an authoritative "wet ink" copy that you specifically agreed to, not some vague digital assent to whatever they sent.

Also get in the habit of initialing each page of a contract, regardless of whether there is a space asking you to or not. A lack of initials then becomes evidence that a given page is not from a contract you signed.

And you need to keep a copy of what you've executed for your own long-term records. It's ultimately your word against theirs. Yes, this is another pain in the ass for the average 20-something, but if you care about preserving your rights you have to play their shitty game.

Relatedly, I'd love to find (or design) some "legalhash" algorithm that would canonicalize typeset documents into a reliable digital hash. I'm imagining a small set of characters, all whitespace folded into a single space, etc. This would capture the legal intent but leave everything else behind (wouldn't work for contracts with diagrams etc). You'd then put the hash of the whole document on the signature/notarization page, to authenticate the prior pages.


Nowadays many contracts are signed with a system like the one you describe. I've signed a couple of leases this way, all in a web browser. This makes it even harder since you can't print it out and cross out anything, then sign and give it back.


You can often still print those out, execute it, scan it, and email it back.

Depending on the context, it's possible to just completely ignore them (eg a non-compete that a job wants you to sign after you've already been hired).

You can also directly ask for your changes, as discussed elsewhere.

Ultimately, if someone tries to spring an unreasonable contract of adhesion on you at the last minute, the right answer is to blame them for disrupting the negotiation. Tell them it's unacceptable for them to have wasted your time, and look around for a better option.


A contract isn't the signed piece of paper, it's a "meeting of minds", two legal entities (e.g. a corporation and a human) reach a common understanding in which things of value are exchanged. Working for money for example. In some places there may be a law explicitly requiring that for employment you're entitled to a piece of paper setting out the terms, but it remains the case that contracts of employment come into existence as a result of this meeting of minds not the piece of paper.

For example once when I was young I was hired by the following process. I see on the TV news that a chip fab I've worked in caught fire, damaging nearby buildings. There are a lot of fire engines but the blaze is under control. Then I get a phone call from a friend, "Mountbatten is on fire". "I saw that". "We're getting Zepler back tomorrow, once structural engineers sign off on it - can you be there 0900 sharp to salvage stuff and get the network back up?". "Can do. See you tomorrow".

No interview. No pieces of paper. No salary negotiation. But that's an employment contract, just some of the details not determined until later. I actually genuinely don't remember how long I worked that gig, it was a lot of fun although pretty different from what I do these days.

In court, forging evidence by relating a signature page to the wrong document so they can then lie to a court about it is not OK - their lawyers aren't going to want to have anything to do with that idea. Contrariwise, if you have an email back-and-forth, or even just a friend who remembers you talking about the change, you're in a good place because your story makes sense and the employer's story does not.

But mostly you aren't going to be in court. If you're confident the employer would try to actually fuck you over, and you're in the sort of work where you get to strike contract terms, walk away from that job. Nobody needs that.


the way it should be done is not just crossing it out. You also add the signatures of both sides to the redaction. One copy stays with you, the other with the employer.

In digital terms, it's easier just to amend the whole file.


This is the truth right here. I've never signed an IP assignment agreement that applied outside of work hours and company equipment in my entire career. I've simply refused to do so, and made it a point of negotiation. If there's a company I really wanted to work for, at times I gave up some salary for this flexibility, but generally speaking it wasn't even an issue. Overly broad employment contracts are common-place in the US, because most people never challenge it. It's very much an "implication" situation, because of the power dynamic between employee and employer. Take the power back, read contracts, and don't sign if you disagree. There's always room to negotiate.

I think it's perfectly reasonable to say things I create during work hours, or in the office, or with company equipment belong to the company. On the flip-side, once you are no longer "at work" (whatever that means in your case) and on your own equipment, that is none of the company's business whatsoever. If you agree to it though, that's on you.


Just to add an anecdote: all large companies I have worked for required IP assignment, and it was NOT negotiable. You can ask for it to be removed and they will say no. You can try the “strike it out and initial” move, but the agreement will come back in about a week with a stern letter from legal saying “sign it unmodified or GTFO”.

It is likely more negotiable in smaller companies that do not have huge, inflexible employment agreements.


It's not clear whether you're referring to imaginary property assignment clauses in general, or specifically to imaginary property assignment outside of the job. Of course companies require imaginary property assignment for the work they're paying you to do, and that's entirely reasonable. It's not reasonable for them to also claim ownership over everything you do in your personal life (eg side projects, emails to friends, cooking recipes).


> It's not reasonable for them to also claim ownership over everything you do in your personal life

Yes, that’s what I’m talking about. I agree it’s not reasonable, but just try negotiating your employment agreement terms with a $1T company, and let me know how it goes!


I recently accepted a job offer at one of the big tech companies and they would not sever that portion of the contract. So while it doesn't hurt to ask, they might not accommodate you.


Every contract of employment I've received initially had a part saying I could not do outside work/projects, or that they would belong to the company.

None of them were there when I started work - as I had them all struck out, or changed to "work I do for the company belongs to the company, and I won't work on similar projects for other people while I work here".

It has never been a problem to arrange that. The only time it was, was during a initial phone-screen interview with the company HR person that said: a) they use Subversion and any discussion of changing to Git was never going to happen (this was in about 2017), and b) any outside projects were totally forbidden. No wonder I hadn't heard of the company before - despite their office being a few hundred metres from Silicon Roundabout and all the various meetups - no one was allowed to improve their skills...

What she had to do with making those decisions, I have no idea. And so that's the only interview I ever rage quit (though I did once tell someone else their puzzle-based questions were dumb during another interview).


If you're in California, you're protected:

"If you work out of California, the law will not recognize an agreement to assign to your employer an invention that you develop on your own time and using your own resources, so long as the invention is not “employer's business, or actual or demonstrably anticipated research or development of the employer.”"[0]

This is US-focused and other countries will differ, but some do's and don'ts:

[0] https://www.startupgrind.com/blog/moonlighting-a-side-projec...


> This is US-focused and other countries will differ, but some do's and don'ts:

If your local jurisdiction doesn't have pretty much the equivalent, it's a red flag to consider.


When a business is big as Google, with their fingers in everything, then that might not be much help at all.

Just one more reason to break up the tech giants.


Generally, you can ask for these clauses to be taken out of the contract when negotiating whilst interviewing. They are often just part of a boilerplate. Directly competing products seem like a fair thing to want to restrict, but other stuff with blanket IP assignment can be removed.

I am currently working as a contractor and the interllectual property assignment clause mentions "materials created pursuant to this agreement", but nothing further than that.

If they push back, point out that such clauses are illegal in California and it doesn't seem to have held back the companises in silicon valley too much. You always have the option to walk away if they won't agree.


Do dentists do dentistry on the side for free because they need to boost their resume? Do managers do managing on the side to learn new management skills?

I dont know why any engineers put up with this anywhere in industry. Although it hasn’t hurt me and I have never had a side project that I can recall. Coding is barely interesting enough to get paid to do it. Also so many side projects are really boring compared to real work with a bigger team.

If I start a side project/company it will be so I dont have to work for anyone else again not to boost my resume for the rat race.


I do not ask about side projects in interviews because they're expected. I ask because it that experience is not uncommon and it could be a reason that the candidate I am interviewing might be a good candidate.

> Do managers do managing on the side to learn new management skills?

Yes, many do. Plenty of managers list relevant community volunteering experience on their resume: organizing community events, coaching teams, participating in professional development groups, etc.


> I dont know why any engineers put up with this anywhere in industry ... Coding is barely interesting enough to get paid to do it.

If the second part of the above is how you feel then I totally understand the first half.

Personally, after decades in the industry I still enjoy coding in my own time at least a few hours a week. For many of those who feel like me, we don't "put up with this". We do it by choice, independent of any regard for the impact or otherwise on employment prospects, and class it as a down-time leisure pursuit.

For myself, what I do for a day job I'd probably still do even if I had an independent income (though I'd choose more interesting projects).


If anything, side projects are one of the only ways to not get bored of coding. Coding for work often means sacrificing good satisfying work forr quick results, whereas coding at home means taking the time to do what you want as well as you want


That's fine, but for a lot of us coding is exciting. I don't do side projects to boost my resume; I do them because they're interesting to me. Personally, the last few years I don't do much that's even relevant to my day job, aside from sometimes using the same language. I have other interests, that just so happen to involve writing code.


This is the best reason for side projects.


I agree with your premise, but just as a counterpoint, I'd add that many licensed professionals have a continuing education requirement designed expressly for learning new skills (63 hours per 3 years in my state, for dentists).


I agree with you, lots of companies are hypocritical and they ask for open source work from candidates, yet they make it either impossible/illegal, or at least very very hard for employees (jump through 5 approval steps that take months and force you to work overtime for publishing) to actually contribute to open source.

Another annoying thing is when a company doesn't even have any open source work published under their name, yet they expect the same from candidates.

When a company like that asks whether I do open-source, I pretend I misunderstood the question and just say:

> "I didn't know open-source is important for this company, I didn't find anything published by the company. Could you share the company's GitHub account? Maybe I mistook it with a different account. I'd love to see how company X contributes to the community." > > "But anyway, yes, I'd love to contribute to open source as part of my day job".

It's always funny to see them squirm, and clarify that they want to see my open source stuff, but they never did anything in that arena.

Usually, that's also the time I decide to stop the interviewing process. I don't care if you don't do open source, but then don't make it a requirement for candidates.

I actually do have some open source projects, so it's not like I couldn't talk about stuff at an interview, but I still hate it when companies ask for open source when they themselves have nothing to show for.

Another thing to mention here is that having a better-than-average open source portfolio helped me a lot at me career, so I definitely recommend it, for example at the company I work for, they skipped the entire coding challenge during the hiring process, and I got a better offer, too.


Those contracts are illegal in most European countries.

The employers are not allowed by law to state how you spend your free time, regardless how much they pretend it to be like that.

Naturally you cannot create a busines in competition with the employer using internal knowledge.


> Most companies also don't let their employees open source their code written at work too.

This would be a big red flag to me if it applied in the general sense at a company. Stuff that's open-sourceable is generic enough to not contain trade secrets, so what is there to hide? Though if it's a question of maintaining the project, I can understand a company deciding not to invest in maintaining the project (though I still think it's good when they do).

In my own experience, my employer does not prioritize open sourcing internal projects, but at least every time I've asked if I could open source something, it's been all thumbs up as long as it doesn't get in the way of normal business priorities. It's just a question of whether I feel it's worth it to me personally to become an open source maintainer.

Aside from that, I've contributed back to open source projects we use at work because there were some issues we found in the process of doing the work and that's resulted in improvements to those projects and a nice little side note on my CV. Even in a super draconian environment, given enough time spent working with open source dependencies, opportunities like this are likely to come up.


It really depends on the nature of the business. Some companies don't write any code that wouldn't contain trade secrets, some write code exclusively for customers who will own the rights, etc.


A lot of companies are just scared of open source and automatically refuse to be involved in open sourcing any code


> but I've never liked the fact that on paper companies can easily claim ownership of them if they become worth it.

My suggestion, if you are really worried about that, build something nobody wants.

Couple of my projects, a Sean Connery themed lisp interpreter[0] and a file sharing site that doesn't host any files and isn't P2P[1].

That said, I don't think anyone has ever really looked at either of those projects during the job interview process.

[0]https://github.com/willcipriano/Connery [1]https://github.com/willcipriano/Podje.li


I have a "fine print" section on my CV. The first entry is that I refuse to work for anyone who tells me I can't work any side gigs. I have no way of quantifying how many potential employers this has scared off, but I've never had an employer tell me I couldn't, nor have I been interviewed by any companies that told me I couldn't.

As long as you're not in direct competition with your employer, it shouldn't make a difference. If they tell you otherwise, get a different job. Good developers don't grow on trees.


For what it's worth, the state of Illinois has legal restrictions on a company's ability to prohibit and/or retain ownership of work that you do off company time and without company reasources.

There might be similar laws in your relevant jurisdictions, regardless, talk to a lawyer to be sure.


Also I have asked for terms remotely close to this to be removed from every engineering employment agreement I've ever signed, and either had them removed or gotten their scope clarified, in writing, and/or subject to a process of pre-clearance for conflicts.


Would you have a legal reference I can look up? I tried Googling for more information but couldn’t find anything. Thanks


For IL it's https://ilga.gov/LEGISLATION/ILCS/ilcs3.asp?ActID=2238&Chapt...


The value of side projects diminishes over time for most people, unless the side projects are "significant". For new graduates, side projects or academic projects with publicly available code are often useful talking points in interviews.

After a couple years of work, your day job becomes the primary point of conversation.

I write resumes. For clients that are coming out of school, the project section is often a large portion of the document. For people with a few years of experience, the project section tends to slip down the resume towards the end, and eventually falls off entirely. Experienced professionals with a projects section are usually trying to demonstrate skills they developed outside their day job (e.g. if you want to be a data scientist but are a web dev by day, some data science projects you did while taking a Coursera course will be useful to list).

All that being said, the problem you are describing is real for people who enjoy doing open source work and are employed by companies with restrictions on ownership. When I was a recruiter, I did work with some client companies to alter contractual language for new hires that had a body of open source work.


>>For clients that are coming out of school, the project section is often a large portion of the document. For people with a few years of experience, the project section tends to slip down the resume towards the end, and eventually falls off entirely. Experienced professionals with a projects section are usually trying to demonstrate skills they developed outside their day job

Thank you for writing so succinctly what I wanted to say.

Agree with this 100%. When I was starting out my career, my personal projects were on the top of my resume. Now that I have experience, my personal projects get omitted or only added at the bottom of the resume if they're relevant to the position.


Side projects including commercial are fine where I work as long as I’m not building something that competes. Saner contracts like this are the answer imho.


My experience is:

Where I work, we value any signs that a candidate will excel, and open source contributions can be such a signal. If you casually drop the news that you've landed some commits in a library that we're using, that will of course be a positive, because it suggests you are familiar with our tech stack and have at least some minimal technical competence. A good start!

But...there's a lot of ways you can signal that, and since most of them are vastly less time intensive, I'd never recommend someone goes out and starts contributing to get hired. Contribute because you want to, and as a bonus, some companies (like us) will value that. But we don't require it by any means, it's just one signal of many.

Which is good, because if we did require that we'd never hire anyone. In my experience maybe 1 candidate in 10 has any sort of portfolio of projects to share. And of those candidates who do have something to share, the quality is overwhelmingly poor. In fact...

...to the best of my knowledge, my current workplace has never hired someone because of their github profile or their open source contributions. But we have passed on candidates because of them, because we've literally had candidates proudly apply for "senior" roles with a portfolio of copy and pasted code full of errors. Bad code is much, much worse than no code, at least if you're claiming to already have expertise in the area. (Obviously I'd never ding a junior or new grad for that; context is key.)

Anyhow, the short of it is:

1. Lots of companies will look at your github profile if you send them a link, and IF it makes you look good, it might help getting hired.

2. Nobody requires it. If you don't send them a link to your github profile, they won't ask, they won't stalk you and try and find one, and not having one won't even be seen as a negative. Hiring a candidate who has never contributed to an open source project isn't unusual; it's the overwhelming rule.

3. If you're struggling to get hired, and you have a portfolio of great contributions to widely used open source projects, let employers know, many will care. If you don't have that portfolio, then focus on something else.

Even shorter:

> Recruiters want people who do side projects

They don't really care in my experience.


In the interview process I wait until they want me, and one of the things I do before final offer is ask for employee handbooks and any and all expected legal obligations for me to sign. Often under the premise that I would like to review the inclusiveness of ip work ie are they claiming outside work. Then I tell them to correct it or won't sign it. On principle we as an industry should be rejecting these things and setting healthier boundaries.

I wish we would unionize and take over the world, seriously, for our own benefit and be the source of change. There is a shortage and if we unionized optionally a cross the industry we could force real change, not for some woke cause but for the economics of it. We could fix a lot of this bs.


Anecdotally, this has never been a problem for me. My side project is even registered as a company in the UK and being directors of it has never been an issue for the full time "real" jobs me and the other two people involved have.


> you will usually have a contract forbidding you from having side activities

In my experience (Europe), the company is only concerned with paid side projects. Regardless, those who expect open source contributions outside your work are out of touch with reality. That's a great filter for me.

I once asked a colleague who was a product managers: "Why is there a side project expectation from developers, and not PMs? What could a PM even do in their free time"? He answered: "Well, a PM could have a side business!". "So, do you have a side business?" - I asked. "No..." - he replied, as I watched his sad face.


Recruiters don't look for people who do side projects. Doing side projects is just an indication of a passionate developer. Recruiters need to evaluate you, and talking about a side project is an easy verifiable thing


I have a couple cool JS projects with 5K+ stars, they used to make for good conversation topics in interviews but now I don't even bring them up. Work experience is so much more interesting to talk about.


I have the opposite issue here. I have never run into an interesting problem in my career (well at least one I was allowed to solve) whereas in order for me to even think about a side project for more than a few minutes it has to be pretty interesting.


I have successfully gotten those clauses removed when joining a new employer.

Pro tip: state that expectation at the beginning of the hiring process. It's part of the negotiation along with salary, working hours, etc. Don't wait until after they send you the contract.

Their contract probably already has a clause for employees in California, so you can state expectations pretty easily with something like "btw, I'm not willing to sign an invention assignment clause that would violate California's labor code".


I have been working as a contractor/consultant/hired gun for a decade now, and before that as a programmer since 2004. I do not recall ever signing a contract that said I couldn't do open source work or side projects.

Now, there is often something that says I can't work for, or as, a competitor in the particular market they're in. Which, to be honest, is only fair. But I would not sign an employment contract that said I couldn't do side projects or open source work, generally.


My last job was in the online learning space. In my final interview with the company owner I brought up my worries about this very thing, he looked at me concerned and asked what my side project was about. When I told him it was something to do with NLP he laughed and basically said he couldn't care less as long as it doesn't compete with his product. I wanted to get that in writing but I wasn't in a strong position to negotiate; regardless it was never a problem.


Before signing the contract, ask for clear written exceptions to the requirement.

In my very limited experience on the subject, I have been able to secure exceptions to such policies for side projects and ongoing work that are clearly unrelated to the company's business. They're happy, I'm happy.

Getting the exception in writing early helps both sides of the contract negotiation to be happy before the relationship even begins.


I have a couple of side projects, I always get them explicitly added to the employment agreement even if, technically, they are not in conflict with the employment agreement.


Been a professional developer since 1999. Never really published anything of substance. Never had a problem finding work. That said, some of my writings have been read by hiring managers. (Even pre-blog days, like forum posts from back in the day) Writing on technical matters says more about your work and thought processes than a random git repo (most of which is likely to be framework boilerplate anyways)


I'm curious how it is even legal anywhere?

Should employee have influence on e.g. ma sleep pattern (because it can reduce my work performance) or my eating habits?


> In a lot of jobs, people end up in a situation where they are actively discouraged from doing anything on the side because it's always hard to know if they're even allowed.

Just don't sign one of those contracts. I treat that as a hard deal-breaker when I'm job searching. If a clause like that is present in an offer, I tell them they have to remove it or otherwise narrow it to cover only the work that is their legitimate business. If they refuse, I refuse the offer. It may take a little extra searching to do things this way, but it's possible if it's important to you.

My job is not my entire life. I won't have it casting a pall over my every waking moment.

Alternately: if your projects are not central to your happiness like mine are, typically the worst your company could do is say "we own that now", not forbid it exactly. So if a project is purely educational - you're not attached to it - then you probably have nothing to worry about. You could also get written permission for specific projects or contributions you'd like to make.


TBH, I have many side projects and open source contributions. In fact I quit my job to work full-time on it. Was I a good hire? I don't think so. I was literally working 2 shifts and I always gave more importance to my own projects. Most of my colleagues had no side projects/open source contributions, but they were clearly outperforming me at work.


Don't worry if you have 10 years experience in a tech that is only 3 years old they will also hire you without side projects.


Contracts forbid earning money not what you do over the weekend on your own GitHub. People need to be smart about their online presence as well, not that they are obliged to but companies can be a pain to deal with over trivial matter. Decouple yourself online from what you do IRL for things you do not want people breathing down your neck for.


I'm a bit incredulous whenever I see the claim that HMs are looking for extensive side-projects because I have quite a few on my github and resume I don't think anyone interviewing me has even looked at them or at least no one has ever asked me anything substantive about any of my projects during an interview. The one exception is the startup that I worked on full-time for a period. I think most HM's look at extensive side-projects as a red flag that you are flighty and unreliable and will be hacking on weekend toys instead of working. Ultimately I think people are just lazy and don't care most of the time.

edit: regarding IP assignment agreements - in CA these are unenforceable for anything invented on your own time and equipment, companies still make you sign them because they do need the IP assignment for the stuff you produce on their time which is fine.


If you really want to, just work on things that are not related to work and strictly work on your own stuff outside of work hours. Just think about it, they cannot forbid you to edit your .bash_profile or even publish it. It's just hypothetically speaking. Unless you contribute to anything major (which will put you into another position anyways) many people will not care at all for the better or worse. Different story if you start making money on the side. And even then, I once worked at a small corporate where someone from HR worked on the side, I doubt that was ever made official but it was also totally unrelated work.

At the same time, while applying for a job with a running side freelance job, they might offer you to continue that arrangement perhaps with reduced work hours. Just mention your doubts after they make you an offer. (I speak from experience)


As someone who was a recruiter for a long time... Recruiters don't care about side projects. What they care about is being able to say a candidates has some technical interests outside of work. Do you give talks? Attend a meetup often? Record a technical podcast? Grind leetcode? Mentor engineers? Maybe you don't do any of that shit and you just go home and enjoy your life after work. That is fine too.

But what a recruiter is looking for is something they can add to your blurb when they pass along your information.

"throwaway account is currently at moonshot company using python and django to do xyz on a customer facing application. The platform is used by 50k users weekly. They also attend the SF python meetup regularly to stay connected to other python engineers."

It's not going to get you a job on its own but it's a small plus.


This is confused: hiring someone who _doesn't_ have a relevant job (e.g. they're a student or working in food service at present). That candidate I want to know about their personal project and OSS. I'd never consider asking someone who has a career about such things. They'd be way too busy. In fact having a significant involvement in a non-work software project would be a red flag.

Also: do you really mean "recruiter"? That's usually a facilitator person who doesn't know much about software. I answered the question in the context assumed in the other answers here which is more "hiring manager" or "recruiting organization".


Just wanted to add that your "side-projects" don't necessarily need to be done outside of the context of your job. On my resume I list several passion projects I've done at work on the side and have been given positive feedback about them. These projects are usually things that would benefit the company and also give me the chance to learn something new.

Although there's no official "20% time" policy at my company I tend to carve out a few hours a week of company time to work on these projects. One of my more senior colleagues managed to carve out 40-50% of his time working on these types of projects.


I've seen 2 people fired for running consulting businesses from their desks.

Made me feel kind of lazy, you know, for only doing my job.


> you will usually have a contract forbidding you from having side activities

Don't sign these contracts. I have been presented with those offers, asked the company to alter the contract to remove this clause, and they did.


They want people who do side projects, but stop them when you work for the firm.


I wish I could compel my team to write more open source code at work. Giving back to the community while shrinking our code base and growing their architecture skills - how good is that!?

Sadly it seems like most people want to talk about open source but not many are actually keen to put up a pull request in public. I suspect there’s an idea of open source being fun, experimental, not-useful code that exists in isolation. That’s not really the kind of open source I want to fund, but I’d love to see bug fixes and performance improvements upstreamed to the frameworks and tools we rely on.

Anyone figured this out?


In my experience, companies tend to refuse investing in doing open source work because they're usually scared that it will be extra work, a waste of time, or will cause legal issues/scare investors.

I'd hope that actual programmers in a team would be excited about doing open source work if given the chance though? It's just hard to convince a business that it's worth doing.


I turned down a job because of this very issue. I was ready to sign and when I was reading the terms, it said they would own my side projects during the contract term if I worked on them. Hard no from me.


In my early career i always ignored any stupid restrictions in contracts.

If i wanted to be creative and work on other projects at my spare time, I just do it.

No legal asshole can dictate what i can or cannot do.


I can include my input here. I recently found a gig through a side project. This happened in Berlin and had the option to say no when companies wanted to do a whiteboard interview / leetcode.

In Germany, I think I'm supposed to ask my employer for permission on if I can continue working on this or not, so we'll see!

https://arbeitnow.com/blog/how-a-side-project-led-to-a-job-o...


Your employment contract should say if and when you need to ask your employer. Aside from that, you also need to worry about Arbeitnehmererfindungsgesetz: https://www.gesetze-im-internet.de/arbnerfg/ Especially if you intend to make money off of it.


Thanks, that's useful!


Through my career only twice side projects have been brought up during the interview:

- When starting in a startup after I lost many years working for a small no-name company. - When interviewing for an American company in Madrid (I was not offered a position).

Side question: how do you all come up with ideas for side projects? I don't know if my life is dull (or I'm dull), but I have no creative power in my mind to give birth to great ideas, only small libraries, that well, interest few people.


It's another point to negotiate.

At my last company, I listed a bunch of things as my prior inventions and got explicit approval that I could continue working on them. Then I pushed to expand that to being able to work on any project that wasn't competitive to my current role/projects. I framed it as "this is one of the ways I learn new things and bring useful concepts into this role" and have had zero pushback.

Your benefits don't have to begin and end at salary, vacation, stock, and wfh.


A. We live in California, so this shit doesn't fly

B. Software engineers make side projects because it's fun, dude. No one is using that as a gating function. But someone who spends their spare time exploring their field is going to have a leg up on people who only write code 9-5. That's a natural result in any field. Exploration of your field in addition to constant professional work leads to skill development at a faster pace than just the latter.


Not everyone lives in California or the US.

Other than that.. yes I agree, but the fact that so many companies set up contracts that can effectively steal the personal work of their employee if they decide to, is kind of a problem.


IANAL and this is just my 2c.

>yet contracts forbid them?

This part is likely exaggerated.

Yes I guess there are a few companies really "forbid" them (from what I saw on HN Apple seems to be an example, but I don't have any first hand experience). But for the majority of the companies, they just claim the copyright of your side projects _by default_, instead of outright forbid them.

The why of the copyright claim part is already explained by the essay you linked so I'll not repeat that. Even with that in place, as others pointed out in threads, at least in California (I don't know if other states have similar laws) you can still get the copyright back to yourself, as long as:

1. You did not use your employer's time (do your side projects on weekends, nights, holidays, etc.)

2. You did not use your employer's equipment (use your own computer, network, etc.)

3. Your side project isn't related to your employer's business

The first 2 requirements are easy to met, the 3rd one:

1. If your employer is like Google that does almost everything, it's hard to met. But Google does provide a straightforward way for employees to apply to get the copyright of their side projects released to them.

2. If your employer is only on a few fields, as long as your side project is on unrelated fields it shouldn't be _that hard_ even if this has to go to court (but this is not legal advice, obviously). If you really plan to do side projects that puts this muddy, then there are other things to consider (conflict of interest, etc.) that's far beyond the scope of what we discussed here.

Also, if by "side projects" you mainly mean open source projects:

1. If it's purely your personal open source project that has nothing to do with your employer, see the discussions above.

2. If it's actually open source project/contribution that's related to your work (for example, your company is using an open source project and you are fixing an issue that affects your use case), _in theory_ you should be using your employer's time and equipment to do that (as that's really part of your job), and your employer should get the credit for this work (e.g. use your employer email in the commit).


So I've worked in the game industry where this happens even more aggressively than the rest of tech, and I've had contracts in at least 2 jobs where I was explicitly forbidden from engaging in any activity outside of work (I don't remember how it was worded, but it was so strict that even doing charity work could have fallen under it).

That combined with the frequent contracts of "we own everything you make while you're employed by us" effectively means side projects are either forbidden, or can be stolen by the company at any time, which is similar.

Not all companies are that bad but it's still a thing, and a lot of employment contracts make it very hard to work on a side project without your company potentially being able to claim ownership of it.


A few states have similar laws to California, but the majority (even weighted by the number of programmers) do not.

If I'm the maintainer of an open-source repo, there's no way I'm willing to risk accepting contributions from someone with an IP assignment clause unless their employer disclaims ownership explicitly and in writing. (I'm currently subject to an IP assignment clause but I had the option to "safelist" existing projects when I signed it.) Just not worth the potential headache.


Shouldn't CLA mitigate all/most of your concerns as the maintainer? Can you elaborate on your concerns?


My concern is that the person who agrees to the CLA (generally the individual programmer) may not actually be authorized to assign ownership of the IP - since if they're subject to an IP assignment provision, they don't own the IP to begin with, their employer does.

CLAs generally (if not universally) include clauses addressing this. For example, Google's [0]:

> You represent that you are legally entitled to grant the above license. If your employer(s) has rights to intellectual property that you create that includes your Contributions, you represent that you have received permission to make Contributions on behalf of that employer, that your employer has waived such rights for your Contributions to Google, or that your employer has executed a separate Corporate CLA with Google.

But I'm not sure I trust engineers to read and adhere to the fine print. And "he told us he had the right to assign the IP" isn't a defense - if it were, you could get out of an IP assignment clause in general just by lying and saying you're not subject to one.

[0] https://cla.developers.google.com/about/google-individual


I think the only time it "mattered" that I had side projects was one CEO who emailed me on two different occasions that he "noticed" my one-commit abandoned github project and was interested in talking further about hiring for a position at his startup.

In other words, the project was meaningless (probably scraped off linkedin) and just served as an icebreaker to try and get me onto a phone call.


Successful people don't follow the rules.

Most rule violations don't get noticed. Of those that do, most are ignored. Of those that aren't, most are met with a warning. Most of the time it's sufficient to respond to a warning by: apologizing, pleading ignorance, correcting your "mistake", and promising to do better.

"It's better to seek forgiveness than ask permission."

IANAL.


I agree with that but there's a big problem here which is that you can get scammed big time by your employer.

If any of your side projects get big, depending on the contract your employer might be able to claim ownership of it.

If you're doing side projects despite those kind of contracts, you're effectively trusting your employer to be nice when they have legal right to not be. This isn't a great position to be in.


For sure ask for those clauses to be removed, but there are plenty of places that simply won't remove them.

Your employer is not omniscient. To claim ownership of your side project they first need to know it exists. How will they come to know it exists? Are they even looking for employee side projects?

Your employer is also not omnipotent. It needs to be worth someone's time and energy to come after your side project. Now if it's wildly successful, or competing with your employer's product, or you have internal enemies, that's one thing. But most side projects just aren't worth going after.


Mildly related: On the non engineering side I see lots of hiring managers who came from a different industry than their current employer and yet are adamant that candidates have years in the industry on on the tool stack (Salesforce or Tableau for instance).

Most industries, let alone tools, don't take that long to learn, and business acumen isn't industry-specific.


When I was looking for my first job some years ago, I kept answering "Never used it" to tools that take maybe a day to a week to master. That made me fail at so many HR stages.


I think this is more of a thing for college students who are getting their first job.

IME I've heard a lot more people interested in side projects than the other commenters. But I'm also a lot younger, and heard this usually in different universities.

Once you actually get a job, you put that on your resume and it's better than a side project.


It's the opposite for me. Recruiters ignore my most recent and relevant (tech wise) side projects and focus on the 'job' I had years ago. As someone who wants to change careers (go from Data Engineering to Front End Engineering) this is very frustrating.


Not all interviewers care about side projects, but among interviewers that look at them, I think there are two very distinct groups:

1) the ones that use the existence of a non-trivial side project as a proxy signal for motivation and expertise (because let's face it, the person spending 2 extra hours every night on a project that is actually functionally equivalent to a product has that much more experience than someone who doesn't - see the "unreasonable efficacy of showing up" effect)

2) the group that heard about looking at side projects as a metric and who somehow got the idea that they ought to be reviewing the code or something to grasp at clues about the candidate's competence.

The latter works out horribly because then through the magic of broken telephone, some subset of candidates think they have to have something on github and then you get into this situation of people wasting time code nitpicking apart school project level code in some way that probably doesn't correlate with actual job performance (e.g. looking at coding style and/or looking for pet peeves).

You want 1). Run away from 2).

As for what's "allowed". Let's put it this way: it's not like you're in first grade and you have to be angel or else it goes in your permanent record, onoes. Side projects come in many flavors, ranging anywhere from leveraging the power of OSS to contribute to the bottom line to using confidential data for competing with your employer, so if you're gonna ask your company's lawyers if a side project is kosher, they're always going to err on the side of covering their asses in the worst case scenarios (especially companies who view engineering as replaceable cost centers). But at the end of the day, there's no such thing as legal perfection; a company can get away with not doing anything about harrassment or whatever in the name of profits, and conversely employees can get away with side hustles, without everyone sitting in the same room to talk about feelings for three hours. Pursuing legal action over ownership of code you wrote in your spare time is not cheap for the company (both in the sense of legal costs and in the sense that they are pretty much asking for a letter of resignation from you and the associated cost of replacing you), so it's going to be a last resort. Reaching a compromise or just letting things be are far less friction. Many companies are in fact open minded to the idea of employees working on OSS, e.g. in consideration that they use OSS heavily in the first place.


I started at a new company in June and they were willing to have their lawyers change the boilerplate contract to state that anything I do that’s unrelated to our industry, done on my own time/resources is mine. It really depends on the company.


I would never sign a contract where I yield copyright of my side projects though


Not even say for $500k+ TC per year (not unreasonable today from faang)? Copyright for all pre-existing stuff stays with you, the question is just who gets IP rights by default to all the new stuff (including commits to existing projects) that you do while on that fat paycheck.


If they want the IP rights to my International Flatulence Database, I'll gladly plaster their name and copyright all over it.


Yeah you should never do that. It feels as it takes away a part of your soul and also shows how little they trust you.


I just hired a junior UX designer in part because of their really cool side project. It's not something I was asking for or expecting in the job req, but I for sure looked at it when it was on their resume.


Every place I’ve worked at lets me carve out side gigs/projects as being personal and not subject to w/e stupid non-compete clause they’re making me sign.


but if they've made you sign it, what's stopping them from changing their mind if any of your projects becomes worth something or makes noise in some way?


Maybe I've just been lucky, but most of my contracts have essentially been worded so that work related to the business belongs to them, but not everything.


Those contracts are abusive and of highly questionable legality. Side projects are the bread and butter of high output tech workers.


I always wonder if I should add how much money are my projects doing so recruiters would take them more seriously.


I would not sign such a contract.


Maybe if you have no experience. Recruiters want people who already have jobs.


At least in the US, the Biden Administration recently called for a ban on non-competes; I submitted a link to the story the other day:

https://news.ycombinator.com/item?id=27817290


depends on the state, in WA state you are protected. In another state i had to sign an agreement that everything in my brain was owned by megacorp


Live in a jurisdiction (California) in which you don’t have to worry about this nonsense because employers are not allowed to do that.


Even in California you have to worry about that, should your project

  Relate at the time of conception or reduction to practice of the invention to the employer's business, or actual or demonstrably anticipated research or development of the employer
Some fat cats are so big and dabble in so many things that you can never be sure


Or, you know, talk to your potential employers. Location shouldn't have to be a qualifier.


> in which you don’t have to worry about this nonsense

You can worry about being able to afford that $500k studio with a 2hr commute.


most of opensource contributions happen as a regular job. there is no such a thing as nerds doing opensource for free. Opensource is free to take source code but is creating of this code is usually well paid by big corporations.


"The equilibrium strategy is to destroy your partner's market value" (C)

https://www.smbc-comics.com/comic/auction


> most companies when hiring are looking for people who do lots of side projects and open source work

Incorrect. Most companies don't give a shit.

> yet when you are actually employed, you will usually have a contract forbidding you from having side activities

Incorrect. I've had a dozen jobs in my life and exactly zero times have I had anything resembling a contract at all, let alone one that dictated my activities in my free time.

> on paper companies can easily claim ownership of them if they become worth it

No they can't.

> people end up in a situation where they are actively discouraged from doing anything on the side

No they're not.

> having side projects and doing open source is valued in hiring

Not really.




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

Search: