5 ms·

To stay sharp employers want to see you keeping up with new trends, doing side projects, or improving in some way. I don't think this is actually true. Employe

To stay sharp employers want to see you keeping up with new trends, doing side projects, or improving in some way. I don't think this is actually true. Employers don't give a crap about your side projects, what you do in your free time, or what you learn at the weekends. Many don't even want you to learn things in your job. The reason it's so widely believed in our industry is four-fold; - people who are "Twitter famous" devs often work as developer advocates for businesses, and spend their work days building small projects to demonstrate things. Then they talk about them but never mention that they're work projects. Their audience thinks "I could never get to build that in office hours, must be a side project!" and extrapolate from there that getting to be a rich and famous dev advocate means working on weekends. - devs involved in hiring say they want to look at Github repos. I've been hiring devs for the last 15 years and while I do look at repos if they're available I still interview loads of people who don't have them. In fact, to be honest, having public repos is more likely to push me to rule someone out rather than arrange a chat. 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. - we like making side projects and need an excuse to spend time on them. When your partner or kids or parents are nagging you to do something being able to stress that our career will wither away to nothing if we don't spend time on something on Sunday night is useful. - it's a route out of a bad job. If you're working with tech you don't like, at an employer who refuses to give you a training budget, and you don't have any opportunity to learn things in work time, then side projects are an obvious alternative. A better alternative is to find a job where you can grow. An important thing to note about this is that there are a ton of skills that are really hard to learn at home on a weekend (running meetings, talking to clients, using focus groups, mentoring juniors, writing clear docs, etc). Being a dev is about much more than coding after all.

windowsworkstoo 5y ago
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.
- pydry 5y ago
  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.
  - PebblesHD 5y ago
    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.
pm90 5y ago
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.
- librish 5y ago
  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.
- onion2k 5y ago
  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.
bigpeopleareold 5y ago
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.
- WJW 5y ago
  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.
  - nisegami 5y ago
    Ah, my beloved MDD: Magpie Driven Development http://www.nichesoftware.co.nz/2021/07/10/magpie-driven-development.html http://www.nichesoftware.co.nz/2021/07/10/magpie-driven-deve...
  - bigpeopleareold 5y ago
    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
t_mann 5y ago
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).
- roenxi 5y ago
  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.
- onion2k 5y ago
  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.
colonwqbang 5y ago
> 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.
- dijit 5y ago
  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 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*
leesec 5y ago
<Deleted>
- my69thaccount 5y ago
  - leesec 5y ago
- lolinder 5y ago
  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.
  - leesec 5y ago
    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?
    - lolinder 5y ago
      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.

windowsworkstoo 5y ago

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.

pydry 5y ago
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.
- PebblesHD 5y ago
  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.

pm90 5y ago

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.

librish 5y ago
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.
onion2k 5y ago
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.

bigpeopleareold 5y ago

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.

WJW 5y ago
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.
- nisegami 5y ago
  Ah, my beloved MDD: Magpie Driven Development http://www.nichesoftware.co.nz/2021/07/10/magpie-driven-development.html http://www.nichesoftware.co.nz/2021/07/10/magpie-driven-deve...
- bigpeopleareold 5y ago
  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

t_mann 5y ago

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

roenxi 5y ago
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.
onion2k 5y ago
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.

colonwqbang 5y ago

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

dijit 5y ago
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 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*

leesec 5y ago

my69thaccount 5y ago
- leesec 5y ago
lolinder 5y ago
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.
- leesec 5y ago
  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?
  - lolinder 5y ago
    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.