Since the 1980s, employment has become a game. Employers don't like it if you realize this and play them right back, of course, but there's not really any other option. Their viewpoint is dominant and essentially universal. In response to monumental productivity multiplication due to technology, they froze wages, destroyed pensions, cut benefits, and extended the work week. They believe if an employee becomes irreplaceable, they have become expendable. Keeping employees dispensable is weighed as far more important than keeping skilled talent. Read books written by managers for managers. Their actions aren't random or stupid, most people just don't understand their reasoning.

And if you only get one tattoo in your life, I highly recommend this centuries-old quote from The Rubiyat of Omar Khayaam: "Make game of that which makes as much of thee."

Consider that we openly talk about Bus Factor as a way of explicitly quantifying the indispensability of certain people; but the solution is not to get rid of them, it's just to train more people on those aspects. Of course there's still some amount of Machiavellian maneuvering, but at least while talent is thin on the ground employees still have enough leverage not to get screwed—not as badly as most non-unionized employees anyway.

I believe that on average non-tech companies treat their employees better and give them more right and freedom.

With non-tech companies you usually sell your time. But with tech companies you sell your brain power, if your side projects affect your brain contribution to that company for sure they don't want that.

So silly of them, I always say this. Companies should stop treating their employees as assets.

And let me say again, there are successful tech companies run by smart people that don't do this! And most employees including the founders are happier because of it.

At SunSed we believe that we should treat business like a passionate music band — making money is not the ultimate goal — the ultimate goal is to see people enjoying your music while you enjoy playing!

Programming all day at work and then spending a lot of your non-work time programming too could put you at higher risk for getting burned out on programming. Spending your non-work time rebuilding old cars probably won't affect your programming at work.

Note that I'm not suggesting that the boss should be able to make you stop programming at home. Many people can program at work and at home and not get burned out, and it should be up to the programmer to decide if they are such a person. I'm just saying that programming related hobbies are more likely to affect programming work than are non-programming hobbies.

Of course, take this with a massive grain of salt. I'd certainly prefer not to have to go to court to try and figure out if this is actually true.

"For example, the California Labor Code stipulates that regardless of what an employment contract or PIIA says, an employee owns the copyright and patent rights to his inventions if the invention is made entirely on the employee’s own time, without using any of the company’s equipment or technology, as long as the invention (a) does not relate to the company’s business, or (b) did not result from work performed by the employee “as an employee” of the company. Washington state has a similar law protecting employee projects outside the 9-5 bounds."

- If you don't show side-projects, you don't have passion

- If you do show prototype-quality side-projects, you aren't skilled

- If you do show production-quality side-projects, you aren't sufficiently focused on your daytime job.

My impression was they generally want to see side projects for newbies/recent graduates, i.e. stuff the applicant would have been working on during college or something. Not stuff the applicant was doing on the "side" during his/her previous years of employment. Am I totally wrong here?

So at least for 15-year veterans it does not really seem to be much of a thing. Although I do secretly wish they would discover my 4-digit GitHub user id, that's gotta be worth some kinda programmer-cred right?

Hmm, the way I see it is that side projects usually demonstrate that you have a passion for code outside of your work as well. From a company perspective I would probably also hire someone who is using his free time to advance his knowledge since some of that stuff he is using/learning could also become useful for the company at some point.

I personally don't mean any harm with my projects. I just really like coding, creating things and learning more (my way of learning also being to experiment/build something with technology X). The field is so broad and there are so many interesting things to learn about with new ones getting released almost weekly.

In other industries, these are called "portfolios" or "writing samples". It's not just about showing a passion; it's your chance to make a piece of work that represents your best abilities and judgments.

When I interview candidates I find it easier and more constructive to ask design questions about the side projects than to contrive some hypothetical scenario.

IMHO the alternative, where you ask people to write code under the pressure of an interview setting, is far less informative.

Not saying you won't get a lot of false negatives with high-pressure on-site coding or whiteboarding, but if done correctly I think it's probably the most signal you can get for the least time. Granted it requires good judgement from the interviewer, and a lot of candidates to calibrate. It's also unfair to candidates who are easily rattled, and biased towards candidates who have time to do a lot of preparation. In the past I have preferred contract-to-hire as the gold standard if that works for a candidate, but that only works if the pipeline is small.