I don't understand the logic of this article. My side projects tend to be efforts in self employment, not 'click bait' for an employer. While not everyone has the same approach, this article seems to imply the only value of side projects is for future employers. I'd hate for people to get the wrong impression about the value of these projects.
And many times, my side projects are my way of relaxing. Some people relax by partying, some relax by walking their dog, some relax by spending time with their kids. And my choice of relaxation time is often just building something interesting that has zero self-employment or market value, but is just funny or cool. It is refreshing to do something for pure happiness and fun, after dealing with the unhappy real world, is all about traction and money and not happiness.
I also have another set of side projects with specific intent to learn something new, which I consider an educational time investment in myself.
Neither is "click bait" for employers, and I consider neither to be a "waste of time".
Like you, I find it extremely relaxing to build pointless things. Do you have the same trouble I do in explaining that this isn't "work" to people close to you?
This is why I participate in the Stupid Shit That No One Needs And Terrible Ideas Hackathon every year. It's super fun to build goofy things that you can laugh about with friends.
I can’t tell if you’re saying everyone outside software has goofy hobbies and this is nothing worth writing about, or if you’re trying to say that software-based hobbies stop software developers from doing their day jobs and paying the bills related to your list of other humans.
My "side project" actually pays the bills yet I'm not sure if my wife will ever fully understand that, despite it technically being "work" (and despite some rare complaints/bad days, like anything else), I actually thrive off of the challenges and sincerely enjoy it. And so working >8 hours on it isn't just because I "have" to, it's often because the challenge is so fun & thrilling that I _want_ to.
Of course, balance is important and I won't try to fool anyone -- it's something I'll likely always be working to improve.
> this article seems to imply the only value of side projects is for future employers
It doesn't imply that. When writing about anything, explaining all the things that you're _not_ talking about is a great way to never get to the point.
Determining that the post is about side projects aimed at landing a job is a task left to the reader. If the title didn't get you there, the second sentence is here to help: "For the distinct purpose of getting a job in tech, side projects are either a great use of your time or a great waste of your time."
"Distinct" as in specific — "The following may not apply if you're objective is not specifically to getting a job in the tech industry."
If you'd like to talk about other great uses of side projects, I think that's a completely reasonable discussion to have. Simi-related threads in top-level comments are common: "I know it's a little different form what the article is talking about, but I'd like to talk about…"
Everything that I have, my companies, my capital, my house, comes from my side projects being transformed into self employment, recurring revenue or reputation for me or my team.
You have to consider that side projects will start small, like a plant, they are very easy to squash and destroy, but takes an enormous effort, and your rewards come later, when you have a tree.
Even a company like Apple could not make something like the App Store earn more than a couple millions the first year. Larry and Sergei tried to sell google for just a million dollars and could not.
A side project takes so much effort that I would have never ever considered making the effort just to show off to companies, then abandoning those(as you will be forced as you have a job that takes most of your efforts). Side project is like your children if you create them.
It is a big error to try to make companies value your projects. They will pay you 0$ if they can(even if they know it is a great project, more benefit for them).
There are much better ways to show off in front of companies if that is what you want.
Side projects are more and more being touted as a way to "stand out" from the enormous crowd of people trying to get tech jobs. A company choosing among 100 candidates, all things being equal, may bias towards the few with active interesting side projects. If you accept that, then starting some kind of side project would be worth it.
Side projects got me jobs and when I do side projects sometime they are for fun and sometimes they aren’t . I think a better objective is to do fun / cool side projects and try to align them when you want to.
Most of them couldn't tell the difference, so they pick some internet advice like "hire people with many side projects!", which is why job seekers are told to create side projects to improve their chances.
Hedging risk by doing a side project relevant to your employment interests is perfectly valid. If you are employed you have the luxury of doing something random in your off hours. If not, you need to be very mindful of what happens if your side project goes nowhere and your savings run out.
Yeah, side projects should be for pursuing personal interests... which has the side benefit that if you happen to later be interviewing for a job and mention your side project it will be much easier to talk about.
I totally stop my side projects when job hunting. There really doesn't seem to be any practical time. Often I find that I need that time to study new concepts and play catch up improving my skills so I can be even more presentable to a company. I mean the tech industry, especially software engineering is rife with testing merge sorts, parsing csv files, and non-real world coding challenges when interviewing. Who has the time? Let alone the shear amount of frameworks and systems you need to understand depending on the companies specific pipeline. Forget your side project and reduce the strain.
I had never even heard of HackerRank before applying at a few places. I was supposed to write a binary search tree algorithm without using anything except the language docs. I rarely write anything new without a quick search, it wastes valuable time reinventing the wheel.
I find I often forget basic language syntax when I don't have adjoining lines to crib from, say, when white boarding. And that's with languages I'm actively working in—I'm hopeless in anything I haven't used in a couple months, even if I wrote in it daily for the five years before that. I'll flat out forget which language features it supports, or how to address them.
Same. 25 years experience. (especially now that I have about a dozen obsolete languages under my belt). This is fine in daily practice, and does not interfere with productivity. But getting through that hiring filter; devastating.
I hope that this is because I have, over the years, become like Liezi's good judge of horses[1], but fear it's just that I have a bad memory for programming language details. Probably it's a bit of both.
I had a really good tech interview a while back, where I had to reverse a string in place, and then reverse only the words in a string in place (so "this is a test" => "siht si a tset")
Anyway, I had a couple of off by errors. The interviewer asked me if I was sure I didn't have any, so I had a look through, stepped through the code, and lo and behold, I did. While I was doing this process, we ended up having a discussion about how unit testing would help avoid problems like off by 1 errors, and would make iterating through the code and refactoring a lot easier.
That's what a good tech interview should look like, not expecting someone to write perfect code, first time.
On a side note, I didn't end up getting the job, since they had apparently hired someone the day before I came in for the interview. Apparently I managed to apply for the job the day they closed applications, but they asked if I wanted to interview anyway, out of courtesy.
i did my last search in two milestones: build things, do interviews.
i did one "field of dreams" project using a stack that i was mostly familiar with already and several "effort" project to learn and demonstrate skills in a different language/stack (Clojure).
totally agree that once the interview screens started, that side-project time got scaled back to vanishing. however, i'm really thankful that i had enough time to do the side project milestone as well as the interview proper, because i wound up finding a role developing in Clojure. i don't think that would've been possible had i not invested the time in side projects before starting in on interviews.
To be honest, this submission gives me the impression that it's clickbait material. The article is field with platitudes and small things you can glean from Cracking the Coding interview book. Judging from the user's submissions, this seems to be self advertising.
Regardless of how impressive your side project is, unless it is a very special exception (e.g. you’re head maintainer of a linux distribution or open source tool the company hiring you is extensively using and needs your expertise on), it’s only getting you into the door to talk to people, and it’s not a route around the interview process.
So, ultimately that process is going to be whiteboard coding, because it (let’s be honest) basically always is. That whiteboard coding tends to draw its questions, most often, from question pools like those on Leetcode.
This means if you’re resume’s strong enough for someone to talk to you, you probably should be optimizing to pass the whiteboard section.
Yes/No -- In my last job hunt, I talked to more than one employer who said they had declined people who rocked the whiteboarding, but had nothing else to show. People are building teams who can work together, communicate well, and dedicate their efforts to completing projects together. Good whiteboarding is a prerequisite to being part of a team... but not the entirety of a hiring decision.
Having side projects to show doesn't prove one can work together on a team, communicate well, nor dedicate their efforts to completing projects together.
a lot of technical interviews use super contrived problems for you to work through. There is a non-zero chance that a super experienced engineer could be qualified for a job, but stumble on the applied questions asked by some interviewers.
leetcode is intended to help that type of interviewee get up to speed on a lot of those sort of technical interview questions that they may not have directly thought about for years.
I think it's because such a small percentage of competing applicants are likely to have substantial projects anyway, you may as well focus on the common denominator of the interview, which are the data structures and algorithms questions.
It would be interesting to know what proportion of employers even look at your Github, let alone dig into detail enough to investigate your side projects to this level.
I work on quite a few side projects in my own time because I enjoy it, but I've never been asked about my projects on Github or my blog.
This surprises me all the time. Most people hire me without ever doing any research on me. I get to a job interview and they ask me if I know what "object oriented programming" means. Had they searched for my name, they would have found my name on the Wikipedia page for object oriented programming:
I have to assume that other people put a blog on their resume, but its a mostly un-used site, so the maybe the employers get in the habit of ignoring personal sites? I've written on hundreds of technical topics over the years, but no one is ever aware of this when I arrive in a job interview.
Likewise, no one has ever checked my projects on Github.
I don't even cop to having a github, and I don't have anything useful on my "public" github.
But where I have public-facing projects' URLs on my resume - interviewers seem to be completely clueless about them. They'll ask me questions about a topic, and I'll point them to that URL on my resume as an example of how I know that area, or did that task.
It seems like they only read the "skills overview" blurb at the top, that we put there to get through the search filters - and they don't read the work history.
When I hire, code samples (like Github contributions) are my first screen of a candidate before I decide to interview them. It is proof of ability to write code and a testament to what I consider to be quality. I do this in lieu of whiteboard challenges or Fizzbuzz tests.
I always do. For mid-to-senior it's more out of curiosity, but for entry-level it can impact my decision, especially for bootcamp grads.
I know the prevailing sentiment on HN is sometimes that hiring managers like making candidates jump through hoops to make themselves feel important, but I don't think that's the issue here. It's simply that someone who came to programming late in life is at a severe disadvantage compared to people who have been interested in it since fifth grade, and some kind of programming in your spare time is the best (only?) way to catch up.
Contra the article, I don't care if the project shipped, or if it's thoroughly unit tested, or how many iterations or whatever. I just want evidence that you're in the larval stage.
Whenever I interview candidates I am always looking for things to talk to about with them so if I can find information on previous projects or publications of theirs then that is a good entry point to learn about their expertise.
That’s just flat out wrong. My GitHub profile has gotten strong interest from companies, including the famous big tech companies (I work at one currently), due to having a ton of open source contributions to major projects & smart analysis/questions through participation in open source communities. I also have gotten asked a fair number of questions directly related to my profile during interviews as well, often demonstrating that the interviewers took a non-cursory look at it.
The thing that companies don’t generally care for are non-impressive GitHub profiles. I don’t care about seeing code that doesn’t stick out as not from a craftsman, or just docs contributions when I review resumes/GitHub profiles. I want to see code demonstrating standard industry practices, and smart architecture decisions. I want to see an understanding of testing.
It’s up to the candidate to make good use of GitHub to impress. Most fail at it, but that does not mean that no one looks at GitHub profiles - on the contrary, they usually are quite revealing.
That's flat out true. Companies didn't even open the github link.
Your experience suggests that one should contribute to the major open source projects used by the big companies to get noticed by them. That's very different from the usual advice to write side projects.
Why do I have to build side projects and memorize algorithm trivia to prove to employers that I know enough to do a job? What's the value of my degree if it doesn't tell employers that I know what I'm talking about? Why are software engineers the only ones with this problem (can you imagine if doctors had to memorize random trivia to get a job)?
> Why are software engineers the only ones with this problem (can you imagine if doctors had to memorize random trivia to get a job)?
Because we don't have professional organisations like doctors and lawyers do.
> What's the value of my degree if it doesn't tell employers that I know what I'm talking about?
Well there's an open ended question. For one, assuming you went to a reputable university, the degree says that you understand the foundations of computer science, which isn't particularly relevant to what most of us spend our days doing. Understanding computer science fundamentals isn't a huge help when your building a CRUD web form and sticking data in the database.
Then there's the profit driven centers that universities have become, it's in their best interest not to fail anyone, that would decrease their revenue. I've had interns that are freshly graduated with masters degrees that would fail a CS101 test if you put it in front of them.
> Why do I have to build side projects and memorize algorithm trivia to prove to employers that I know enough to do a job?
Because employers are trying to compensate for the issues I mentioned in the cheapest, quickest way possible. Sure they don't do a great job of it, but neither does anyone else in the pipeline.
> (can you imagine if doctors had to memorize random trivia to get a job)?
Comparing yourself to doctors, with the implication that it's easier for them, is pretty silly. Doctors have to memorize perhaps the most shit to get a job, and are frequently reevaluated on it through examinations to keep their license.
> are frequently reevaluated on it through examinations to keep their license.
Not in the US. Keeping your license, whether for medicine or engineering, is just a matter completing continuing education units. There are nearly worthless activities that count towards CE units, and I have yet to see any that are actually graded (they are all just butt-in-seat things).
People here seem to have anloftier view of licensure than it deserves. Sure, it's better than nothing. However, licensed != competent and should never be used as a substitute for measuring competence.
Doctors have to memorize a lot of information to just do their job. They have to have the answers to a lot of things or look incompetent as Googling would make people lose their trust. I think we have it cushy.
My experience is that side projects mean nothing to employers (as an experienced dev) and memorizing algorithm trivia is rarely needed. Usually doing a coding test with internet access is the norm.
Apparently there are a lot of people applying to developer positions that make it to the technical interview and don't know how to code. I have never encountered this personally, probably because the people I have interviewed have always had prior work experience as developers.
I am confused now. I have been working on my side project almost 2 years (started working on it a couple of months after my first job in it). Firstly my plan was to deploy this project and open to users finally, however after some time, I realized that there is a lot of similar web pages and it is not a good idea. So I decided to work on this project as some kind of battlefield for testing new frameworks. Finally I ended up with a quite big project (about 390 commits, front-end, and back-end part). Overall the quality of this project is not so good in my opinion, I see a lot of places where things can be done better. Do you think does it worth to put information about this project and link to the github? Even when the code quality is not so good, code coverage is low?
I would also love to know the answer to this. I have an app that is nowhere near what I would consider ideal quality-wise but it's a project that is done, deployed, and open source. Do I even mention it? I wouldn't as it stands.
I don't know about how bigger firms feel about it, but I'd probably not regard it as a positive. Only show me code you think I'd accept at my work place.
For juniors it could be a positive signal though, if you're the kind of person that always looking to learn new things. Depends on the situation if you should show it or not: who are you trying to come across as?
If you have the resume, don't show it. Otherwise, do show it and let me know what parts you like and why some other parts are WIP (comments are great here).
Another thing to take in consideration is your own criticism. You might be really critical of the project since you're an exceptional programmer, and great programmers tend to move forward quickly and look back at their own old code with distaste. :)
I would say, show it and be prepared to talk in the interview about what you have learned and would do differently the next time 'round. Any sensible employer wants employees who will learn from experience...
Another recommendation I have is to pick side-projects that are small enough in scope to get finished. There's more satisfaction in that and also more useful for interview situations, arguably.
I was a bit nonplussed reading this as well. If I'm interviewing a future colleague I am especially curious about their side projects on GitHub ... but I don't care how well what they have done dovetails with my current technical needs, or many "iterations" they have shipped, but rather: are they passionate/do they make things they care about? Can they write clearly? Is the code of high quality? Have they interacted with others well (respectful/helpful tone in PRs, Issues, etc.)? I find most candidates don't bother with half, or any, of these, but the ones that do tend to be good ones (and, alas, are also employed already).
My own experience as tech recruiter, who looks at dozens of resumes a day, is that I only take some minutes to review your publicly available code.
If I see commented code, rough violation of coding standards etc., that is bad and I will ask about it.
So if you share side projects, remember that it gives the interviewer "attack surface" to disqualify you. However, good interviewers won't look 20% for your weaknesses and 80% for your strengths.
If you are a regular open source contributor, I might use this information to argue that you are be better than other engineers who don't regularly code in their free time.
Be careful, the coding in free time is an interesting signal to be sure, but considering one engineer to be better than another purely on the basis that they code in their free time is anti-diverse
But if I only care about coding capability I might want to hire the one who programs 16 hours a day and not just 8 hours a day. We live in a free market and I can optimize for such parameters, if I want.
Obviously, if I really take this as a main parameter, I will be hiring probably 22 yr old kids with no relationships. I only see an indirect relationship to diversity. Still, good hint to keep that in mind.
Personally when I was unemployed my side projects helped me learn new skills, and fit my desire to do something with my spare time. Applying for jobs was a pain, building something was enjoyable and gave me hope
Feel like some of the other comments are sort of missing the point of the article although the author probably could have been clearer in what his point was.
My take is that this is targeted toward people without any sort of traditional/university CS background trying to get into tech from scratch and in addition to taking a basic javascript course or whatever are following the standard advice you hear of "you need to have some side projects to get employers attention." Think its just trying to give some pointers to people going down that path with the very specific larger goal of it leading to a full time job.
So ya, I would bet the author would probably agree that side projects are almost valuable in and of themselves, but some are going to be more likely then others to lead towards a full time position, etc.
Another great way to impress employers (and in some ways much simpler): write blog posts about what you've read, learned or done. Even if it's on a current employer's blog.
Semantic Image Search: takes high dimensional images vectors from a Deep Convolutional Neural Network and searches for similar images using Locality Sensitivity Hashing.
Search is O(1) + O(n/B) where the last term is a small fraction, B, of the complete search space n.
The goal was an E2E machine learning project: modeling, training, validation, deployment and serving. Using VGG-mased CNN w/ tensorflow, redis for database, Flask for web frontend , tensorflow serving and docker+kubernetes for orchestration.
It all works on my local machine but when I went to deploy it to my prod website the tensorflow serving part broke down and I haven't had time to fix it yet :(
It was just supposed to be a one weekend project after I got the inspiration from the AlexNet paper, but it took over a month. Most of the time was fighting k8s.
So another data science project doesn't make it to production...
Man this article is so flawed, it's not even funny. I was going to comment earlier today but I was certain it would get buried. I'm a bit disappointed that it's still on the main page. Here's my take..
> Make sure your side project isn’t a waste of your time
A side project is never a waste of your time. It's a way to build something new, to exercise your creativity and passion, and to (when it's all said and done) ship something! I'd wager that 90%+ of "coders" have never built something from zero to hero. That is inherently a valuable thing, regardless of what your future boss thinks.
> Your side project, by itself, probably won’t get you a job
Okay, so? I'm pretty sure no sane person is going to go through the hard work of building a side project to impress during an interview. Not only that, but for a side-project to be successful, it also needs marketing, PR, networking, and so on. You probably won't have to do any of those things at your next programming job, but you most definitely need to do it when launching a side project.
> 1. Is your side project relevant to the job you’re applying to?
Again, who cares? Side projects should never be contingent on what jobs you're applying to.
> 2. Does your side project have depth?
Doesn't matter. A side project can be as shallow as Snapchat 1.0 (disappearing images? Sign me up). Run with it. Build something awesome and win at life.
> 3. Has your side project at least had 2 iterations?
I actually agree with this. Most of my MVPs are kind of shitty until I show them to a select group of friends and family that more often than not rip them to shreds. Fail fast, fail often.
> You have to bring attention to your side project
Yes, yes you do. But guess what: looking for a regular 9-5 programming job is completely antithetical to "bringing attention" to your side project. The latter of which involves emailing zillions of people, setting up mailing lists, getting featured on blogs, product design, going to talks, giving talks, and so on.
The article also misses the point about intrinsic VS extrinsic motivation in software. Personally I think being motivated by money, careers, nice cars — whatever — is just fine. But I think the only way to know if you really want to stick with Programming, and especially any particular branch of programming, is by finding out what intrinsically motivates you.
That can be your rock to hold onto as burnout approaches...
> I'd wager that 90%+ of "coders" have never built something from zero to hero
I think that's probably very true! Shipping something is such a useful exercise. You learn so much by going through the full process, rather than just starting and then later abandoning something.
