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 e

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.