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).

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.

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.

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.

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.

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.

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.

* (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?

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.

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.

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.

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.

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.

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.

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.

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.

It's dubious to say that one has a lot of specialized knowledge yet he fails at writing a for loop.

What sort of toy problems are you talking about?

(I'm sorry. I thought about using less snark but I can't.)

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!

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.

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.

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:

  var app= new BootStrapMainApp();
  app.run();
  logger.log("App crashed if we get here");

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.

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.