Don't call them side projects. Call them apps, products and businesses. Each one used a particular tech stack, each one had a life-span of some kind: a start, a launch or a middle, users maybe, etc.
How would you explain all this work if you were hired by a small company to build them? You wouldn't hesitate to claim the years working on these interesting projects as valuable years and part of your career growth and progression.
We tend to downplay things we do or build ourselves, as if the very fact that another person (a boss) tells us to do something makes it immediately more valuable than if we choose to do that something ourselves.
It doesn't. The app you built because you chose to has just as much value as the app you built because someone paying you a monthly check told you to build it.
Wrap your 'side projects' inside a business and claim the credit for all that work.
I list my job title as “Failed Internet Billionaire” and then list the projects, the problem they were solving and the tech stack. The “job title” always gets a laugh from interviewers. Remember if it’s a technical interview, the person interviewing you most likely has done side projects as well.
If I were in your shoes, I would AB test phrasing it like this and then also as the op said in a more serious tone. Do it on some jobs that you wouldn’t be devastated if they don’t reply and see where your (I hate myself for saying this) brand gets traction
Problem there is fun dev teams can still have terrible HR filters. That's the sort of thing I'd jokingly say in the interview, but come up with a more normalized title for the resume.
Haha, that happened to me with my current job. The HR guy told me to my face that he thought my resume was unprofessional and if it were up to him I never would've gotten the interview
That is true. HR is told to filter outside of their wheelhouse. This explains A+ certifications and bullshit resumes.
In general: always be extra nice to HR. They are underpaid, under-appreciated, under-loved, put in the middle of every dispute, and told to make the impossible possible. Like IT, but with squishy meat bags.
> I list my job title as “Failed Internet Billionaire” and then list the projects, the problem they were solving and the tech stack. The “job title” always gets a laugh from interviewers. Remember if it’s a technical interview, the person interviewing you most likely has done side projects as well.
This is invaluable advice. I had a similar problem when returning to the market after years doing my own things. Someone here suggested leaning into the failed startup I’d attempted with a colleague rather than downplaying it. Despite that, I still had a tough time getting initial calls.
I eventually landed a three-month contract job. That rehabilitated my resume and I had no trouble getting callbacks once I had some recent work history. Don’t be above taking a short term gig if you find that the phone isn’t ringing. It might be the thing that turns that around.
I love this idea. I always like to see side projects (even in place of a "real job") and this seems like the perfect way to integrate it with a resume. Funny, humble, and probably a pretty honest job title for a lot of developers with actual side projects to show off.
I like this a lot. People underestimate coming off as a bit memorable and likeable, even in technical interviews. If you don't mind I'll probably use something very similar if I ever wind up in that situation.
Nice touch. Except maybe better not to use the word "failed". It's a needless association. Maybe something like partially successful internet entrepreneur.
I recommend against attempts at humor front and center like this on a resume. It’s too early.
I’m in a serious mood trying to solve a serious problem when I’m reviewing resumes. This would fall very flat with me. I would not think you were serious about finding work.
Sneak in some humor later and it might work. If I’m interested enough to read the details of your resume, something humorous later on might get a chuckle out of me.
> I would not think you were serious about finding work.
Then why are they interviewing? Taking people at face value until you know you shouldn't is an important interpersonal skill. Second guessing what people tell you is pointless. This would be one item in a list of his experience, not what you see first.
Definitely agree. It comes across sort of “cocky” as well as if their only goal was to become Billionaire and they failed at that goal.
The goal should be to build a great product, company and reputation. If that makes you a billionaire, that’s fine. Most likely you will achieve this goal but not the billionaire status.
Yep - it indicates a level of self-awareness and the ability to not take yourself too seriously, which is something I would appreciate even subconsciously as an interviewer.
I agree with the sentiment, but be careful approaching this from the mindset that closing a handful of GitHub issues or "launching" a zero-user app with no marketing is at the same level as having a job and being assigned tasks by other employees.
> We tend to downplay things we do or build ourselves, as if the very fact that another person (a boss) tells us to do something makes it immediately more valuable than if we choose to do that something ourselves. It doesn't.
It does, in the sense that it's actually a pretty high bar to get to a point where you can afford employees with management and have directed product growth. It doesn't mean it's better in an absolute sense -- sometimes the very opposite! -- but you might be setting yourself up for disappointment if you don't acknowledge the differences.
> We tend to downplay things we do or build ourselves, as if the very fact that another person (a boss) tells us to do something makes it immediately more valuable than if we choose to do that something ourselves.
Oh wow this just clicked something for me. I need to do that for me too so that I actually work on the damn things instead of thinking of them as projects on the side
Pre-revenue businesses with no product fit "I learned a lot so your startup won't fail trust me lol" and no references
But yeah they won't care about the crappy products since all the companies you interview with are doing the same, honestly the real followup question would be what do you do about references
I don’t. I’m Danish and almost everyone here has some kind of higher education, so our hiring practices are a little different from other countries.
Anyway, there is no reason to spend the time looking at what people have done on GitHub. Once you make the final five or ten candidates, we could honestly use sheer chance to decide and end up just fine. The only reason we don’t do that, is because it would be disrespectful to the applicants, but the interviews are as much an opportunity for them to figure out if they want to work with us once they’ve met us, as it is for us to do the same.
Hiring people once you move past a certain skill level is much more about finding a common fit, so that you can continue having the good culture that you have already established.
It’s not that I think you are wrong to look at github though. It’s just that I don’t feel it’s really ever worth the resources you need to allocate to get a proper picture. I feel the same way about the coding interview, it’s just a waste or everyone’s time. I mean, how can you tell if their GitHub profiles aren’t doctored? If it was too clean or too good, I’d personally be suspicious why they’d work for us.
One thing I'd like to mention about being "fine", you'd be fine, but you could be extremely well off if you are able to find the engineers that go way beyond. I find the multiplying effect of engineers within top 1% can be more than 5x. These folks will take responsibility for everything, innovate and work intelligently, tirelessly and passionately to solve any problems thrown at them as opposed to someone who will just pick up Jira tickets blindly.
It's just a little attitude thing that makes so much difference. The way salaries work, they probably don't get 5x salary so they are extremely valuable for the company and to find in general.
If you just look at general performance, resumes and things like that you might just get "rest and vest" types.
These great engineers you describe are almost never making more than 1.5x the “pack”. If you can find (or create) and retain them, it’s the best overlay I’ve ever found in employment.
> One thing I'd like to mention about being "fine", you'd be fine, but you could be extremely well off if you are able to find the engineers that go way beyond.
Really? Because that’s not what our data shows on it. It shows specifically that regardless of what we submit applicants to won’t matter. Maybe we’re just bad at hiring, but with 25 years of data from a very broad range of job types (public sector) we can at least be comfortable with the knowledge that everyone else sucks as much as us.
I get your point though. Some engineers are more valuable than others, but the thing is, that it’s not a constant and there are no real way to make sure you both attract and keep them.
We employ an engineer who just might be the countries leading techie on ADFS and how it plays into our national and EU vases strategies for NSIS certifiably authentication. With a background as a bouncer, I’m not sure how many places would have guess that when he was first hired.
I’m another such story though in a different manner. I used to be real rockstar developer, and a real workhorse. This was way before I got into management and long before I had children. Because when I did have children it turned out that may undiagnosed ADHD could no longer fit into the responsibilities of adult life and I worked myself into first a nice range of stress, then anxiety and then a depression. Now I never work more than 37 hours a week unless there is a big event, like elections, and when there is, I make sure to not-work the extra hours after wards. If you had hired me the year before my first daughter was born, you would have gotten the workhorse with a very high degree of both creativity and getting things to actually do something useful for the business end. A year later you would have been sitting with a depression stricken employee who was on partial sick-leave for 9 months.
I understand the dream of course, but unless you can show me some data on someone who figured out how to actually purposefully hire the dream employee, I’m personally going to consider it a dream. An unhealthy one even, because almost nobody is ever really irreplaceable in an enterprise organisation. Sure the loss of some employees are felt harder than others, but the truth is that IBM could stop selling consumer PCs and still trundle on. So in my opinion it’s much better to create a team of people who work well together and who have a good culture, because that means it’s also easier when someone moves on to other things. It also means that you’re not as effected by the life changes of your employees.
To add to this: it's very unlikely you have a company that knows how to manage a dream employee efficiently. Or just regular employees really.
Ask yourself this when hiring: you genuinely have a series of actually-actionable tasks ready to go for the new hire? Do you have the right resources on hand who understand that a part of their job is to answer questions about those projects from the new hire (and it will probably be a whole lot of stuff)?
The answer is going to be that you probably don't, and so whoever you hire, no matter how good they are, your company will just never know.
> there are no real way to make sure you both attract and keep them.
In my experience, it's pretty simple. Pay them lots of $$$. My circle of friends is in their 40s now, and the ones we all generally consider really good make boatloads. It's hard for them to switch jobs because most places aren't willing to pay a "regular developer" nearly as much.
Works the other way too. I had to take a paycut to leave my last company because it was full of people who didn't really like the company but couldn't find a job that paid as much, and it showed. It was really toxic.
I consider an engineer like this a "nice to have." Sure, for the time they're there and still motivated (I've been that person and after a few years the motivation and drive wore off), they can be super productive. But you can't base a business on the expectation that most, or any of your employees will be like that.
Same, but I don't get too much from it. If its not there I really don't care anymore and never ask for it. Whats the point of showcasing your github profile today? Little to no experience (entry level / jr) makes sense but for anyone else - don't fret.
I really don't and I am not aware of anyone at work who would. I rarely even read resumes and that if I am very mixed after the 1 hour coding/design/arch whatever round.
I never send my GitHub links either. If I am coding a side project and I think it has business potential I am unlikely to start with open source and if it doesn't have business potential, I wouldn't bother. Also if I am building something on the side, code is likely to be rushed and seemingly horrible.
I have no idea what in GitHub was written by the owner itself, what was copied, how long it took them etc.
People without a Github/Gitlab start with a huge disadvantage in the hiring process at my company since they don't have code to support their claims and that they can walk us through together.
Now I get some people don't have time for open-source after work but it's way way easier to ace an interview when it can be based on something you build yourself, can show and can talk about the ins, the outs and the design constraints and your architecture choices.
That's almost as poor a signal as FAANG's hazing rituals. It sends a certain signal, too. That signal, to me, isn't "this person's company really supports open source!" The signal is, "we want to select developers who are willing to produce code for literally no compensation." Think about that.
Also, the vast majority of developers don't have open source contributions or projects worth pointing to. Further, it strikes me that the ones that do have such projects can be much more selective about which company they work for than companies can be about them.
I have a mass of "open source" that I churned out while I had more free time. Trouble is it's quite out of date with my skills, especially since being busy at work. I still do tinker and release rushed code, but I don't know I want to be judged on taking someone's code and gutting it for my purposes
Do you have a backing statistic for "the vast majority of developers" or are you speaking purely anecdotally?
Furthermore you're making an assumption that anyone who has code on their github produced it for no compensation, as if that was their sole motivation.
Maybe it was a previous project, maybe they open sourced a side project that at one point made income, or maybe it was something they did as an experiment or for purely personal reasons and compensation had zero relevant bearing.
So few previous employers who bet on you and paid you hundreds of thousands on a yearly basis is not enough cred to prove that you can deliver software that solves business problems?
If you were at a place for five years, got two promotions, and shipped three products while you were there? Strong evidence.
If you were at five places for 9-18 months at a time with several six month gaps interspersed? Not evidence of absence, but that’s absence of evidence to me. (Immediately, I’m assuming several of those gaps might be flameouts.)
I would be wary of anyone job hopping every 9-12 months or even two years. For one reason, they dont stick around long enough to see the long term effect of their work and learn from it. So even if there is no 6 months break, thats still a yellow flag to me.
That’s better, because it suggests four times out of four, the decision to leave and timing was yours rather than “seven times out of nine [four listed], the change was employer-initiated”.
None of these are signals that I rely on as binary go/no-go gates; the main point was “just because you got other employers to pay you for a short while, that’s not standalone evidence that you can deliver business value through working software”.
I don’t believe in jobs-for-life, “putting in your time”, “paying your dues”, “never quit before 2 years”, or other nonsense advice, but if you’ve never had a long stint at a place, at minimum you’ve never seen the pain from your decisions 24 months prior play out and the maximum negative case is far worse.
And, furthermore, if you've never worked anyplace longer than a year or two--and I really want to hire someone longer term--it would be pretty silly for me to assume I'm so special that you'll stick around. My loss perhaps. But that would certainly factor into my thinking.
IME (and this certainly is what's happened in my career, but I've seen it in many), this is usually a lack of mobility options or undercompensation. Few enough quality workers leave places where there are opportunities to grow and (not or) where yearly raises are in the ballpark of the salary delta from moving to a new position. And if you fall into the trap of working for a bunch of startups, you also get the fun "aaaand sometimes startups just explode from underneath you" effect, too.
For most of the folks I've worked with, it's the case that if they take a job and they're not learning something, they're not going to stay long. And if they take a job and the choices are "stay here, even if they enjoy it" and "take a 15% compensation bump that will ripple through the rest of their career", it would be foolish not to go for the latter.
The places that understand that retaining people takes effort are less rare than they used to be, but they don't grow on trees. If you want to hire someone longer term, I hope you're putting the money, and the investment in that worker, on the table.
That's all fair. At the same time, there tends to be a certain amount of gripe-age with any job and some people are more inclined to try to work through it and others are more inclined to start job-hunting. Which is perfectly fine but, if it's a persistent pattern, I probably won't hire you.
To be clear, I'm talking about a persistent pattern. Even those of us with fairly long-term employment (~10 year stints) in general often have one or two short stints for various reasons. E.g. dot-bomb in my case although the job wasn't a great fit anyway.
I have done this a few times. Be honest about it and describe what you did in details on your resume, so you are able to explain what you did or tried to do in an interview setting. Often these project can be good to have a conversation about because you care more about the technology choices and have full ownership of it.
>We tend to downplay things we do or build ourselves, as if the very fact that another person (a boss) tells us to do something makes it immediately more valuable than if we choose to do that something ourselves.
I disagree, if you built something that involved collaborating with others thats inherently more valuable than what you build on your own. The reason is simple -- external assessment is ALWAYS preferred to self assessment of skill.
It's the difference between you saying you're a good programmer and someone else saying you're a good programmer. That small bit of indirection is very important.
If the apps still exist or had users he can just point to that. You don't really need to have collaborated with others. Plenty of valuable software is done by solo developers.
Yes but those "solo devs" are assessed externally usually from open source development etc. They haven't gotten where they are by saying they're really good. It has always been other people valuing and praising their contributions that gives them perceived value.
any example or inspiration to build awesome narrative for that? I think you are right I used to downplay my side projects. when someone ask about it I just said "just another simple projects "
How would you explain all this work if you were hired by a small company to build them? You wouldn't hesitate to claim the years working on these interesting projects as valuable years and part of your career growth and progression.
We tend to downplay things we do or build ourselves, as if the very fact that another person (a boss) tells us to do something makes it immediately more valuable than if we choose to do that something ourselves.
It doesn't. The app you built because you chose to has just as much value as the app you built because someone paying you a monthly check told you to build it.
Wrap your 'side projects' inside a business and claim the credit for all that work.