Are unfinished projects worth anything to an prospective employer?
I have plenty of projects I attempted before getting busy with real life. Should I show those when asked for a Github?
If your answer was an unfinished project, I'd want to know why they were unfinished. Did you give up on them because of external pressures, you had a better idea, or because you often struggle to finish things you've started?
That last one is not alway a pejorative statement, BTW. Some people are great at figuring out the big stuff and then need others to help them execute on the detail (think about architects or producers). Others however, just give up at the first obstacle they meet, and if I get that impression from a candidate I'd want to dig into it a bit as it's possibly a yellow flag.
My advice then: think carefully about what they are likely to ask you about those unfinished projects, and what your answers are likely to be, before you offer them up.
[1] The most interesting answer to this question I've had was "an OpenGL renderer for the X Window System written in Lisp". My follow-up questions were many...
Good employers, but who do not have more qualified candidates than they know what to do with, are already very happy with someone who simply has an interest in his job, as this is already rare enough. They pay attention to personal projects as signs that you actually belong in IT.
Government and, by extension, the consultancies that cater to them, pay attention to diplomas. Bureaucracies recognizing the stamp of approval of another bureaucracy, is one way of looking at it.
One hiring manager let me talk about it more, but in retrospect he was basically nice to me and let me talk about it because I wanted to.
Learning how to do those is a useful skill in its own right, even if they're "toy problems", because what you're learning is a process to break a problem down, and then make a choice based on your knowledge of data structures and algorithms about how to approach it.
Getting good at those puzzles means you flex muscles related to:
- Problem breakdown into logical steps, or what I now call "the useful thing CS50 actually teaches"
- Data Structures
- Algorithms
- Communicating your thought process on all of the above
Those skills are going to help you in any developer job, but might also give you more confidence to take on side projects you wouldn't otherwise. You might look at something out there and think "woah, I want to go figure that out", and now your mental muscles are slightly better trained for it.
What I want when interviewing isn't necessarily a good guide, but typically the technical skills are a baseline and then I want:
- People who can be mentored and aren't know-it-alls. A touch of humility about them. Finds pairing whilst driving scary but will try it.
- People who want to mentor others. Finds pairing whilst not driving scary or frustrating, but will try it.
- Able to work within a team towards a common goal
- Will take ownership and accountability of their own individual tasks
These are things you're more likely find from previous work experience and maybe in side projects, at a push.
I'd say if you're going for FAANG-type companies, definitely prepare for the puzzles and quizzes, but for a more smaller one (let's say sub-100 people) go for the side project approach.
Exceptions do apply obviously: I've had friends who got hired at FAANG because of a side project that grew and got the attention of the engineers at said company.
The most common reason for me to ditch a side project is that I've gained what satisfaction is to be gained from making it. For example, I want to try or learn some new thing and convince myself I can do it. Once I'm far enough to know how it works (even if it's not really doing much yet), I'm satisfied and I can move on to the next interesting thing.
That's why I have basically no side projects to show off..
Just redefine the scope, or the success criteria!
If the project's purpose was to learn or experiment with X, it doesn't matter that it's not a polished product, it still served its purpose and as such can be considered done.
What is finished anyway? Are projects ever "finished"?
Depends on the definition of "unfinished" - it's good to create something that's workable to some state (or at least demo something). If you're using a repo of unrunnable code as an example of your skills, you probably need to have a robust explanation of what needs to be done to get it working.
However, I doubt lots of examples of half-complete projects will reflect too well, and might be more of a hindrance ("doesn't follow through, constantly jumping from thing to thing...") than a benefit. Pick one you're proud of and run with it, even if it's just a "this is the state, this is what I'd do to get it running...".