Ask HN: Recruiters want people who do side projects, yet contracts forbid them?
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.
226 comments
[ 2.4 ms ] story [ 230 ms ] threadYou can worry about being able to afford that $500k studio with a 2hr commute.
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.
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.
I've managed to have it crossed out at 3 of my most recent employers.
In digital terms, it's easier just to amend the whole file.
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.
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.
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.
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.
It is likely more negotiable in smaller companies that do not have huge, inflexible employment agreements.
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 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.
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).
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.)
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.
Sounds like you’re bolstering his point that hiring folk care a lot more about work experience than side projects.
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.
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.
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.
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.
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.
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.
In my experience it's underrated, people prefer to gloss over that in order to ask the all important Fizzbuzz questions.
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.
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.
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.
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.
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.
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.
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.
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.
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 :-)
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
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.
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.
Very much not true
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...
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.
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.
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 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?
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.
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.
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.
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.
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.
The most wrong thing I have been told about adulthood. Doing homework at the last minute is hardly just a kids thing.
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.
Granted, I went to a pressure filled high school, but nothing came close to being as demanding as that, even engineering school.
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.
But at my high school, they did.
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.
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.
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.
Finding someone who'll learn new things in their spare time for fun is much cheaper than training.
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)
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.
PhDs typically walk into senior roles depending on what they did for their thesis and what types of code they developed.
Tech hiring, and most hiring really, is broken.
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.
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.
For every ten that don’t, there’s one that does. Probably the same recruiters who lurk on HN.
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.
* 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
When I got rejected from Google the feedback was I should do more open source work.
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.
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!
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.
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
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...
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
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.
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.
I was sure to carve out exceptions for all of my side projects in my employment contract, they did not argue about 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
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.
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...
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.
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.
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).
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.
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.
https://www.smbc-comics.com/comic/auction
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".