Ask HN: What sort of side-projects are useful for getting jobs?
Most of mine are more of demo's I built for blog posts and teaching rather than SaaS products people are actually using. Some of my projects are rather complex and (at least I believe) do well to show knowledge and understanding, but I feel like the fact that they are demos rather than products make them rather useless.
168 comments
[ 3.8 ms ] story [ 291 ms ] threadWhy would you think that? Anything that shows off your skills has value. Well, it would to me anyway. I mean, if I were evaluating your candidacy for a job, I wouldn't care if your projects were demos or "actual products".
The thing which is valuable is to show you can get things done. That's it. Nothing special, just do what you want to be doing then show it to be who need engineers to do that thing.
I hear some say game development is the hardest field in software, but I'm not sure recruiters in say web development sees much of a bridge between the two!
My references vary from simple image-upload site to a (more complex) link-hosting site that does a lot of magic behind the scenes. And a lot in between.
Even projects from hackathons. [Here's](http://helpmehelp.herokuapp.com/) a perfect example. The code is opensource (terrible though :D). The project is old, irrelevent and unused. But still no reason not to have it hosted somewhere.
There is definitively a barrier of entry in software and it helps if you do a bunch of things that are discussed here in this thread.
On the other hand, if you just need a job as a programmer and have skills like OP seems to have, and apply for junior positions, possibly through a contractor, then you will get a job.
This is for anyone who reads these threads and wonders "am I good enough?" "can I be a programmer?"
Yes.
In the end you'll have an actual job as a real programmer doing Java at a bank and soon you'll realize the job is kinda boring and most of your colleagues are kinda average at their job and you realize why companies would advertise to find mid-senior level people :-)
But you've made it. You started kinda late in life and you wondered if you were smart enough to do it, but of course you put in the work and you got the results.
And now it's up to you if you want to cruise along or use that precious skill, the ability to sit down in the evenings and study and practice, and go on to do something you'll be proud of.
Can you do it? Yes.
Stop applying to junior jobs and thinking of yourself as a junior. "junior" is just code word for "pay me less". Get yourself to where you need to be and just apply for regular roles.
And then there's the practical issue of living without a job while you get education, build experience, etc.
In my opinion, "junior" is code word for entry-level, and it's the easiest search query to find those jobs.
My rate of getting interviews per email sent is much lower (maybe 40-50%).
1.) CV. My CV is cool. It's a password protected website (I also generate a link that logs you in to save time for employers). It's a minimalistic one-page website with lots of cool features. It sets cookie that says Hi, it outputs messages to console, has fun comments in JS files, puts message in header. It also has "print friendly" button that hides unnecessary stuff (links, stuff that doesn't print well). If you click it 100 times you get an XKCD comic (and some prompts at 10/50 click). Just all around fun site that is also a very basic showcase of my work.
Granted most of the people don't even see the console.log messages. But I guarantee you two things a) those who do notice these details will want you more than some random guy b) you want the job more than some random job someone might offer you.
2.) Interviews. I'm extremely honest. I have zero problems saying "I'm sorry I've never heard/used this before" (which happened more often than I'd like to admit). As it turns out, our field is pretty big and people really don't expect you to know everything as far as they can see you've grasped different concepts before without big issues. But you need to show you're happy to learn. Not just willing, but happy. Make them know you're always happy to get more stuff under your belt. Humble yourself and show them you want to be as good as them in this technology.
Hell, I've been accepted for a job as RoR engineer and I've written maybe 10 lines of Ruby in my life. I told them that in the interview. I'm experienced in Laravel though (PHP framework). So I drew parallels and showed them that I'm familiar with the concepts. 2 weeks later they called me that I got the job :) Had to turn it down though.
I will also always try to ask about their stack/technologies they're using. Now I've been on interviews where their decisions were "uninformed" to say the least. For example, the guy interviewing me was going on and on about how the performance really matters. And they were using PHP (relatively new project). In cases like this (if you want the job) it is EXTREMELY important not to come off as arrogant, but still show that you're well informed. So I asked them how they decided for PHP, wouldn't Java/C# be more suitable. And they said that they were thinking about it, but ultimately decided for PHP as their developers had more experience. And, in order to not come off as arrogant, you need to find a way to (at least partially) agree with them. I said something along the lines: "Yeah, I can understand that. Sometimes you've got good developers on your hands and you need to implement some stuff quickly (which will require performance). You don't want to replace you good programmers and you don't have time to learn a whole new language/concept.".
But most most importantly - show enthusiasm. This will get you far. Show that that you enjoy this stuff, tell them about that hackathon, make them laugh with that irrelevant side project of yours that outputs morse code with belly buttons - where you were learning some new technology (or just improving on old ones), tell them about those local meetups you attended.
For junior positions people will always take someone who is easy to work with, will happily accept help (this is often more important than next one) and offer it too when possible a...
It also doesn't seem to do anything. I kinda expected that though when you said hackathon. :)
It's a stupid app that helps you decide on who to vote (US elections) based on issues you type in. Try typing in "death penalty" or "crazy".
It then dynamically finds latest google searches and tweets about candidates. And charities that help the issue.
The app had to "solve a real problem" and use paypal. Not our favourite 2 things for a hackathon. This (useless and non-profitable) is more our style https://www.youtube.com/watch?v=ySU703VXSNY
Small demos, most of time time, keep you on the main, easy, default road while a bigger project let you see a lots of side scenarios which are more representative of what you will hit in job.
However, I would recommend, from my experience to always scope down features since at some point you may fell in the trap of adding feature and not learning the technologies, hence moving away of the primary goal. I am wrapping a 30 months project and will definitely not do any project that would take that long. I aim project between 4 to 12 months for the future (at about 40 hours per month).
Could you expand on this? Are you referring to an acquisition?
People who can do this serially are never out of work.
This sounds trite, but honestly, finishing things is hard. If you can show off a couple of finished side projects, that reflects much better than a half-dozen abandoned halfway through.
Also have a portfolio website to show how and why you made certain choices. I have one (very bare bones) for my mobile apps but it helps the employee to see what you're capable of.
Going further though, I do think I prefer `published` to `publishable`. Fighting through the last (sometimes most difficult steps) to get something in the public means a lot to me.
Additionally, it's also easier to demo something that's available on the public web.
Invest your time studying for interviews than wasting time building side projects if you're doing this purely for getting a job, period.
In my experience, companies don't care about your little side project when hiring--that is, unless your "little side project" had some huge impact or is something they have been aware of--the best you could get is "huh that's cool", and that's it, unless you created something really unique.
This whole process of job interview is broken because it's extremely easy to study for them and give the right answers if you invest a couple of weeks to a few months. But since we're talking about getting a job, I think you should take full advantage of this. If I were you, I would be doing this instead of doing side projects for the sake of getting a job.
Also, "side projects" should be something that you build because you think they're cool, not because you want to get a job. That's another reason why I say study for the interview instead of bothering to do side projects if the purpose is to get a job. It's neither meaningful for the employer nor for yourself.
If you still really want to do a side project, just pick a problem you want to solve, and apply some new technology you want to learn to build it. That's the best side project for yourself and the potential employer.
Which means getting the experience somehow. Unpaid work is one (expensive) way of doing it, but so is getting into a related position and working your way across. QA is potentially a good path for this: hired to do simple things without the degree requirement, move into test automation, move across into development. Then you have it on your CV.
I agree that if you can hold out for a dev job, do that and save a year or two getting to the same place. If you really can't get a dev job and need the income, get a QA Automation job and start migrating early by asking to fix small bugs yourself, or work on the automation tooling.
At a smaller company, working on the build system and QA automation tooling might be more interesting and get more attention than what you would do as a jr software dev.
That said, it doesn't have to be a degree from Stanford or Berkeley, it can be from pretty much any accredited institution. Typical path forward here is community college for a couple of years and doing the general education requirements, then transferring to one of the state schools to finish a degree in a STEM subject (typically math, cs, ee, or physics)
Anyway, at least here on the East Coast, I find that many (most?) companies don't have a strict requirement regarding a degree. At least, not if you have real world experience. Maybe it's more crucial if you're going for your first job.
It still is and same for the other tech hubs.
The tons of complaints are likely from people who have no degree AND no experience and want to break into the industry and the 100k jobs. Of course, they have troubles, for good reasons.
Simple maths; For every experienced HN dev, there are 100 redittors with nothing who wants in.
When you have neither, getting a job in uncertain, there are many variables outside of your control. But getting a degree is completely within your control so it is the better choice of your time. Given the monetary constraint ($3,600 / year for community college (x2) and $7,500/year (x2) for state college) From my experience the job you will get in year 4 (and during the summers of year 3 and 4) will pay you more and offer better advancement than if you had started working in year 1 and not pursued a credential.
If you already have experience, then you also already have a network of people who have worked with you and know what you can do, and getting a job is a matter of finding the person in your network who will vouch for you.
Strangely though, I've accumulated 3 associate degrees (general education, computer programming, and high performance computing) over the years as well. Somehow, with all that, nobody ever mentions that I never finished my bachelors degree.
Not sure if it's possible to replicate that career path these days or not. I may just be the product of a specific era of history.
So, I'll have to disagree about the no degree + experience. No degree + no experience is a very tough spot though. Should still be possible though. As others have stated will probably need an entry level-ish position first and then impress the right people and move across. A bootcamp might also be possible.. Companies do hire right out of there, so with the right aptitude and performance in the bootcamp I can see that gaining a foot in the door somewhere.
In getting my last job I thought I would have a slam dunk because I have a bunch of cool stuff I work on but nobody cared at all.
I failed multiple on site interviews until I gave in and read a couple CSCI 101 books cover to cover. I had too much specialized knowledge and not enough fizzbuzz. On my second round of interviews I got offers from all three companies because I could regurgitate their stupid toy problems in minutes.
What sort of toy problems are you talking about?
(I'm sorry. I thought about using less snark but I can't.)
When it comes time to do something novel, that understanding will be very useful.
People pooh-pooh Google's hiring interviews, but when was the last time Gmail's search results on your email were as bad as Bing's (I use this example because it's not their general index, I'm asking about your mail.)
There are a lot of good reasons to bone up on CS 101 (and 201, 301, 401, and 501).... I disagree that it's just "studying for the test".
On top of that, in almost all code beyond CRUD, you'd have to write some custom algorithms - there, the knowledge from data structures and algorithms is really helpful.
1 - I have. But it is overwhelming more likely that you'll just need to know their characteristics than how to implement them.
2 - And get better caching behavior for free.
In your daily life, you use tools to do your job. Over time, your tool set has sufficient coverage that it can handle most jobs. However, because of this "good enough" coverage, you may not realize the existence of other tools that may be far superior. I believe "applied math" is one such tool. (Translate to "algorithms".) Its applications are everywhere, including at least 50% of your daily life in my experience. However, you fail to see them because you may not have that tool in your tool belt! This is no different than wearing x-ray glasses - you get to see almost every problem in a different light. Google and others who realize it want to make use of these versatile glasses.
I do not mean to be obtuse but a different perspective may be helpful!
Lets take fizzbuzz for example. These types of problems almost always require manipulating strings and dumping them to the console in the simplest scenario possible. Usually the main method or equivalent in a console program.
It would be easy as hell except they don't let you use google or an IDE, so you need to memorize the syntax for the main method and string manipulation.
1) In real life you almost never write directly to the console. 2) In real life, you never manipulate strings using sub-string or regex really... In fact the only time I do this a lot is for terrible reasons in bad code. 2) Main method? If your real life app even has one it was written by the first guy 10 years ago and is 3 lines long, just some function that looks like this:
And don't assimilate fizzbuzz with half hour problems. There are for sure some difficult half hour interviews questions; they are not comparable to trivial exercises like printing the numbers from 1 to 10.
P.S. If you never use console, strings or regex. I really wonder what kind of applications you're writing.
Regex really never. Unless you're munging data in Python it's usually a bad idea to use regex. Clean strings? Use a library. Parsing? Use a parser. Raw regex implies filtering stuff or banning certain characters in strings which breaks all kinds of multi language compatibility
Well, I am obviously the guy who write the tools and the libraries, so you don't have to know these things yourself but I do :D
Every time I see a regex cleaning strings I instantly know the app was written by an ametuer and probably horrible and full of security issues. Oh it globally replaces this bad token but not recursively? Great
I use regex for searching logs all the time but never in production apps. I can write some pretty mean regex but I can't remember the function call for string replace off the top of my head. For me regex is 99% in a text editor.
Really when do you split up strings without using a tokenizer or parser of some sort? Manual string manipulation is usually dumb and error prone. The only time I find myself doing it is when stuffing crap into bobs "extras" db field which is actually a bunch of 80 char strings delimited by the pipe character.
How do you parse known data formats from free text strings? (regular expressions, string manipulation) How do you parse a cookie? (string manipulation) How do your apps http requests end up in their respective handlers? (main method socket listener)
If your answer to each of these questions is that you use a library that's cool and all, but just because you didn't have to write it yourself doesn't mean it doesn't exist in "real life". Someone wrote that code for you, and you can call it "bad code" if you want - just know your app is built on it.
I simply can't fathom that you believe such basic constructs of software development would be a bad code smell. I really don't know how you get around using them and manage to do anything remotely interesting and novel.
Other fundamental courses might include ones on Computer Networking or Databases like those offered by Stanford Lagunita.
Just keep a list of MOOCs that start regularly (like once a quarter or twice a year) or the self-paced ones and just rotate through them as review.
It's dubious to say that one has a lot of specialized knowledge yet he fails at writing a for loop.
My rules for the ideal portfolio ready side project:
1. It is "complete". Not just started but something that actually works. This means that a side project needs to be something which you can actually finish. No matter how great your code looks, it will be outweighed by code that works.
2. The problem it can solve can be described in 10 seconds.
3. The interviewer will not be able to sketch it out in their mind in under a minute. While the problem solved may actually be quite simple to implement, it is best if it's just outside the interviewer's knowledge.
Actually publishing a usable library, even something trivial, provides great separation at the resume level and gives you something specific to discuss in the interview.
The easiest examples I could think of would be a library that does some math. Odds are the interviewer doesn't know how to do trig functions on a sphere, but it is something easy to look up and implement. You can describe it quickly. No amount of time will help them figure it out. Some people's eyes will just glaze over and they'll assume you're really smart (don't go into too much detail on these guys, show them your communication skills instead).
So you're best off knowing how to derive an O(N) dynamic programming solution to everything on Codility/HackerRank/LeetCode/ACM-ICPC coding challenges.
This is highly dependent on the company you're applying to. The world is bigger than GooBookHooSoft. I've worked for a lot of companies that don't do any of that "grill you on Algorithms 101" stuff, and are far more interested in a demonstrated ability to build something.
OTOH, it certainly can't hurt to study the shit out of Algorithms 101, but projects will carry more weight at certain companies. I know if I were in a position to hire right now, I'd care more about projects than CS trivia.
So, to OP, definitely don't over-do it on the side projects, but do be sure your potential employees know you enjoy what you do and are self-taught and self-motivated.
There are people who realize this and are respecting it (and are adapting their interview per candidate) but increasingly, companies simply don't want you if you didn't invest months/years in showing off.
Remember Google infamously rejecting Max Howell, the original Homebrew author? I know there has to be more to the story, but he's become the poster child for talented programmers getting rejected because they can't play the interview game. My point is, though, that his side project absolutely had a huge impact and it still wasn't enough.
90% of my interviews have been a take-home project followed by a chat going through my history and experience; in fact, my small side projects and hackathon projects tend to impress interviewers more than my on-the-spot abilities or my work history. Interestingly, I worked for a Fortune 500 bank and, while it was the least-challenging job I've had, the interview process was by far the hardest and had a few questions straight out of CCTI.
Research a few companies. Their Glassdoor pages usually indicate what kind of interview process they have. Then prepare accordingly.
If Donald Knuth interviewed with Google, he would fail too because he would need 24 hours to solve a hard level leetcode question[1]. Unfortunately, Google loves throwing those kind of questions at interviewees and expect them to come up with solutions within 1 hour interview, lol.
[1] - http://keithschwarz.com/interesting/code/?dir=find-duplicate
It's just a trick though; I don't think skill in coming up with these is particularly well-correlated with being a good programmer, and for that reason Google claims not to do teasers like this any more.
All google does is teasers like this.
Today everyone is reading CTCI book and prepping. So if you aren't at that level, you will be behind. It's just like that guy who refuses to use steroids while trying to be competitive in MLB/NFL.
I have been on both sides as well, many times and to be honest, if someone was a graduate and they didn't have some kind of side project, we just scrapped them.
* (I'm assuming your side project is an application)
But if someone was able to clone and deploy someone else's project and pass it off as their own, it at least demonstrates that they know git, the command line and some ops.
Interviews beget interview skills. How does this translate into job performance?
However, I agree that unless a side-project has very high impact, it doesn't help much to have on your resume for people who have relevant work experience from a previous job.
Devs love the idea of "being found" because they had the perfect project on GitHub or a great blog. Reality is these are time consuming, low % approaches to improving one's job prospects.
It's so much more time efficient to network and study for interviews.
I tend to be pretty decent on interviews anyway so its difficult to know if this approach is the right one but for sure it keeps you sharp.
It is more common than not that the technical interviewer compliments me on this approach. Recruiters and non-technicals tend to not care about the specific project but do like that I am comfortable with the technology which gets me through the next round at least.
However I'd also note that I applied to a LOT of companies, and while my side project helped me land my current job, 90%+ of the companies didn't care about it.
I learned a lot from my project but job hunting is a numbers game, and it's far more worthwhile to study than it is to build a side project IMO.
Something else to consider: Depending on the corporate policy on open source, employees may be forbidden to look at external source code without prior approval by the legal department. This is more likely at large companies who are afraid of lawsuits accusing them of copying code or ideas (and, yes, it does happen). So, your interviewers may not even be permitted to look at your portfolio anyway.
In rare cases, your side project is addressing one of the businesses needs directly, giving you domain knowledge. More likely is that it does not. At this point, the value-add of that project is that is improves your understanding of the techs you used. Can you talk about the pros and cons of using Go/React/Angular 2/techBuzzwordDuJour? That speaks to your passion and creativity, and stands to improves the knowledgeable of the team that hires you.
tl;dr: Do something fun that you enjoy. The rest takes care of itself.
For other type of work, such as freelancing or consulting, your previous experience may matter slightly more.
I wonder if this is just a result of it being a more niche skill set than a general software developer.
So I'd say, do what you do, update your github profile and apply at google, etc.
So to answer your question, an A engineer is someone who can potentially crack a Google interview, or someone who worked for one of the big-5 in the past (FB, amazon, google, apple, microsoft). I let you guess for B and C... same concept.
At FB and Google it's all about mathematics, advanced CS, etc. So... They're looking for generalists and it's harder to find because in real life you don't really use this stuff anymore.
Bull-fucking-shit. Google and Facebook are the poster children for algorithm based interviews. They don't give 2 shits about what you have done because it wasn't done at Google, so it counts for nothing. Now go solve another pointless dynamic programming problem you waste of skin.
It's all about separating the good from the bad.
No, it's about google being able to continue jerking off to the idea that they only hire the best.
I've seen people smarter than me get rejected and people dumber than me get hired. Google's process is shit, and that would just be par for hte course but the company is god damn arrogant about it.
Hell, you decided to be a condescending fucking asshole just talking about it on HN.
Sheesh! Glad to see those google filters are still working pretty well...
Just released my side project: http://libretaxi.org - it is open source, useful for some users, code is kinda clean, plenty of tests.
Just show how you can take an idea and implement it. So your employer will know what to expect.
If it has to be a single-person project, then it only has some value if you released it and people is using it.
* A sample of my writing skills * A sample of my design skills * A sample of my engineering skills (shown in scripts and codes) * A sample of my documentation skills * Additional proof that I am passionate/skilled/interested about this type of work.
Everyone is commenting that studying for the CTCI bar exam is more important than personal projects. Is something like HackerRank more or less important than personal projects?
Thank you.
I haven't looked for a job for years but I get freelance / consulting gig opportunities presented to me on a pretty regular basis.
Most of those opportunities come from a combination of side projects, open source contributions, having a blog and teaching online courses.
Now, I'm not sure if that's what you meant but in the above life style you don't need a resume or know how to take interviews. You don't even need a formal education.
People just come to you, already knowing beforehand that they want to work with you. You already have the job before you even know what it's about.
You could start open sourcing some of your work right now and build your self up on GitHub. Maybe start a blog too.
Link to your linkedin/resume please?
I have about 4+ years in DevOps and in support. I consider myself a programming generalist, which I thought would be enough to at least get a technical interview. Instead of working on a project that will most likely be left incomplete due to fatigue or loss of interest, I rather spend that time learning ways to improve my skills to make myself the best programmer I possibly can be.
I've been considering starting my own blog and write articles about lessons learned or an e-book to express my credibility. Does anyone have any opinions with developers who write blogs/publications in lieu of side projects or OSS contributions?
Then you can watch the GitHub stats and see that noone opened your link :D
If you're DevOps you should probably have an updated LinkedIn. Its getting crazy over there.
This especially helps if the company is a startup, in which case they most likely are understaffed to keep everything up to date and bug-free. They will also be more likely to respond to your feedback in an actionable way besides a "thank you" from a maintainer.
Anecdote warning: Some years ago (pre big data) I wanted to move into analytics from more general strategy consulting because I found it more intellectually challenging, but didn't have much on my resume to support it. I started building database-backed sportsbetting algorithms (first horses, then hockey) and trying to find profitable strategies. I never did find one, but a year later when I found myself a part of the inevitable downsizing that happens in the industry and applied for analytics jobs, the statistics, probability and analytics strategies I learned betting on sports definitely got me the job.