Ask HN: for senior positions is it advisable to list side projects on your CV?
When I was younger I used to list side projects on my cv and employers used to take notice. I find now they don't seem to care, usually are only interested in employment history and tech tests.
I also wonder whether side projects speak to the fact that you're not concerned enough with your employer's bottom line. I remember when Ken Cosgrove, in Mad Men, had a side gig as an author and got published in a magazine. Roger Sterling told him, quite sternly, he had to choose between the job and the gig.
The thing is I would actually appreciate if a potential employer asked me about the above two projects. I think they demonstrate some of my skills and would be interesting to discuss.
What do you guys think: Do you guys still list your side projects? What about for jobs more senior than senior developer?
156 comments
[ 8.5 ms ] story [ 270 ms ] threadSide projects = Fun project that demonstrates skills
Side business = Ongoing obligation that could distract from your job.
Be careful in how you present them.
Side business actually is. Because it means you can build, launch, acquire, and retain; and you have to deal with customers.
This means you do have skills to be in a senior position.
For this reason, I'd default to no, don't list side projects, unless you make it a strong argument for the position you're applying to.
Are you a major contributor to a tech used in company? Have you written a book about it? Did you grow a community? Have you reached significant traction or revenue?
Any yes to one of the above, if they relate to the position, can hint you into mentioning your side project.
Other than that, your side project will be seen as a hobby and not an achievement, and will be disregarded.
Note: some nuances may apply, so take this as the generic advice it's meant to be.
I think you’ve misunderstood the purpose of a side project for engineers. They’re supposed to be hobby projects that demonstrate the developer’s abilities as well as their commitment to following through on projects.
The OP’s projects are perfect for listing as completed side projects on a Senior Engineer resume. I wouldn’t hesitate to include them on a resume and describe the technologies used to build them.
You definitely don’t need to demonstrate significant traction or revenue for an engineering side project, nor do you need to write a book about it or build a significant community around it. These are ridiculously high standards for including a development side project on a senior engineer resume.
Frankly, if someone were to list “side projects” with significant revenue and a large community, I’m going to assume it’s a business and not a side project. We’d have to have a conversation about how much time and energy it’s going to take away from their employment, and how we can cleanly separate it from interfering with their job. Showing employers that you’re running a side business with significant revenue and therefore significant needs isn’t exactly a bonus when it comes to hiring someone. A fun side project that demonstrates their skills is a bonus, however.
Most managers at my company view side projects positively. One of the main reasons is that it shows the person has a creative mind and is at least a little passionate about technology/coding and learning on their own.
If you are interviewing for an Alcohol friendly company then the calculator might be a fun side project that shows you know Android development. Raytheon would probably love the ballistic energy calculator. If your interviewing with the quaker church then both items will probably have you rejected for culture fit.
I might as well add the link. https://play.google.com/store/apps/details?id=com.blogspot.t...
Perhaps, but you have to assume that many of those who are hiring will do exactly that. That's the meta-game.
There's a basket of opinions in this thread and they are all valid and informative, even if they are mistaken.
Side projects help junior candidates without relevant job experience most.
I don't agree. A side-project might demonstrate those things, but most of the time, as an interviewer, I'm interested in a candidate's side-project because it shows curiosity and interest. It says something about their character.
If you actually went beyond basic setup and dealt with real enterprise/production level issues then make sure to point it out. I assume that “I learned it for a side project” means mostly happy path stuff.
All bonus points, especially if the company uses k8s or if you can answer aptly "why did you choose k8s?"
FWIW, I'd expect 3 kinds of answers: 1. "This was a right fit because..." 2. "I knew this was NOT a right fit but I wanted to learn" 3. "I thought it was the right fit but I was wrong because..."
But you have to come strong with the side project. The site/app better be up, you better have a repo, and it better be something beyond a todo-app or a bootcamp project.
Honestly, finding a well maintained and substantive project in a person's GitHub would impress me, and that candidate would certainly stand out. So often people link their GitHub accounts, but when I visit, I only see toy projects and book exercises.
As part of my hiring process I've been giving out a simple take home coding challenge, but I offer to instead review a project you've already been working on if that's your preference, because I feel bad making people do work for a job they don't even have yet (I haven't been able to convince my boss to let me pay people for their time on the take home challenge yet).
Mine has a few gone nowhere forks, scrap books, silly projects etc.
We've been working hard to build a library of the best engineering resumes we've seen - you can get an idea for best practices here - https://www.rezi.ai/resume-templates?search=developer&resume...
But interviewers are still human beings, and so a link to a visually impressive, interactive and accessible side project will probably get you some credit. My favorites were multi-player games.
If the side project makes money, that's a whole 'nother consideration. Everyone is likely to be impressed.
At any rate one question I have had in the last few years (maybe due to age) is how do you keep up on latest technologies - I then have side projects and articles I can point to as a way to learn new things.
Or, if it's on the resume to demonstrate you're still actively hands on and you believe that is valuable to the role.
However, if you wouldn't talk about it in an interview, don't put it on your resume. If it wouldn't help you get the job, I wouldn't talk about it in the interview.
In other words interviews are human and messy, not strictly logical.
Hyperbole time but I think it conveys the message: People do side projects for better reaons than they do professionally. At worst it's because they want to quickly learn/achieve something for their next job. Compared to professional experience, where at best it's because they were paid to do it and any fun or whatever altruism is a byproduct.
There are lashings upon lashings of caveats and nuance of course. For a senior role I will still be looking for interpersonal skills not just technical achievement. Part of being a senior is managing yourself, selling your ideas/concerns, mentoring and managing peers, and to some extent managing your managers.
FWIW your side projects are great examples and I'd would be impressed.
I could do 2 hours of productivity after the kids go to sleep and I'd still have 2 hours for entertainment. I exercise too.
So let's make it even more reasonable. How about 30 minutes, 4 times a week?
>Meaningful progress
So then do an hour or 2? I make progress in 30 minutes and sometimes keep going. If the point is for a resume, you could even do a 1 or 2 week sprint.
I suppose you could even work on it while the kids are awake. My kids love Alphablocks.
If you don't have a personal side project, the issue isn't children. It's desire.
i much rather do something else. play a videogame, read a book, watch series. i already work 8~10h a day, after that, i want chill and think about something else that is not code.
Btw have you considered something drastically different than your current code? Embedded comes to mind, it's half electrical engineering and lots of instant gratification.
But in general, nonfiction books could help you ace an interview. I wowd some people by merely talking taoist philosophy and how despite having diverse skills, there's something to be said about sticking to your role.
You forgot the second part of my sentence:
> or who choose to pursue non-IT hobbies to keep a work-life balance
Beyond that and the burnout is real.
I can hardly imagine how someone could build anything at 2h/week. 30 min is barely enough time for the brain to switch gears.
I fully get how someone does not have time for side projects - they have life besides work, while I barely do.
Both count for the interview purposes.
Coincidentally I wrote some notes about resume building a few days ago: https://simonwillison.net/2021/Jul/17/standing-out/
While it is unfortunate that side projects have some selection bias against those who are time-poor, it also feels wrong to me to discriminate against people who can demonstrate their skills and impress through their side projects.
Like, if there are two candidates and all else are equal, and one has a really impressive side project that demonstrates positive traits (whether it's technical expertise, novelty, relevant skills, or communication/community), it's going to be hard to... actively ignore that?
In 15 years I've had 1 side project. I'm a staff engineer.
It's just an additional piece of signal that may help a candidate when relevant; the same way doing great during the interview can help a candidate.
I’ve also had people show me pics of their wood working, mountains climbed, hunting trophies, and even 3d models. I think only one time did someone say they did nothing but take care of their spouse. We talked about that, as I have some experience there. My job is to see how you solve problems and ensure they’re compatible with our problems, along with skill set, etc.
The other thing that it might be is rational pessimism. A lot of ideas would take a phenomenal amount of work, and as a senior you probably see those pitfalls and that work right at the beginning, while someone more junior might attack a problem - and eventually succeed precisely because of their irrational optimism.
There was a fun quote on the Alexander long Piano story:
> I think because I was so young I absolutely knew it was totally possible to do, I was fully determined and without consulting any professionals I had no barrier stopping me.
I think the implication there is that if he had consulted professionals, the enormity of what he was taking on might well have crushed the idea.
> I have pages of side project ideas
Well evidently not for you. But please don't assume everybody's mind or personality works the same way yours does. You were told to not judge everybody by the same subjective yardstick and your immediate response is to.. project and judge everybody by the same yardstick.
The ability to generate side project ideas or the interest in investing huge amounts of time into a project on your own time are largely orthogonal to the ability to actually build things when it's your job.
The point I evidently failed to get across was that there are lots of ideas around and you don't need to generate them yourself. People who like generating ideas generate far more than they can hope to work on and often would love to see others carry them forward.
I consider myself senior, but I haven't really lost my optimism. I don't think becoming a senior should mean losing optimism. For me it's the opposite. I have much better understanding how to achieve something than before so I have the confidence that I can definitely do it. Maybe it's my personality though, that instead of thinking what the obstacles are, I think how I'm going to visualize and build it.
But I can see how it's different from plenty of other folks, and I think it comes down to personality. Usually I don't or can't think of challenges/weaknesses up front and I like to just dive in. I have been criticized and given feedback of having this flaw, but I have unrelenting belief, that I can solve everything on the fly and for me it has worked in the past.
It's like my mind is unable to bother or concentrate on what the obstacles will be. And it's frustrating because many people expect you to come up with a plan and potential obstacles beforehand while my mind just wants to jump in.
Most advice tells you to think/ask questions/plan before you code, but I code while thinking and iterate on that code. I can't think or concentrate if I'm not coding or actively solving the problem. If I try to plan something, it's half-assed and to me it seems useless and it kind of pretends to be a viable plan and when I finally do it, I do it completely different from the plan anyhow.
Not saying it's the right way, but maybe it's some sort of thing similar to ADHD where I just can't focus without building. And I am very impatient as well so if there's something that needs to be built or solved I will need to jump on it asap and get it solved asap. If I'm not building and am planning I have this increasing anxiety, that I should just be doing it.
More specifically:
How do you handle collaborating with other teams if / when your work is a dependency for them delivering theirs?
How do you deal with requirements, use cases, and other pieces of functionality if you just jump into coding?
This has happened to me sometimes.
It depends on how much time you spend on side projects I guess. It also helps for me to have a fixed work schedule.
For a while indoor 'cycling home' as I did when I went into an office more worked well to delineate the day, shower, and get on with something of my own feeling refreshed. I still do it, but I suppose I'm used to the feeling or whatever, I don't really find the same benefit any more.
Meanwhile, if you ignore the side project, that candidate isn't disadvantaged as a result. They're just given the same consideration as the other candidate, not more and not less.
How you choose between the two at that point is perhaps more difficult, but the playing field is still level. The single parent still has a fighting chance against the person who has the time and money to do extra work for themselves.
The better question is if one candidate has a strong set of work experience but no side projects, and another candidate has an underwhelming set of work experience but a strong set of side projects, does one get valued over the other or are they given equal weight?
If they aren't given equal weight, do you understand the reasoning why (or is it just because they think side projects are cool and want people like themselves).
And side projects are side projects. I was fascinated by a candidate's beer brewing project (there are some very relatable skills in management and organisation, supply chain dependencies, etc) as one example of a non-tech side project.
(Unless, of course, this candidate was starting a brewery, in which case, that is a hobby turned side project.)
Some of the best engineers I've worked with had exactly none, and very full lives outside of work. But you could tell they punched above their weight just by looking at the resume.
It is really no different then working overtime same amount of hours.
This is true and should be considered, but it’s also kind of the part. If the goal is to find the best candidate, then discriminating against people who won’t have as much time to do side projects, read, study and train more, etc will be likely.
I think it’s fair to consider these things and candidates shouldn’t be treated equally in this way.
There’s nothing unfair about preferring to hire someone who’s personal time is spent working in the same field as their job. All things being equal, I’ll pick that candidate over the alternative as it demonstrates genuine interest in the field as a pursuit, not just a career.
The problem is that if you want to pay for a quality engineer those are things that signal quality.
Many people didn't have time to go to university because of caregiver duties. Many could not afford to go to university, but it's still a huge and reliable signifier of quality. The same can be said of previous jobs. Not every candidate could do a job with a reputable company because those require more work (think Amazon) and your off-job duties might conflict with that.
In the end, you are going to discriminate against someone for some circumstance of their life if you screen resumes at all. There needs to be a balance but you can't throw out an entire metric because some people don't have time to participate in it.
EDIT: I want to point out I have a lot of family responsibilities. I live with my parents and got married young so I was never as single and as free as my colleagues. I still don't think it makes sense to ignore a person's resume because others may not have had the chance to have as nice a resume.
To be frank, the job of a hiring decision-maker isn't to treat candidates fairly, it's to hire the best fit for the role based on the available signals. It's the job of the candidate to send the best signals they can, however they go about doing that. One thing we'll probe for in our interviews with more experienced candidates is what kind of experience/lessons they have from their former employers, for example, and that can weigh in their favor if there's conceivable overlap with what we're doing.
But I would say don't give any single signal undue weight. Side projects are nice, but not mandatory. Heck, we've even hired people who bombed our programming test because they did okay in the post-test interview (where we'll usually see if they can work out where their solution failed).
It could be a home automation project or applying tech to another interest.
It’s entirely up to the individual to take initiative in their own self directed learning.
Quality is far more important than quantity.
I love hearing about non-professional things. Coding outside of work is actually a negative for me, because I assume you are going to get burnt out. I WANT you to have a life outside of work, because A) you are human and deserve that, and B) you are more productive during work. I'm fine if you take a few days off to run an ultra-marathon, or take off a few hours early to catch your kid's baseball game, or care for a family member, whatever. Well-rounded people are better at writing software, in my experience, and better to work with.
Does it? really?
> A VP's side project would scale up to a viable business of its own
Why? I don't follow your logic here, or we are using different definitions of side-project.
The more senior you get, the more the biggest hiring risk becomes sociopathy rather than incompetence. Most VPs of Engineering are basically decent at the skills required for their job. But a lot are duplicitous or machiavellian and aren’t going deploy those skills in a way that’s aligned with the broader organization.
Having a stupid little side project, one that has no tangible business or career upside, is a marker of sincerity. It shows that the person has genuine interests outside raw ambition.
- Algorithm which refuses loans to black people.
Not needing it is conveyed in a thousand ways. Personally, I think being your authentic self is the most important aspect. If you’re proud of your work, list it! Side project or not, it’s still your work and is a reflection of the kind of work you can do for them.
I don’t think senior vs junior is particularly relevant. People care about your work history, but as long as your projects are listed under “other” then there shouldn’t be any confusion.
That said, I work a full week as it is so I don’t invest a ton in them. Just when an idea grabs me.
When I'm interviewing someone, especially for a senior position, I want to make sure that they know what they say they know on their resume. Having code up on GitHub, or an actual working side project is a great way to show those things off.
Even code that doesn't look great, but shows that some level of effort was made to learn a new technology is okay. If anything, it then gives me a jumping off point in the interview to ask the candidate about that project, why it's in that state, why certain decisions were made, etc.
I am seriously having a difficult time thinking of downsides in listing a personal project, so I say go for it.
It's one thing having the technical skills to be able to write code and build a product. It's another thing entirely to have the focus and discipline to actually get all the work done. The side projects you listed look as though substantial effort went in to them. You said you're proud, and you ought to be. They certainly should impress any potential employer!
The only thing I look for in a resume is number of years doing development and a very rough assessment that the experience there fits with what we asked for in the job description. Beyond that, we have questionnaires that ask the specific questions we care about and real world work simulations that attempt to measure fit for the position.
To the OP: the better teams shouldn't care too much about something like this. But, I'd say add it. It shows you like programming enough to tinker. That's a positive signal to me. But, I'd never dock a candidate if they said they don't do side projects because they have other ways they'd like to use their time outside work.
That said, resumes are still useful to me for things I can't test in a couple hours. E.g.: How long is this person likely to stay? What motivates them? What kinds of environment are they used to/comfortable in?
1. they are technologies you are unfamiliar with. It's an easy and effective way to demonstrate that you are eager to learn new things.
2. they are emerging technologies (crypto, VR, AI, etc). In most organizations being a senior engineer who doesn't get "stuck" or complacent is a plus.
I'm not sure why employers would not be looking at those things, they definitely should be, it's a treasure trove of information as to who you are and how you think.
Important questions for me include: Can they build things? Do they have enough experience dealing with real-world deployments to avoid common pitfalls? Do they care about the domain? How long will they stick around?
You're correct that they're going to be of the most help early on, because they demonstrate real-world experience with production software. It's a great sign you'll be able to take a vaguely-specified user need and get something valuable done in production. But even more senior resumes sometimes still leave me wondering if they've worked at sufficiently big/bureaucratic places.
Assuming your resume demonstrates competence without the projects, then yes, they could just as easily count against you as for you.
If the project is one that's related to the domain and/or the tech stack, that's a positive sign that you're interested in what we're actually doing, and so joining us would give you something you could be very engaged in.
Otherwise, I'm going to be concerned that we're going to have to compete for your time and attention with your side project. That this is a day job you're just doing until the side project takes off. I might hire somebody like that, but one of the things I think about when hiring is ROI on my time, so if I can get somebody as good who is likely to focus better and stay longer, I'll hire them instead.
The particular side projects you list are of the kind that would be most concerning to me. They look like attempts to build actual businesses. And you have two of them going at once, which is a bad sign: if you can't focus on one of your commercial projects long enough to make is successful, maybe you won't focus on your actual job either. And there's something cold and unappealing about both of them to me. They are trying to compete with full commercial sites and prominently say they're the best, but when I try them out it doesn't seem that way.
In contrast, the kind of side project that I'd react positively to in more senior engineers is one that demonstrates competence without looking like it will be competitive, and bonus points if it's related to the domain somehow. Modest open-source projects, for example. Twitter bots. Niche Twilio apps. Small, fun services like mcbroken.com or typelit.io.
To me things like that indicate enjoyment of the work, a desire to create things, and an interest in serving users, all positive traits. But they do so without giving me questions about whether they employee will be able to focus on what they're getting paid for.
I got furious tired of this so on my last resume I treated my employment history strictly as employment history. A list of employers with dates and dates of promotions plus a sentence or two what I worked on. Supremely lowered emphasis.
I also put my personal projects into a separate section above my employment history. Between my personal projects and employment history I put in a small two paragraph section for personal bio. In this bio I mention how long I have been programming, some of my accomplishments. I also explicitly mention to carefully consider my personal projects to make an informed decision if I will be a good fit for their organization and that two of my personal projects contain over a thousand commits. I follow up that up with a mention that I am not waiting on administrative approval or a budget authorization to innovate and that these personal projects are years of experience other developers do not have.
This a recent change I have made so I cannot say if it’s successful.
With personal projects you set your own velocity. Output is the result of initiative, time spent, speed of delivery, competence in product development, and expertise on the problem.
And even disregarding this, you're still not proving my point wrong. You're saying personal projects show you can work in some set of conditions that have little to do with how work in a company gets done. Yeah, you can "prove" yourself somewhat when you're on your own, does that automatically translate to being a good engineer in the office?
Again, I have no experience hiring, but I fail to see a logic here. Good luck with trying the CV out, and do write a blog post when the results are in!
You are your own principle audience. You aren’t trying to prove anything. You are trying to build something. Unless you are the kind of person just likes building things I suspect it will be impossible to understand.
For the record, I am someone who just likes building things. I totally get why building things on your own is more enjoyable. I just don't think that an employer really cares all that much about that.
I suspect that technical competence is an irrelevant aside to what you are looking for. It sounds like you are looking for someone who can check a box, perhaps copy/paste or a gear on an assembly line. If you are strictly looking for a box checker then I would suggest hiring people who never mention personal projects of any kind on a resume. You are looking strictly for labor, a hard worker, not initiative. Work harder, not smarter, and your targeted candidate will do exactly that.
The whole point of personal projects is the opposite: initiative building something new because there is a passion to build, grow, and improve.
I think what gets lost in a lot of these threads is that different employees, and different employers, look for different things. And that's OK. There's filtering going on all sides and not everybody is a right fit.
For example - depending on how you phrase that sentiment on your resume, you might be an immediate No for our team - we are in a very traditional production mode with a procedure-focused client, and the sentence is telling me you might not follow process, wait for approvals, engage the team and client, and will just do your own thing. That may or may not be what you're saying, as I said it depends on the phrasing... But! That may be in fact excellent and mutually beneficial filtering - you probably don't want to be on my current team, and the ideal company/team for you may see that very same statement as a positive signal :).
My point is - not all filtering is bad. In threads like this we focus on "doing / not doing this on a resume will be a red flag for many employers" - but that's not necessarily a wrong thing. It's like dating - some people will advise "don't be yourself", but I ask - Why? Sure, be a good version of yourself on first date / interview, but be fundamentally honest what both of you are looking for. You don't have to have relationship with everybody, you don't have to get hired by everybody. You need to find that one person/job that works :)
How you spend your time, what you spend it on, and how you executed your vision are much more interesting and informative to me about how you'll handle your work than which corporations you've fit into a slot for.
* Behavioral interview(s)
* Some form of pair coding excercise
* System design interview
Side projects have never really come up explicitly, but my GitHub profile is included in my deets and I'm sure people have viewed it.
Or, perhaps the inverse could be the case, where i learned cutting-edge stuff for my side project, but at enterprise, sorry, they're only using legacy Java (for example), so can't really use my cutting edge experience, etc. Now, as far as certs, i agree that they should help get through the door, but wonder if pairing them with discussions about experiences gained on a side project - to play with the knowledge learned from said certs - would be an even better combo? If i was hiring, and saw that a person got some certs (and maybe checks some needed box), but also has interests in side project, again, for the experience of it...then that is well above average for sure (at least in my eyes).
I list such things as "web presence" along with my GitHub account, "technical blog"(heavy quotes here) and LinkedIn profile. I think only that last one ever gets clicked on.
Large companies especially don't care about such things, because they need you to fill a highly specific role, not one that would make use of the broad skillset required to release your own product.
My role as a contractor was always highly specific, and so were the roles of my more permanent co-workers. That being said they did tend to switch to mostly unrelated roles every few years or so.
I have a friend who worked in accounting for a large company and complained that nowadays large corporations slice responsibilities into these little bits, because it's easier to train for them this way, but the side effect was that her role had a very narrow scope and she was easily replaceable.
But, yeah, if you put in the work, it shouldn't hurt to list your side projects. But also, keep them in perspective: don't bring them up simply because they would be "interesting to discuss." By their nature, side projects don't deal with a lot of challenges of professional projects: there's usually no deadline, there's no disagreements with other engineers, they deal with a smaller scale audience so don't deal with bugs and maintenance.