Hacker News Reader

It depends on your point of view. The boss wants the most sophisticated talent he can get, and he doesn't want to pay anything for it. Every penny he pays, and every second of your life he doesn't get for it, is a failure in his eyes.

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."

I think this game is much more openly recognized in SV without too much cynicism. The average tenure is probably around 3 years, and people move between companies often. This serves both the employee by diversifying their skillset, and it serves companies by facilitating knowledge transfer for certain techniques, particularly around scaling and operations for larger tech companies that individuals can't get through mere education or even small-scale work.

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.

Do you have any recommendations for books for managers written by managers? The last book I skimmed on this topic was "The Alliance," by some people at linkedIn. According to one of the reviews on amazon it mainly just talks about industry-wide blacklists for employees if they leave their jobs for a better one.

I thought it was me. But now I see each job as a place where I grow my skills. I actively pick projects where I gain more technical skolls over those where I develop internal company knowledge.

"fuck the game, don't let the game fuck you"

So if you have any other interests, such as rebuilding old cars, would that boss still have a problem with it? That is the thing I don't get, is how some companies see a big difference between regular hobbies and programing related hobbies.

I only know a few companies that promote a healthy work/life ratio.

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!

It might actually make some sense for a programmer's boss to be concerned about side programming projects, even if they have nothing to do with what the company does, but not be concerned about outside interests like rebuilding old cars.

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.

Equally there could be beneficial aspects to working on different coding problems outside a main job- improving skills, learning new tools, whatever. But that's not the important thing. To me, the important thing for an employer should be performance: "I have these expectations for the role, how is the employee doing in relation to those expectations, and are they being paid over or under the market value for the position?" Even if the employee could be better if they didn't have a side project, figuring out balance and maintaining job performance are skills in and of themselves. If an employee can do that, great, if not, bummer. The external cause doesn't matter. What matters is the employee's judgement in the self care they need to do in order to meet the needs of their job. No need for employer to borrow trouble by trying to control non-work activities and incurring bad will.

[Google owns any IP you develop, even on your own time](http://startups.stackexchange.com/questions/7822/working-leg...), and you can't easily work on those interview-worthy side projects after you get hired.

That's not necessarily true. Companies certainly like to advocate for the idea that they automatically own any work you do that's relevant to any of their business interests, even if that work isn't relevant to your particular job. But that doesn't mean it'll hold up in court. Just a couple of days ago I was reading something about how courts regularly side with employees instead of employers in disputes like this, how they tend to interpret that as only applying to work relevant to the employee's job and not to other parts of the company. Unfortunately I don't remember where I was reading that, so I can't go find it again.

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.

Were you reading it here: https://news.ycombinator.com/item?id=13142327 ? There's a couple of mentions of courts siding with employees and courts in California siding with employees.

That's probably it. And I'm in California so I probably only paid attention to that bit.

All previous companies I worked for had this clause. I've heard it's not as easy as typed to actually enforce. However, the companies I worked for stated that any personal project "relevant" to company interests belonged to them, up to 6 months after you leave.

This clause is illegal in many states. It definitively is in Wisconsin where I live, and I thought for sure it was illegal in California.

http://www.shakelaw.com/blog/employee-inventions/

"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."

That's kinda true, but we can request to get our copyright back on a per-project basis.

Good point. Seems like the company's attitude is: "show us you're passionate and have side-projects, but of course, once you work for us, we want all of that passion focused strictly on us."

I've been penalized for showing side projects and kaggle entries that weren't production quality code. No shit it's not production code, because it's not going into production. I quit working on them when I stopped learning, and that was well before code polishing.

To be completely fair, if you are showing a project you have done, it should be a good representation of your abilities. Treat it like how other industries treat "portfolios" or "writing samples".

Seems like a lose-lose:

- 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.

Maybe a good balance is to show a very small number of production-quality side-projects: like just pick your top 1-2 things? (Just brainstorming)

That's a backdoor work sample. I personally don't do work samples unless paid...

> If your company wants to see side projects but dislikes the idea of you actually working on them after starting, you are doing something wrong.

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?

Anecdata: I'm currently in the middle of interviewing with a wide slate of mid-size SV companies, and not one has asked for code samples. It's all a mix of whiteboarding, on-site coding, phone-screen coding, or take-home coding.

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?

> Not stuff the applicant was doing on the "side" during his/her previous years of employment. Am I totally wrong here?

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.

> side projects usually demonstrate that you have a passion for code outside of your work

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.

I know what you mean, but it's also easier to fake. I've definitely run into the situation where someone's projects look good, but then they are terrible on the job. I'm left to conclude they were pairing with someone more knowledgeable or cloning some idea or maybe has spent years preparing to tackle that one problem and are not good in general problem solving.

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.

I also think that contract-to-hire is a good option to consider. Vetting a small, unknown company requires time and effort.

It probably depends on the company but I think this is right. If I interview someone with little working experience it definitely helps that they have some work on Github. But it would be strange to reject a senior candidate with a great resume who did very well in the technical interview just because they didn't have anything on Github.

You might find this post by Joel Spolsky a good read: https://www.joelonsoftware.com/2016/12/09/developers-side-pr...