Hacker News Reader

Heh your bit about Github resonates. I hire plenty of devs and the whole "make sure you have a GH body of work" has become such a meme that when people do include it on their CV, it's usually just a big list of forked repos with no contributions.

For me, Github/personal projects have not been a useful signal either way, but it is apparent in recentish years that the advice has been to have one regardless.

I havent done much hiring but when I did a github profile that wasnt just forked repos, programming exercises, classroom notes etc. it was always a strong and positive signal of ability.

It just happened rarely. 95% of github profiles held almost nothing of interest.

Impressive github + well known employers + gregarious/outgoing as a combination also always basically signaled that the candidate wasnt going to be within budget.

Good points, and interestingly as a candidate who is reasonably outgoing, does a bit of public speaking, and has a github profile with a few infrequently updated but well used side projects included on my resume, I aim for this to work as a reverse filter for companies who will pay me an above average salary, and it’s worked a treat so far. If an employer still wants to interview me after being referred from a DevOps talk or through friends after reading my resume or having coffee with me, I’m usually pretty confident they know what I’m going to be asking for.

> In fact, to be honest, having public repos is more likely to push me to rule someone out rather than arrange a chat.

That sounds like a good thing? Looking at the quality of someone's public work lets you rule out more candidates who are not a good fit.

The quality of my GitHub profile does not in any way reflect the quality of the proprietary work I do.

A great example is the projects I do to learn things or for fun; such as this awful ruby port of a BBC Basic game from the 80s which does _nothing_ the right way: https://github.com/dijit/SpyQTest-rb/blob/master/spyqtest.rb

The constraints are fewer on side projects, the motivations are not the same.

I am not certain that I'm amazing at my job, I'm definitely decent enough to be employed for 15~ years, but the gulf that exists between my GitHub repos and code I write for my employer is extreme enough that I'm relatively certain that if I was judged on my GitHub profile alone I would not get jobs; and if my proprietary code were open it would lead to jobs.. so *shrug*

Interesting. There were posts on HN here recently were tech recruiters said that they look at github more than at resumes (with lots of people commenting that their githubs look like what you described and aren't representative at all).

3 comments on HN can look like a crowd. It is still 3 people. Even a busy thread might be a few tens of people.

There are too many good people out there who don't have interesting public github repos. It isn't a decisive signal although it might help a resume stand out from the crowd.

Engineers who are involved in hiring people for their teams have wildly different goals to tech recruiters, and possibly a much better understanding of recruitment in a lot of cases. Tech recruiters (bad ones) don't care if someone's skills match a role. They're happy to waste everyone's time on the small probability that they'll get lucky and land a candidate. I'm not happy to do that.

How great would it be to get paid by your employer to tinker on something on the side :) Because, if that was the expectation, I would happily bill my employer for things I toy around with.

I think the usual way to do it is to pitch your manager on a new project for something that the company actually needs, but for which the fancy new tech you want to play with just happens to be the best tool.

Of course, this will also cause people on HN to shout at you for making things too complex, but you can't have everything.

Ah, my beloved MDD: Magpie Driven Development

http://www.nichesoftware.co.nz/2021/07/10/magpie-driven-deve...

I wrote a small tool based on a tool I have at work in Free Pascal for fun and mentioned it in our company chat room. One of my co-workers thought was scared and thought this was an indication that we were going to start using Pascal for everything. :D

Not doing side projects is not the same as stopping learning. OP addressed this in their last paragraph: if you're in a dead-end job that isn't teaching you anything, you'll learn faster by getting a new job where you can grow, rather than working overtime to teach yourself. You'll have more hours to learn in, other people to learn from, and real-world situations to adapt to. They also rightly point out that a good job teaches you valuable soft skills that you can't really get from side projects.

More generally, it would be helpful if you explained more why you disagree. This comment and the paragraph you reference are both devoid of any actual explanation for your opinion beyond "it worked for me", while the commenter you're replying to has clearly thought things through.

You interview two candidates, they both have exactly 1 year experience and no degree. They both have done satisfactory at their first role, but one has also stayed learning and has a few side projects to show for it. Which do you choose?

If all else is equal, I'd go for the one with the side projects. But all else is never equal, and you haven't listed all the possible differentiators:

* What if one spent a year doing the bare minimum at their job because their creative energies were wrapped up in their side projects, while the other took the lead on important tasks at work?

* What if one spent a long time working on side projects that use arcane technology, while the other worked at a job that uses the same tech stack I do?

* What if the one who worked on the side projects is distractible and never finishes anything while the one who didn't is focused and get stuff done?

* What if the one who works on side projects doesn't get along well with others, while the other one avoids side projects because they prefer to be on a team?

* What if one did side projects because their job bored them to tears, while the other was a key player on a small team and learned a ton from their job?

The point is, side projects are just one signal among many, and they're far from the most important signal. This is important to keep in mind when strategizing your career, because it means that there are other things that are valuable to focus on; it's not just side projects or bust.

The one who did better in the interview?

Which do you choose?

The one who interviews better, and who sounds like they'd be a better fit for the team. If one of them has been learning the things the team uses then that will shine through on their technical interview and coding test. If they've been learning something that's not used then it won't make any difference and won't put them any further ahead than the candidate who spent their spare time doing other things.

Anecdotally, and this is just me rather than something that applies broadly in tech, but I don't want people on my team to work (or learn, or whatever) 16 hours a day. I want to work with people who are fun, interesting, and have interests outside of just working all the time. There's few things I find more tiresome on a Monday morning than when the PM asks "how was your weekend?" having someone on the team who never has anything to contribute. Those people are boring, and they make the rest of the team less willing to engage with one another.

Coding is a team sport. If you're doing your best work on your own at 2am learning something new then you will not do well in many companies.

You don’t really sound like a person who writes code for fun. Just because you don’t or cant do it doesn’t mean that others should follow.

side projects’ intended audience isn’t future employers. It can be anything the creator wants to hack on just because.

> Most people's public repos are examples of very bad quick hacks, starter projects with no additional work, or things so poorly documented I can't even tell what they are.

lol ok. Having worked at several corps generating hundreds of millions of dollars of revenue, most of them have been powered by the gnarliest of hacks duck taped together and kept alive by armies of pitiable engineers with a pager. Your expectations are wildly out of touch with how most software companies operate.

I think you've interpreted the post incorrectly. It's not saying "don't do side projects for fun". It's saying "don't do side projects as a means to get hired" which I agree with.

You don’t really sound like a person who writes code for fun.

On the contrary, I write code in my spare time a lot. I have a ton of GH repos, CodeSandbox things, Codepens, etc. I tinker with things all the time. I'm just aware that others don't so I try not to let my own preferences bias how I hire people. Missing out on a great candidate because they're not like me would suck for my team. Plus, I'm also aware that people's 'free time code' often isn't representative of how they write code professionally. I wouldn't want to be judged on mine...

Your expectations are wildly out of touch with how most software companies operate.

I've run a software company. I've worked at a lot of them. I'm very aware of how much things are held together with duct tape and undocumented YAML files. I don't see how that would impact how I'd review someone's public GH commits though. The company they work for might be operating a codebase that's one commit away from catastrophe, but it might not. I don't get to see that code so I can't really use it as a reference.