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.
Here's a piece of advice from actual experience (from both sides):
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.
I mostly agree with you, but the side project can be a huge factor in differentiation between candidates, either at the resume or interview stage.
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).
It really, really, really depends on where you're interviewing though.
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.
> Remember Google infamously rejecting Max Howell, the original Homebrew author
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.
I thought the trick with this one was to sum all the entries and subtract the sum of 0 to N-2. The remainder is the duplicate entry.
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.
To be fair, the level of depth one person knows about algorithm was a lot less back then.
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 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.
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.
There is so much evidence online of this being true but people just don't want to believe it.
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.
As someone who hires for software development, I have to only partly agree here. No, your little dogfood calculator is not going to make me hire you, but given equal resumes and presentation, I'd hire the candidate who also shows some self-initiative and actual code vs the candidate who is all on paper, only uses the limited 8 year old stack of their previous employer, or worse openly admits they have no actual experience.
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.
Side-projects can subside for a lack of experience to a degree. A fresh grad's resume with a ton of open source projects will look much better than one without. Or someone who is a developer planning their move into data science will greatly improve their changes by having some experience in machine learning and data analysis even if it's just in a side project.
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.
Absolutely true. Which isn't to say to not do side projects, as they are a fantastic way to become a better programmer! They are just not the most efficient way to get a job.
This reflects my experience 90%. One time I contacted a company in a whose hiring thread here on HN. They asked if I had code on github they could look at. When my response was no, they broke it off.
That's a little extreme, and it's their loss, IMO. Many good programmers have nothing public on GitHub because they only program for their job. I guess they don't want those people.
This definitely struck a nerve when I read it. I'm gradually making my way in GitHub with my own toy projects but truth be told, I prefer to spend time with my wife and work on my body (I have weight to lose and I need loads of cardio) than to always be on my PC/Macbook and code for glory.
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.
This 0%. Side projects are how I've gotten all of my real jobs. Side projects* demonstrate that not only can you write code, but that you can also architect and deploy an application that solves real world problems. There's a lot more to software engineering than can be tested by fizzbuzzing on a whiteboard.
* (I'm assuming your side project is an application)
side projects show you can clone code on github and push it to your own repo. Interviews show you can articulate what you know in a convincing fashion, and that you have done homework on the company as well as your skills of inference and general personal skills to glean into what sort of answer the particular interview is looking for at the time. Something a lot of people really miss out on when bikeshedding over how terrible whiteboard questions are or interview question xyz is
Pass off someone else project as your own? Doubtful. This attitude comes across as having trust issues. To me, it's a sign of a company with a rotten culture to be avoided.
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.
I've had quite the opposite experience as a corp-to-corp freelance contractor but this isn't scientific as its testimonial anyway. My focus has been on cutting edge technology that appears to be the right way of doing things based on large successful companies using the particular technology like Uber, Netflix, Facebook, Google, etc. I've built side projects with forefront technology gaining valuable experience that otherwise I would never get because of the chicken and egg problem. How do you get experience without experience? You don't.
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.
Who is this advice for? UC Berkeley grads? If you don't have personal projects or previous professional experience to talk about the only thing you have to bring to an interview is a university degree. Are you proposing the OP just does nothing? How is OP supposed to land an interview in the first place?
If I see one of your side projects is inline with what we are currently working in my company I would hire you immediately. Obviously we will do some checks on the code quality but nothing extreme. I always hired people based on previous experience and never ever gave them a puzzle to solve.
Totally agree. It's great for fellow engineers to poke around on to make sure you aren't an idiot or aren't copying/pasting projects from the web, but you're right.. for the most part, no one cares about side projects when it comes to trying to snag a new job.
>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.
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.
I second this. If you have a software day job, then you should already be practicing coding every day. I think it's more useful to spend your extra time learning rather than applying. This can be algorithm books, coding courses, interview guides, etc.
It depends what OP means by "getting jobs". To me it means getting work from clients. For getting clients side projects can be extremely useful, and there are no interviews.
I feel like CTCI would get you into Amazon/Microsoft but not Goog/Fb. There's much harder questions in EPI that are part of the regular circuit at these companies.
Agree with this 100%. It's soul sucking and destroying but unfortunately coding interviews today are entirely about competitive programming and not about what you create.
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 has been true in my experience. Interviewed at FB recently, they gave me a take-home project that we would go over together in the on-site interview. I spent a lot of effort on the project instead of typical white-board coding. I did great on the project but did so-so on the white-boarding. No offer.
I very much agree with this, but just as an aside I'd like to mention that I worked on a full stack web application as a side project and I believe that helped me land my current job at a startup.
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.
It seems like that would be a ticket to a QA automation job, not a dev job. People say QA -> dev is a good way to get in, but I've seen very few people actually accomplish it.
I've seen it happen several times (my employer may be unusually prone to hiring jr devs as qa automation).
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.
Yes, but it's also quite hard to get hired as a dev without either qualifications or experience. If you've got the qualifications you can go in directly.
It probably varies from place to place but in the Bay Area at least you pretty much have to get a degree of some sort. There are so many programmers out there that the degree/no-degree has become an easy filter for recruiting types and no-degree + no experience (which means no one to talk to about how you work and what it is like to work with you) makes it doubly difficult.
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)
Silicon Valley used to be famous for the exact opposite: the story was always that formal credentials were less important than demonstrated competence. Have things really changed that much?
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.
I certainly agree that formal credentials are secondary to demonstrated competence, but in the specific case of neither credentials nor experience, people with credentials and no experience have always had the first choice at the 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.
That sounds about right. For me, I fell into a weird scenario where I was still in school right during the peak of the late 90's "dot com bubble" era, when anybody could get a job as a programmer if they could turn a computer on. So I quit school and went to work. And after keeping that first job 4 and a half years, I never had any trouble with a job after that, even without having a bachelor's degree.
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.
> Silicon Valley used to be famous for the exact opposite: the story was always that formal credentials were less important than demonstrated competence. Have things really changed that much?
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.
I moved to this area from the West Coast and found the market much better for these same reasons. Happily living in a forested area while working as a developer.
I've only once in the past 6 years been asked about a degree, and it wasn't even by the people trying to hire me(away from my current employment situation). It was a veto from the CTO who didn't want engineers at the company without CompSci degrees, against all objections. This was by far the odd experience out. People are usually surprised to find out later on that I have no degree.
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.
Start contributing to open source projects on github that solve business problems. Usually for popular projects there are a good number of issues that are available to solve at varying levels of difficulty.
I think you missed the fact that before landing a job, you need to land an interview. I've been on both sides as well for different kinds of companies. Some value side projects a lot at the first screening. If you study a lot it will get you a job %100 guaranteed. But it's nice to be able to work for a company you like.
This 100%. When I'm involved in the interview process I make a point to check out all candidates side projects but over 90% of people don't care.
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.
I'm going to be snarky but I'll say it anyway: you know, stupid stuff like balanced binary trees and shit like that, when nothing's going to fall apart if the user's browser shows a spinning wait animation for 7 seconds (45 seconds at peak times but that happens for just a few hours per week at most) while you iterate through the data sequentially. honestly, who ever needed an algorithm or data structure. /s
(I'm sorry. I thought about using less snark but I can't.)
I have a different perspective. This is for applied math in general, but translates to algorithms with a little stretch of imagination.
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!
You know, besides the other comment about not implementing data structures in a real job¹, why do people insist on memorizing all that trivia about balancing binary trees instead of just using some much simpler self balancing structure like a B-tree²?
1 - I have. But it is overwhelming more likely that you'll just need to know their characteristics than how to implement them.
and if you did absolutely have to implement one from scratch, then you probably wouldn't have to spit out an answer on a white board in front of some judging eyes with very limited time and push that into production.
But rolling a standard datastructure (and what's the "standard library" for a red-black tree anyway - in Python, or in Java? - or C++ for that matter) proves that you can do something "tricky" and hopefully get it right. You can understand and reason about what you're doing. If they don't let you Google while doing a "CS" type problem, of course, then they're insane.
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".
Even then, you'd have to know the characteristics of various data structures to be able to choose the right one.
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.
Anything you could write in less than a half hour.
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");
Say that you dont remember the exact arguments for main and move on. It will be fine.
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.
Mostly web. You always use a logging lib so no console really ever. Strings are used all the time but not substring or splice, 90% of uses for those are anti patterns tbh.
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
It's not that I don't know them, it's that only idiots roll their own instead of using libraries.
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.
it's bad code if you're writing it again. Everything you mentioned is something already handled for the developer through the browser/API's. It's like writing your own multithreading instead of using something provided by the OS. 99% of the time it's stupid
If we have reached the point where basic string manipulation is compared to multithreading in terms of complexity or need for abstraction then we have truly dumbed down the software development profession to a very saddening degree.
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.
You'd probably just be fine spending a few hours per week working on a MOOC that covers the fundamentals of algorithms and data structures like the ones on Coursera by Bob Sedgewick.
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 kind of agree with you for people who already have verifiable experience that sideprojects are not important. For people without anything on their CV however I think it can be a good idea.
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.
From my own experience dealing with all kinds of companies. If you aim for C-level companies (IBM, Banks, Oracle, Walmart, etc.) then you don't need to spend time building side projects. They simply don't care. For B-level companies like Uber, Airbnb, Dropbox and everything in between low and high skilled engineers, it's crucial to have a product of your own out there. They hire mostly young engineers with no professional experience, fresh out of college, so need something to look at. Your app(s) or website(s) will lead you to an interview if you apply. Now, for A-level companies like Google, Apple, FB, etc. it's actually better to do what you do! They prefer a nice github profile rather than an actual app. They're looking for very technical people who teach, mentor, etc.
So I'd say, do what you do, update your github profile and apply at google, etc.
This is how recruiters and companies classify engineers in Silicon Valley (and beyond I believe). I'm not a fan of that classification personally, but it makes it easy to trim a pile of 5000 Resumes. What happens is that Google, FB, etc. will most likely attract 'A' engineers, while other companies will have to deal with B's and C's (sometimes A's as well).
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.
From what I remember so far at Airbnb it used to be tough when they were small. I don't know today if they still attract a lot of rock stars. But still, all I had to do was to write up a mini-web app and connect to their API in order to pull out some data, in about 2 hours. Then after this interview they had an onsite with classic CS and culture fit. They were very tough on culture fit and you had to meet with the 3 founders. I don't know today if it's still the case.
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.
There was an interview I did last fall where I was rejected because I had prepared material that was more useful for a team they weren't hiring for at that time. So it can mean many things, and it's really frustrating when they don't explain.
Like any other companies they have a list of values, company culture etc. I said tough because you could have easily passed all their interviews and failed at the very end, by talking to one of the founders.
> Now, for A-level companies like Google, Apple, FB, etc. it's actually better to do what you do!
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.
Funny comment :) Looks like someone got rejected a few times. The point here is to land an interview first. I can't name one single engineer who wrote "algorithm and data structure" on his/her Resume. Do you? If you do have a nice github profile it'll help you get into the hiring process. AND THEN we can start talking about the actual interview content.
> 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.
I'm a junior web developer (1.5 years of experience) and I don't have a degree in the field, so references are all I have to proof my worthiness. And similarly I have a lot of small (mostly useless too) projects that nobody uses. But I still put them online. I have my own domain for development purposes only and whenever I finish a project to a satisfiable degree I put it on some subdomain amd add it to my list of references. Purely as a quick way for people to check what the code they were looking at actually does.
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.
>>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.
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
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?"
Find those large staffing companies and submit your resume right away. Meanwhile keep learning and practicing. A junior HR person from that staffing company will be with you right there in the actual job interview sitting on your side of the table (but of course their customer is the company, you are the product, and they probably won't be much of a help and take a big cut). Maybe you need to practice that whole procedure a bit. Remember, if you can do FizzBuzz then everyone in the room breathes a sigh of relief since they had 3 people worse than you on this day already :-)
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.
>One of my problems is finding junior jobs. It seems whenever I go searching I see only mid-senior level jobs
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.
Difficult when non-junior jobs require 3+ years of work experience and you have none. A majority of companies will filter out your resume before you even get an interview.
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.
Apply for the mid levels anyway. I never post for a junior position, because we don't have the time and money required to train you up to where you need to be. However, part of this is also about confidence. If you're fresh out of school, but you code as a hobby, and are really into learning about how code works, and have some chops, then depending on the hiring round, you can easily score higher than a mid level dev that has simply worked with Visual Studio his whole career and is inept if an IDE isn't there to hold your hand the whole way through. That's beyond useless to me.
I was always pretty good at landing junior level jobs. To give you a rough idea, I've done 14 interviews in my life and only 2 of them did not offer me the position. I'm at my 3rd job right now (turned down all the others). Also for reference I quit first one before the company went broke (I literally took the first job offered to me at the time, before doing other interviews I was invited to), 2nd one was just a 5-month project and I'm somewhat happy with my current job.
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 and genuinely enjoy learning new technologies over someone who might be better on paper, but just doesn't show the above characteristics.
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.
I think the parent really meant publishable where he said finished. Some kind of minimum viable product. That's what shows you can cut through the BS and wishlist and fun-to-code stuff in favor of the details and grind of getting something out the door and functioning to serve an audience.
`publish` vs `finish` I think is a good clarification of what I think the commenter meant.
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.
Interesting to see many comments here claiming that side projects don't matter when looking for a job. I've been actively applying for a full-time dev position for the past 3 months and the most common feedback I receive is "We need to see side projects, OSS contributions so we know how you code."
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?
I agree. I think it is partly because the quality of prose is more subjective than that of software. Not thought a lot about this point though. It is an interesting topic.
In my personal experience - side projects, blogging and technical articles all help; done all three, seen results from all three (for getting both jobs and consulting / training work), and intend to do more. Ebooks are pretty sure to help too. Obvious caveat is that all have to be at least reasonably good. Blogging can take more, time though, you have to keep doing it for some time before people notice it. Every little bit helps, though, IMO.
It depends where you want to work. Here in NYC my experience, the plural of which is not data:
Enterprise-style jobs at non-tech-focused places (banks, pharma) don't care.
Big Consulting companies really don't care, they just want warm bodies.
Startups and small companies care a lot. I've been on both sides of the table and it's been a big differentiator. When I was screening potential candidates at another company, if you didn't have anything at all we were less likely to bring them in for an interview.
And it wasn't always tech stuff. One person did multiple research projects on bird species and submitted them to science journals. One person made a book of notes passed to tellers during bank heists. At a small company people spend more time with their colleagues than their SOs, and you need to like each other. Side projects are like cover letters, they let me know what you're interested in and that you're an actual human being.
Currently on lunch at a job acquired through a side project. I built it because I saw a problem, got upset enough about it to do something, and made it happen. I think that's the key - it's a combination of being interested in something and design/build/execute ability. Do it because you care, not because you want a job.
I made a video game and I have had two jobs thanks to that code base.
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.
If you don't mind me asking, in what field were the jobs? Does making a game give you much credit out of the game industry?
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!
If you want to be a web programmer then do not make games. Yes I got interest in other fields thanks to my game but the idea is to work in games. Both my jobs have been in the Japanese video game industry.
Side projects can be amazing for building skillsets in areas that aren't a direct part of your current role but will be in a desired next role. 95% of domain knowledge for non-engineering interview purposes is lingo and plausible applications from your past.
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.
For typical full-time jobs, whiteboard cording questions are all that matter. Whether or not you have interesting side projects or experience does not matter all that much.
For other type of work, such as freelancing or consulting, your previous experience may matter slightly more.
Maybe it's just my experiences (iOS development interviews), but whiteboard interviews are actually quite rare. Most of the time it's either questions about iOS, pair programming iOS or discussing your implementation of some coding test.
I wonder if this is just a result of it being a more niche skill set than a general software developer.
I feel like the fact that they are demos rather than products make them rather useless.
Why 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".
It depends on what your definition of "getting jobs" is.
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.
Congratulations, you're in a nice spot but your situation is extremely unusual. Most people do not have jobs just being offered to them out of the blue, so not sure if the advice is really that usable.
The difference between a demo or prototype and an actual SaaS with paying users is significant. The former can land you a technical job if it's well done. The latter will getyou a C-level job for an upstart if it's well executed (read: shows important growth). But you haven't explained what kind of job you're applying for.
Not an acquisition. If you can show you've built a XaaS from scratch, were able to acquire a good number of paying users, and were able to keep them happy, then chances are you're well worth the hire. You're high-end startup material. Do this a few times in a row and you can be certain investors will like you. Taking it up a notch each time.
People who can do this serially are never out of work.
If you are just studying for a test interview, then might as well show them your grades from college or your SAT score. Solving the interview test isn't real life.
I agree with what is generally said bout side projects, nobody really cares. I mean not even a little bit, it kinda of amazes me. But oh well, I do my side projects for two reason, 1. to make money 2. to increase my knowledge in a language.
I wonder if Bill Gates, Zuckerberg and Jack Dorsey would be around if they had to go thru intensive code interviews?
I think it is more interesting for companies if you contribute in open source projects relevant for your future jobs rather to single-person side projects. It means several things: you can join a team working in a project, you know how tools like git work and how make a pull request, you have experience with something you might use in your future job and you can collaborate with others.
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 lot of responses I've seen seem to bag on side-projects. My experience has been a little different, but I see the wisdom in 'Don't pursue side projects if its purely for getting a job'.
Here's my story: I was a Junior in College, and had just learned Java. I was bored with the class, so decided to do something with Java, since I'd just picked it up. I decided to write a small mod for Minecraft, back before like 1.5 or something. It was a simple terrain modification, involving some basic 3D geometry. And after a few weeks, I was able to post it and had some success. I was very pleased with my Floating Islands.
That summer, when I was applying for _Internships_, They asked about my work with Java, and I mentioned the mod I had made, and explained the process as well as the logic I had used to get it done. They later extended an offer to me, and thus I started my first Internship.
As I got to know some of my interviewers, by working with them, I was given the chance to ask what I had done which made them think to offer me the spot. You see, I wasn't the strongest in CompSci, since I was actually studying as an Electrical Engineer. The interviewer mentioned a small handful of things involving problem solving, and the way I could handle changes in requirements ( they enjoyed throwing a wrench in the works during the interview questions). And then he mentioned that my work outside of school had put me over the edge because it wasn't just academic, it was personal.
So in summary, perhaps at the Professional Level side-projects of low-impact have a low rate of return, but at the college level, I believe it is worth investing your time in a side-project, to grow your skills and to show you are interested in it beyond mere academia.
When I interview someone, I always ask about side projects. Some have been huge, and some small (and maybe half haven't done any). However, the passion that the interviewee shows when talking about their project is very revealing. Also, do they really understand the problem, do they have a realistic view of what can be achieved.
Most of my side project are spread on many months (years sometime). I try to ship something valuable and meaningful, but the main idea remains to practice, learn and get my hands dirty.
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).
For me, it's having a successful blog that is on topic to the position. When I started my current job 7 years ago, I started a blog then which was simply a repository of lessons learned, scripts I can reuse in the future, cheat sheets, and videos. I still use it today to look up how I did something years ago, but apparently a lot of other people use the site too. The blog demonstrates the following to any potential people willing to hire me:
* 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.
I don't spend a ton of time mastering algorithms for interviews. Maybe I should. But studying a canned set of specific formulas is about as fun as memorizing a Math textbook. I've found that I become a better programmer by focusing on what's interesting to me. Often times one can guess at a pretty good solution in an interview by simply having tried to make enough things fast enough, modular enough, DRY enough, etc. My basic hypothesis is that most interviewers wanna know you can think how to make things easier to reason about, faster, can ship something, and the you have enough depth to help them in a meaningful way.
For me, my open source work has been a great way to establish credibility for finding jobs, full time or freelancing. In addition, it is a way of giving back to the software I use, and improve my skills by dipping outside my sphere.
The kind that you are/were passionate about and can speak knowingly about the techs you used in the project.
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.
Leading a side project up to release is already a plus : it means that you can build a product by yourself, which is actually quite rare among developers (few even try, many of those who try never get it done).
On top of that, having a side project which actually has users is better : this gives you street cred and also demonstrates you can communicate with stackholders.
If you have a side project in the same field than the business you're trying to get in, obviously, this is almost an instant hire. Developers often think business domain is a detail, business people don't.
Find a company that works with open source projects, and contribute to them on your own time. Bonus points if you actually use them for your own projects so you are able to provide real-world use cases and feedback to them.
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.
Beyond just showing potential employers you have skills and can apply/talk through them (and demos work fine for this purpose; I would't worry), if you want a specific job then it's helpful to have side projects in the target domain. e.g if you want to do data science for a civic minded nonprofit, maybe have a side project doing analytics on one of the census data sets, etc.
Side projects are great to get recruiters' attention and also a great filler if you want to show what you can outside of your previous job. But even if you have an awesome side project you may still get rejected. So in the end if you want a job I will focus on getting really good at solving interview questions. It is broken. You can optimize for it.
I get a few leads from my github account here and there and because I have been working more on closed-source side projects, my activity on github has been low for the past year, generally open-source projects that will be good to show for a job would probably have software that shows you're up on the latest tools and have some testing
I'm going to second the library idea. If you have a library released and get a few users, you'll start getting bug reports, feature requests, etc. You'll be able to show companies that you were able to manage work effectively (prioritization), write good code, write good tests, etc.
Think of a web application. Anything, Trello, Twitter, Harvest, Facebook.
Re-build said web application in your own image. Pretend you are going to release it to the public even if you aren't. Develop everything a public app would need.
As long as you learn a lot, that should be sufficient.
For me, coding simple games was extremely valuable.
First, you can publish them as apps, which is fantastic for resume building. But also its the best way I've found to practice all the algorithms you'll eventually be asked to implement in coding interviews.
The only thing that would peek my interest when interviewing someone would be something that is actually finished and does something useful. Having dealt with a project long term and stuck to it is also a plus.
I would say any project that is non-trivial and is of some use. Does not have to be large. In fact it could even be of no practical use, if it shows some of your programming skills and knowledge (preferably on aspects that also happen to be useful in jobs). But the projects with no practical use will likely have less chance of getting you what you want - though some chance still. As with many things, it depends - on the company / job / etc.
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.