5 ms·

Side projects are the new resume

23 points by bradly 14y ago

tptacek 14y ago
If you say so. Some of the best people we've picked up didn't have significant side projects, or any side projects. And jobs here are harder than most industry dev jobs. If you're a developer reading posts like this, you should know that it's a seller's market. Work on side projects because you love them, but don't cram them like extracurriculars on your college application. Very few competent hiring managers can afford to downselect you out based solely on your Github page. If you're a hiring manager, my advice is a little sterner: unless you've got candidates coming out of your ears (Github is an example of a shop that might have this problem), don't get confused about what your job is. You need to work on two things: lead generation and lead qualification. Think about recruiting as a sales & marketing problem, because it is one. Most marketing teams don't set up qualifiers that are likely to reject leads that might close.
127001brewer 14y ago
If you’re a software engineer, you should be hacking at projects, building apps, websites, and tinkering away at things you love to build outside of work. While I generally agree (that you should expand your knowledge and skills with side projects), how many companies think that these extracurricular activities are taboo? As someone who is looking for a new opportunity, I often hesitate to talk about my side projects even though these activities demonstrate my complete knowledge and skills. (During the day, I work primarily with Microsoft technologies, but with side projects I have utilized Linux, Apache, MySQL, PHP, Python, etc.) The hesitation comes from not being considered since other candidates may not have side projects and, therefore, more likely to be totally focused on the company's goals (and not their own). (A discussion on when a "work day" stops would probably generate epic rants from various commenters.) Edited for clarification.
pc86 14y ago
Somewhat OT, but I'd like to see a post about why a developer should be blogging. I'd think a prolific Github repository or six-figure Stack Overflow reputation would be much more important than me throwing up a few paragraphs on the last WordPress plugin I wrote. This is ignoring the fact that most of the jobs I am applying for are not "insider" positions, but ones where the technology considerations are orthogonal at best.
- danielweber 14y ago
  I think it's the generic formula of "a great developer has these traits: <list of all traits self has>". I know I fall into the trap, too. I love projects, but I hate working on them thinking they could get me my next job. Sometimes I just want to take a private protocol apart and see how it ticks.
  - pc86 14y ago
    Agreed. And for the record, my Github repository is the antithesis of "prolific," and I generally have more cash in my pocket than I do SO reputation. :) Luckily I am busy enough that I don't have time for any side projects for the next few weeks, but perhaps soon I will be able to toss up some Arduino or C# code.
- mixmastamyk 14y ago
  Developers should be able to write well to communicate how products work to others.
Dewie 14y ago
Then a lot of companies should wave their right to every line of code that an employee makes while under our employment, both during hours and off-hours. This is a term of employment that I've read that many american corporations work under
mechanical_fish 14y ago
I used to worry about my relative lack of splashy "side projects". So I'd sit down to work on one, and within five minutes I'd be asking myself: "Should I work on this side project, or should I pick a bug off my company's bug tracker and fix it, thereby making dozens of customers measurably happier, making my manager happier, making my company marginally richer, delighting the customer-support team to the point that they high-five me in the company cafeteria, and making the product I work on every day just a little bit more satisfying?" The side projects kept losing this argument. But I fail to see the problem with that. Meanwhile, I guess I won't be getting a job at your company, but that's fine. As someone who likes his day job to be satisfying, I'm probably not a good fit.
- HarryHirsch 14y ago
  > The side projects kept losing this argument. But I fail to see the problem with that. This is the company's problem. Seriously. At places like Dupont and Merck it was mandatory for a scientist in R&D to work on projects of their own choosing and publish. The research was part of your evaluation, and if you didn't measure up you were out. I believe at least Dupont still uses this model.
- nostrademons 14y ago
  I've faced the same dilemma ever since I started working at Google (and hence, all my side projects have long since died - well, that and the rather draconian IP agreement restrictions). I think it's a natural outcome of working at a place with real users vs. a side project with no real users. But I worry that this is just another form of putting all your eggs in one basket. Taken to its logical conclusion, this works great until the market shifts around you and suddenly your company's product doesn't have users either. And meanwhile, you haven't been keeping your skills sharp so you're at a severe disadvantage when you do have to switch projects.

23 points by bradly 14y ago

If you say so. Some of the best people we've picked up didn't have significant side projects, or any side projects. And jobs here are harder than most industry dev jobs. If you're a developer reading posts like this, you should know that it's a seller's market. Work on side projects because you love them, but don't cram them like extracurriculars on your college application. Very few competent hiring managers can afford to downselect you out based solely on your Github page. If you're a hiring manager, my advice is a little sterner: unless you've got candidates coming out of your ears (Github is an example of a shop that might have this problem), don't get confused about what your job is. You need to work on two things: lead generation and lead qualification. Think about recruiting as a sales & marketing problem, because it is one. Most marketing teams don't set up qualifiers that are likely to reject leads that might close.

127001brewer 14y ago

If you’re a software engineer, you should be hacking at projects, building apps, websites, and tinkering away at things you love to build outside of work. While I generally agree (that you should expand your knowledge and skills with side projects), how many companies think that these extracurricular activities are taboo? As someone who is looking for a new opportunity, I often hesitate to talk about my side projects even though these activities demonstrate my complete knowledge and skills. (During the day, I work primarily with Microsoft technologies, but with side projects I have utilized Linux, Apache, MySQL, PHP, Python, etc.) The hesitation comes from not being considered since other candidates may not have side projects and, therefore, more likely to be totally focused on the company's goals (and not their own). (A discussion on when a "work day" stops would probably generate epic rants from various commenters.) Edited for clarification.

pc86 14y ago

Somewhat OT, but I'd like to see a post about why a developer should be blogging. I'd think a prolific Github repository or six-figure Stack Overflow reputation would be much more important than me throwing up a few paragraphs on the last WordPress plugin I wrote. This is ignoring the fact that most of the jobs I am applying for are not "insider" positions, but ones where the technology considerations are orthogonal at best.

danielweber 14y ago
I think it's the generic formula of "a great developer has these traits: <list of all traits self has>". I know I fall into the trap, too. I love projects, but I hate working on them thinking they could get me my next job. Sometimes I just want to take a private protocol apart and see how it ticks.
- pc86 14y ago
  Agreed. And for the record, my Github repository is the antithesis of "prolific," and I generally have more cash in my pocket than I do SO reputation. :) Luckily I am busy enough that I don't have time for any side projects for the next few weeks, but perhaps soon I will be able to toss up some Arduino or C# code.
mixmastamyk 14y ago
Developers should be able to write well to communicate how products work to others.

Dewie 14y ago

Then a lot of companies should wave their right to every line of code that an employee makes while under our employment, both during hours and off-hours. This is a term of employment that I've read that many american corporations work under

mechanical_fish 14y ago

I used to worry about my relative lack of splashy "side projects". So I'd sit down to work on one, and within five minutes I'd be asking myself: "Should I work on this side project, or should I pick a bug off my company's bug tracker and fix it, thereby making dozens of customers measurably happier, making my manager happier, making my company marginally richer, delighting the customer-support team to the point that they high-five me in the company cafeteria, and making the product I work on every day just a little bit more satisfying?" The side projects kept losing this argument. But I fail to see the problem with that. Meanwhile, I guess I won't be getting a job at your company, but that's fine. As someone who likes his day job to be satisfying, I'm probably not a good fit.

HarryHirsch 14y ago
> The side projects kept losing this argument. But I fail to see the problem with that. This is the company's problem. Seriously. At places like Dupont and Merck it was mandatory for a scientist in R&D to work on projects of their own choosing and publish. The research was part of your evaluation, and if you didn't measure up you were out. I believe at least Dupont still uses this model.
nostrademons 14y ago
I've faced the same dilemma ever since I started working at Google (and hence, all my side projects have long since died - well, that and the rather draconian IP agreement restrictions). I think it's a natural outcome of working at a place with real users vs. a side project with no real users. But I worry that this is just another form of putting all your eggs in one basket. Taken to its logical conclusion, this works great until the market shifts around you and suddenly your company's product doesn't have users either. And meanwhile, you haven't been keeping your skills sharp so you're at a severe disadvantage when you do have to switch projects.