I’m not mad at you, but as the dude on the other side of the desk, I have to decide whether you can cut it and I’m fine saying no. I could make you do some whiteboard problems, but I think whiteboard problems are pretty far removed from your day to day development and I am uncomfortable relying on them as a proxy for your ability to ship code.
I don’t really disagree with your philosophy of working while you’re working and NOT working in your downtime. I think the same way.
But I have a whole pile of stuff I can show you that I’ve worked on. I don’t ask anybody to take my word for it. In computing, you just can’t. The signal to noise ratio is too bad, there are too many guys out there making unmaintainable junk, if they actually ship anything at all. There are shops out there that can afford to hire a bunch of maybes and just weed out the duds when they wash out, but I don’t have that luxury. Nor am I going to go on some weeks long hiring safari where I hire you for a week or two and see if you can cut it. No time man. Sorry, don’t have it. I’m going to give you the job or I’m not going to give you the job.
On the flip side? As somebody who has plenty of open source projects--the set of employers who actually looks at them is within epsilon of zero. I have not once, not once gotten a meaningful question from anything I have posted on Github in any interview or client meeting even after suggesting up-front that it's worth taking a look. And I used to interview on a monthly basis just to keep in practice! No--instead you get dance-like-a-monkey "coding tests" (unpaid, of course) that are nonportable from employer to employer.
Employers don't care. Employers say they care, but it's signaling. If I didn't write code on my own because I like it, it would be a serious negative to do so on the off chance that you run into the black-swan employer who takes the question seriously.
Hiring manager here who reads Github profiles -- it just occurred to me that I've almost never actually mentioned it to the interviewee. It's flavoured the conversation for sure (except for the bootcamp grads who all have identical Githubs) but I tend to talk more about your process than the actual code.
When I've had time to prepare, I've taken the time to review candidates' GitHub repositories, and it has surely helped to really understand what "open source experience" means vs "coding camp attendee". It's fun to ask about a particular class or set of files and ask the candidate to teach me something about the project. It shows we care, and also helps me tease apart a candidate's communication abilities.
As a software engineer who does technical interviews, I also regularly review GitHub contributions if mentioned on the resume. It's not a deal killer if someone doesn't have these things...but if you're up against another candidate who does (and their work is good)...then the other candidate is likely getting the job.
When I hired people, I looked around on the internet for people with public work (whether side projects, university homework, open source development, essays, whatever), I scrutinized all of it, and then I talked to the people about those things.
Because I myself feel that this is such a good and reasonable way of hiring people, I wouldn't want to work for an employer that wouldn't let me do open source work.
I mean, it's also because I consider open source to be the public sphere, and I really do believe in software freedom. Maybe my professional metaphor would be the coder as a writer. Of course I want to see your published work.
This is what I think most people fail to understand. It's not a _requirement_. The vast majority of people DON'T have side projects. Companies can't afford to simply auto-reject everyone who doesn't have side projects. The point is that if you do have any, it can help make you stand out dramatically.
From my experience (of talking to bootcamp applicants), bootcamps are not so much about learning how to code, but rather how to get an entry-level job. At first glance of somebody's Github, it will look like they have lots of open-source projects and collaborate with other people. But this is just part of the bootcamp "script".
Bingo! Bootcamps are basically multiple month training sessions for interviews. Princeton Review for dev jobs.
Regardless, I actually think this paradigm works for entry level jobs at most companies. You don't have to know anything for your first year in most cases. You just have to be able to show up and follow instructions.
I do understand what you're saying though but I don't think people are going to just search Github for your name on the off-chance that you're on there, I suspect that what most people do is look at the things that you've specifically mentioned in your CV.
Searching Github for your name can backfire. My name is not very common, but there are 2 people on Github that have it and I'm not one of them. I do have a huge body of stuff on StackOverflow though.
The wrong empoyers don't care. The right ones do. My github portfolio is a means for me to determine if a potential employer is suitable for me, not the other way around. It's not a test for me to pass, it's a test for a potential employer to pass.
If a recruiter brings up things listed on my LinkedIn page, I know they're not suitable for me. If they bring up things on my github, I'm reasonably positive I want to talk to them. One company's CEO asked me a whole bunch of questions about one of my projects. Not as an interview, but as a peer. He had a genuine interest in my side projects. If he'd asked me to come work for him, I would have said yes in an instance.
I don't expect my surgeon to do surgery in his spare time. Nor my plumber, dentist, gardener, or any other professional. I look at their past work history and reviews from customers and/or coworkers.
I will never understand the belief that side projects are in any way necessary. I'd much rather have a well rounded individual who isn't moonlighting on other things but rather can bring his clear focused mind to the office.
> I don't expect my surgeon to do surgery in his spare time.
I really like it when my specialist has a prominent public profile.
A recent case: tenure at a major university, had written or was quoted in many good journals and papers, and had a number of impressive accreditations (for example he was also head of his specialty's medical association for the country). This showed dedication and interest as well as some measure of intelligence.
I was accordingly confident he was on top of the latest developments in his field and would be able to deal with complications better than your run of the mill specialist. The care was great throughout.
Similarly, our lawyer has been quoted twice by the Supreme Court in Singapore, has written many articles in the Straits Times, and does great (and visible) pro bono work, all of which I could find off a quick Google for his name. Whilst I hired him based on a recommendation, it was comforting to see this public confirmation of his ability and interest in the field.
While these points may well be examples of this person's ability, certain credentials don't have to mean as much. As an example, the head of an association is not necessarily chosen for their merit.
Not so sure about this. It would be OK for my surgeon to just be a badass surgeon and not a politician. Public confirmation doesn't add much because the skill of navigating that is (mostly) unrelated to the skill of achieving a great surgery outcome.
I think the key to your answer is in the parent's text: "This showed dedication and interest as well as some measure of intelligence."
My reasoning is that if someone is very good in his line of work, some of that work starts to spill out to the public, either by research, teaching, articles, blog posts, etc.. If a person is not a pure introvert, working all by himself, and is quite good, invariably someone will notice it..
Me either. It's become cool to work 60 hours a week because you like your job, and then go home and do more programming because you like programming.
Why it's cool... I don't know. I agree it helped me in the early days of my career, but at this point, as a senior developer I can pick up new technology much faster than my early days. I can come up with a working solutions much faster.
I like my job, and I like programming... But there are other things I like too.
So, why do I need to work long hours and program outside of my job? I have good enough communication skills to convey my experience. If I'm not hired for not having an active github account, or a side project, there are five other companies that would.
I like my job, and I like programming... But there are other things I like too. Such as playing the guitar and saxophone, writing side coding projects, mountain climbing and traveling. Do you realize that writing side coding projects is just one of the many things we like to do?
Just because we do side projects does not mean that we do not have a life outside of coding.
One difference is that many "programmers" actually don't do any programming at work. Their hands on experience is a 5 week java course in uni 10 years ago and after thay they have been stuck in meetings or writing brain numbing CRUD in a proprietary domain specific scripting language at $bigco ever since. The only way for many to get actual hands on is to do side projects.
Hair dressers don't have this problem, they are actually cutting hair 8 hours a day.
Carpenters have a more hands on education compared to compsci which is more maths than version control.
Doctors require 2 years of practice supervised by other doctors before they are certified.
> I'd much rather have a well rounded individual who isn't moonlighting on other things but rather can bring his clear focused mind to the office.
I don't understand how you equate doing side code projects to not bringing clear focused mind to the office.
Would you also much rather bring a well rounded individual who does not take art classes after work? Do you think taking arts classes after work would affect one's ability to focus in the office?
Then why do you make similar assumptions about doing side code projects? For many of us, doing side code project is like taking art classes. It is art for us and it helps us learn new things about the art of software development that is not always easy to learn in the constraints of real world software business. Most importantly, it is a relaxing and enjoyable experience. It refreshes our soul and combined with a good night's sleep, it helps us to better focus next day at work, not the other way around.
Are you saying that you would much rather not hire people like us who care about the art of software development because from your high horse, we don't look like "well rounded" individuals? If you hold this kind of irrational conservative beliefs, I'd much rather not work for you.
Thanks for pointing this out. Working on my humble side projects is the hiking/cooking/traveling of my life. I spend my free time programming for the same reason the author doesn't spend his free time programming: because life is too short not to do what you love when you can. Making progress on these projects helps me to be more present in other aspects of my life, like my job and my marriage.
If the person enjoys their side projects, go for it. I'm not saying they can't. But on the hiring side I'm not going to require that all employees have side projects that match their day job.
> I'd much rather have a well rounded individual who isn't moonlighting on other things but rather can bring his clear focused mind to the office.
I don't think it's wrong to work on side project. Some people like or want to. Who am I to judge what they do on their free time? It might happen to overlap with their job, or it might not.
But I agree, I don't require my surgeon to do surgery in his spare time. I've worked with plenty of great engineers who wanted to leave work at work, and after 40 hours of engineering, enough was enough and spent their free time doing something that wasn't engineering. I've also worked with people who did side projects, and were equally amazing.
A lot of coders consider coding not only as a job, but also as hobby. Usually they experiment with new stuffs this way, and thus their open source projects at Sourceforge/Github, etc etc.
I don't expect a brain surgeon to mess with somebody's head because he's bored at weekend, though :p
For the first many years, I was this way (considering coding as a job and a hobby). I guess it still is in many ways, but as I've gotten older I've started to feel the burnout more. If I spend my weekend doing anything on my computer, I feel it on Monday and just want to do something different.
You're right, I was probably swinging too hard on the other direction with my comments. The core of my argument stands: I refuse to require side projects as a condition for hiring someone.
Surgeons, plumbers, dentists, and gardeners are licensed, bonded, and insured, entrusting the certification process to a third party. Surgeons and dentists also have professional development baked into their work schedules, which software engineers should have -- say, hire someone for 35 hours per week so they can spend 5 hours per week on professional development.
This! And similarly, software developers should keep abreast of latest technical advances.
What makes software engineering different from surgery is that when a surgeon learns something new, he does not have a live patient at his home to practice the new thing he has learnt, but as software engineers, most of the times we can immediately fire up an editor and write a PoC or a toy project to practice the new thing we have learnt.
Its strange that such natural and obvious curiosity and desire to try something out outside of work deserves the kind of criticism that it is receiving in the original article and some of the comments here.
> Its strange that such natural and obvious curiosity and desire to try something out outside of work deserves the kind of criticism that it is receiving in the original article and some of the comments here.
The critic points out that it is no longer curiosity which drives you when people expect you to do it.
Yes, it is normal to tinker with new stuff to get acquainted with it. It is, however, not the same thing as publishing results of that tinkering on e.g. github, or blogging about it as if you want to break some posts-per-month record.
I do not get this obsession with putting everything out there. I have a huge local directory with my old test programs, PoCs, started but abandoned ideas, etc. I regularly try new stuff, new libraries, programming languages, what have you. But my github account is empty.
> I do not get this obsession with putting everything out there.
It's not obsession. It's just a matter of convenience. git add; git commit; git push; and all my experimental code is safe on someone else's server that is managed much better than I can manage my set of USB drives and hard disks.
I expect a surgeon to stay up to date on the latest in medical technology. And I don't know too many surgeons who clock in at 9am and clock out at 5pm. Many surgeons pull 60-80 hour weeks regularly.
> I'd much rather have a well rounded individual who isn't moonlighting on other things but rather can bring his clear focused mind to the office.
What I do after the office hours is really none of your business. I should be able to do whatever I please (write code, play guitar, etc.) after office hours without you raising concerns about it.
If you believe I do not bring my clear focused mind to the office, then that is a separate issue to be discussed separately without bringing in what I do after office hours into the discussion. It is my prerogative, not yours, to decide if I need to give up what I am doing after office hours in order to focus better at office.
People who have only recently completed their 10,000 hours don’t understand that there are diminishing returns, and that learning something else entirely may help you more than doubling down on your narrow skill set.
Some of the things you can learn outside of this field are what overtraining is (actually not that different from the AI concept), perspective on the learning and teaching process, the importance of preparation and good tools, patience with new ideas, and the dangers of trying to rush through the learning process.
We aren’t talking about people moonlighting as developers. We’re talking about people in the industry working on software every waking hour.
Roughly 220 work days a year, 5 hours a day at work if you are full time, 6 if you dabble a bit outside of office hours, that’s around 5 years out of school, which isn’t too far off from my experiences prior to Malcolm Gladwell.
When I'm building some CRUD interface for my job, there's nothing I'm practicing with that. When I spend my entire day doing that, I've gained 0 relevant hours for Malcom's 10K.
No, side projects are not necessary. They're just a signal that you're really into this stuff. Like all signals, it can't be evaluated in isolation. It's no different than preferring candidates who come from a top University.
Some jobs are easier to do on the side than others. I'll bet the gardener has some side projects too.
The former one, maybe not. I'm sure lots of practices hire surgeons by looking at their record and not observing them actually doing a surgery. After all, it's the results that matter in the end.
The latter one, sure. Makes me wonder if we should call interviews as auditions.
What about an artist or a musician? Would you expect a musician to practice and get better in their free time or only play their instrument during paid gigs?
Fine artists usually produce works on speculation. Craft persons usually produce on a cottage-industrial basis, essentially commodity piecework. There are a lot of ways to get paid, beyond the two you highlight, so the parallels are not as clear as you appear to be assuming.
You list things on linked in just so you can blame potential employers for looking at it? I dont even have linked in account and still find it ridiculous to hold it against them if they dare to look there.
“How much time is the interviewer willing to invest” is a super legit question to be asking. It tells you a lot about how many shits they give about you in particular and is a good proxy for the quality of the team in general.
> My github portfolio is a means for me to determine if a potential employer is suitable for me, not the other way around. It's not a test for me to pass, it's a test for a potential employer to pass.
I disagree with you, and grandparent, and the article :-)
I've hired plenty of great engineers who didn't have side projects on github. I have never specifically been looking for people that don't have a life outside the field, and unlike GP I have found that there are other ways to evaluate people that can identify great engineers with very few mistakes.
But that doesn't mean I wouldn't see your high quality or impressive open source code as a huge plus. Quantity doesn't matter -- if anything if you're super prolific I might wonder if you have much energy for your day job -- but I'm not going to pass up a chance to see what kind of work you do.
And because quantity doesn't matter, I think that writing a little bit of code "for your resume" (every once in a while, to reflect your continuing development as an engineer) is a pretty reasonable investment even if you don't happen to want to spend your whole life outside work programming. It's not required, but it might get you a really great position some day, even if like the OP you're up front about having a life outside of software engineering.
This. Not once has a potential employer ever said to me: "Based on your Github, you can obviously fizzbuzz with the best of them, and know a for-loop from an if-statement. Let's skip the phone screen/homework assignment and get you onsite directly."
Speaking of FizzBuzz, I had never heard of the fizzbuzz test until recently in interview. In 15 years of frontend work I've never needed to find if a number is divisible by another number, so I forgot about the modulus operator '%', and stumbled on that question. Apparently not knowing about that made me unqualified for the job, above all other evidence of my frontend work and achievements. It takes less than 10 seconds to find the solution, but in interviews we are expected to have the entire JS reference guide in memory.
There are plenty of ways to write fizzbuzz without the modulus operator, although it is the most obvious way. But you can also combine infinite streams, or keep track of the index of the next "fizz" and "buzz" with simple addition...
Perhaps there are plenty of ways, but finding the remainder of the division is what's needed and in my case the test was pen and paper, with just a small space for the answer and no way to test my code.
It's all good, it wasn't the role for me, I'm more creative dev than programmer and I didn't get a good impression of the company anyway. I've moved on.
Or at least the JS reference. Or design the questions to fit the role. If it's a frontend role, then ask frontend questions, not some bullshit high school arithmetic.
I wrote most of the 'fizzbuzz' function but couldn't remember the "%" operator. Tests are annoying because it's not how developers work, at least I don't work that way, without any way to verify syntax or look anything up.
I recall an interview from years ago where I was asked to show the code behind my websites and step through it explaining what it did and why I did it. This is better than a test, because you're explaining how the code works and also showing off your work.
Time for anecdotes. Twice in my career, an employer has looked at my GitHub and asked specific questions about certain projects, what motivated me to write the project, why did I not use a popular big data technology to write the project, etc.
There was a time, last year, when I'd regularly receive email-SPAM from recruiters talking about one of my C++ projects. (Console based mail-client with Lua scripting.)
Later I moved that project to a github-organization, as it didn't need to be tied solely to me, and I wanted to allow others to commit, etc.
I'm not sure if the SPAM-mails went away because recruiters stopped scanning github for profiles, or because there was no obvious link between that particular project and my personal email.
It doesn't happen too often - but I've had that happen several times, actually. Just like people might pretty much hire you (or invite you to substantially greenlighted interview process - sans whiteboarding or over-the-phone grilling) solely on the basis of a talk you gave, or an impromptu discussion about some topic you're insanely interested in, after meeting you at some event.
Granted, this has been for gigs (or temp-to-perm) situations, not official, up-front fulltime roles. And some of these people ended up being flakey or sketchy (as spontaneous / whimsical people sometimes are). But nonetheless, hired (or substantially fast-tracked into their process, bypassing most of the usual interview crap) - pretty much on the basis of single demo or code sample (or in one case, literally on the basis of a single stats plot).
Because by this point, pretty much everyone knows how silly those live fizzbuzz sesions are anyway - including those administering them.
> As somebody who has plenty of open source projects--the set of employers who actually looks at them is within epsilon of zero. I have not once, not once gotten a meaningful question from anything I have posted on Github
I guess that isn't the idea here. I think the idea is for them to grab a dev from the next cubicle/floor, point them to the repo, ask "can he code?", and the dev says "sure looks like code to me, yeah."
"Showing up" is 90% of every move. Sure, the guy who copy-pasted something together could get the job that more talented dude who was too timid to share their stuff would be much more suitable for, but such are the trade-offs here.
In my experience, that doesn't happen. And I go on a lot of interviews; it's an activity that helps with a set of skills that I always need to keep sharp. And, along those lines, I get a lot of offers! But it has never-not-once been related to my Github profile.
In my experience, it is employers signaling how cool they are before they ask you to do their multi-hour coding test for no money.
> before they ask you to do their multi-hour coding test for no money
Where do all of you keep finding those companies? Is that an SV thing, or am I just not applying to "prestigious" enough companies? I've been on my fair share of interviews and haven't had that happen once, along with no whiteboard interviews. I can echo your experience about Github projects playing a small role apart from signaling though. Once, an interviewer mentioned one of the Github projects I worked on and we exchanged 2-3 sentences about it, but I don't think it had a significant impact on the result of the interview.
They're pretty rampant in Canada. You usually get one of these types:
- Long home coding challenge (for no pay of course)
- Hours of whiteboard coding talk. If you're lucky it relates to the job at hand, most of the time it doesn't
- Doing coding tests online, either through their propitiatory app or through sites like HackerRank.
- A conversation type interview, where you talk about the job (have only had this one in my recent attempt. Didn't get past that phase)
Of the roughly 30 interviews that I've done in the last ten weeks, only one place ever asked about my github profile (which I don't have yet, currently revamping it since most of the code was years old and pretty meh). Almost every one of them had questions about my linkedin profile though.
Can confirm, not a SV thing, plenty of it in Europe.
Nothing to do with prestige, it's a simple "will this monkey jump through hoops" test to see if you'll work in shitty conditions for shitty pay.
My go to response is asking them to look at my git instead, which ends the process in about half the cases. The other half they look at it for <5 minutes and point out the error that isn't an error (yes I know what an SQL injection is, and I've taken steps to make sure it won't be an issue).
If I came onto your project I'd be trying to fix that SQL injection too. Why don't you add a comment explaining why you know it's safe and why you aren't using the standard way of escaping variables in SQL?
I'm not sure where I'd put the comment, since in the part where router paths are set up, it's self-documenting/obvious that it isn't an issue, and if the person skips that and looks at individual functions only, then I'd have to put it in too many places.
I guess I'd put it in the paths, as it's something that needs to be kept in mind while updating the paths. Also in the coding conventions, but it's understandable not to have one on a small project.
Another option is to create a function like _escape_numeric_string that returns its input after asserting the string is numeric and has a comment explaining, and use it everywhere. Although yes, that does mean changing all your individual functions.
Generally if a code reviewer suggests a change it is worth documenting why the change isn't practical. That can be adding a test or adding a comment.
I recently had 3-4 interviews in the same format. Its so frustrating and heart wrenching after rejection. For a job i have to go through 2hrs of coding interview.
I've had to jump through those terrible "online coding challenge" hoops for jobs that didn't even involve coding! Tech companies far and wide are currently obsessed with them, to their detriment.
No--instead you get dance-like-a-monkey "coding tests" (unpaid, of course) that are nonportable from employer to employer.
Anecdote time! I had a potential employer ask me to do the tutorial for their framework before the interview. I submitted a pull request to fix errors in their documentation during the interview. I got the offer but didn't wind up taking it. I don't do those types of things anymore because it's more beneficial to them than it is to me. I could see the value in doing it if I was a junior dev trying to get my foot in the door though.
I had something similar where they had a test app online, but the test environment was broken to the point of it being non usable. Emailed them as to what was broken including error messages. Got an email cancelling my interview twenty minutes later.
I disagree, my side projects have led to many employment opportunities, including my current one. I also get recruiters contacting me and mentioning my side projects. I often suspect their system just found my projects and dumped them into the email, but other times the email is clearly from a human who has read my blog and/or investigated my projects.
They are not that successful, a few dozens stars generally for the most serious ones. And also, there are not especially trendy (no fancy react app or js library, but stuff in python (lib, web ui), C, a puppet module, some shell scripts and little bit of perl).
With that, in 5 years, I was contacted only by 2 or 3 recruiters/contacts that emailed me because of my projects.
For two of them, it was more a general look at which languages I used in my projects ("hey, this guy knows Python and Bash, he may be good for an SRE position").
The last one actually came across one of my project which is a little bit domain specific (an RFC 3161 timestamp server), not sure if it would have ended in a recruitment offer however.
I get more offers through my crappy linkedin profile.
> instead you get dance-like-a-monkey "coding tests" (unpaid, of course) that are nonportable from employer to employer.
This - the non-portable aspect - is what irks me the most.
Especially for enterprise developers. Since most of the software we develop is under NDA, we cannot put any of it online to showcase our skills.
I've had to do 3 different take-home "coding exercises" over the last 10 days. 1 was for a Hedge Fund, another for a Real Estate company and a 3rd for an Accounting SaaS company.
I'm in the process of publishing these coding exercise solutions after polishing it up a bit more onto my github profile. Still, I feel like this will also be a waste, because like OP says, most companies have their own specific "Coding tests" and wouldn't take an already coded solution to accept skills and experience of the candidate.
The music industry is exploitative precisely because it has this dynamic. I would like the developers lifestyle to be more like that of surgeons than like that of musicians.
That's not the only reason it's a terrible analogy; Musicians are artists, developers are tradespeople. If an interview method doesn't make sense for a carpenter or an electrician, it probably doesn't make sense for a developer. That being said, I don't think there are any good proxies for whether a hire will be a good fit, so I understand the problem employers are facing.
I agree that it is a bad analogy, but I think it goes far beyond supply and demand differences: Music is performed mostly by muscle memory, "system 1", while code is developed mostly by ratiocination, "system 2".
I don't think so. Development seems easy just like singing you can do it at home, have some results on your own computer. But look at talent shows, there are people who can sing and win but still do not have what it takes to build career after winning talent show. Secondly there is whole bunch of occupations that pay well like dentist but how do you even practice that without buying expensive tools.
This is becoming a real problem IMHO. Asking me to do 3 to 4 hours of work on a "test" just to get to a real interview is a big ask. I do it because I have to; but as my time has gotten more valuable I've started just politely refusing and thanking the recruiter for reaching out. I have a ton of stuff on github that I'd much rather talk about.
We generally offer candidates who made it through the 15 minute phone screen to bring along some code to an interview. Quite honestly, it can be their own project or we can supply a simple "test" so that they have something to bring. We make it clear that we're not looking for perfect code samples, or even great ones, just something for the candidate to talk about. This seems to work pretty well, makes sure they're not doing any free work for us, and doesn't ask for much in the way of their free time.
I've had too many "tests" that were a giant waste of my time to ask it of others.
I see the point, but some of these tests can take several hours or longer to complete. I think they shoot themselvess in the foot a bit because many of the really good devs won't waste their time with that. My evidence is all purely anecdotal, however.
You must be applying to the wrong companies then. I just got done doing interviews, and I looked at what the second round candidates had available on GitHub and their personal site, and the one who got the job had about 5 projects that were impressive.
Good employers care. I care. Its not signaling. Its important.
>Good employers care. I care. Its not signaling. Its important.
It's not important. There are plenty of good companies who don't do these things that manage to pay developers $100k salaries. They may assess in other ways, but it's not the only signal.
It's only important to you. You choose what you want to see in candidates. You need buy-in from the candidates that your process is conducive to a good environment, good code, and good delivery. In turn, you cultivate a team who share something in common, and the team gets along well and makes good code.
It's people finding like-minded people -- the same social movements that are in every other profession. There's nothing wrong with it, but there's currently no prevailing right or wrong way to do it, otherwise that would be the technical interview.
Practically, development is still in demand. So if I get rejected, I can go apply some place else. That's why it's not important.
Maybe your pay is slightly above those other companies, but is a marginal pay increase really worth all of the extra effort? That's up to the developer. But the employers that don't use this criteria are not non-good employers.
For me, a marginal pay increase is only a differentiator when comparing two otherwise equally ranked opportunities. I once left a 300k job to take a 180k job on the basis of work content, cultural fit, and optionality. But, I make most of my money by holding XMR, so the difference in pay doesn't determine my quality of life - nor my ability to exercise charity - which is, practically, the same thing.
Best company I worked at looked at my personal site and Github, albeit briefly, ahead of time and didn't ask much if anything about it (IIRC). They asked more peer-level questions. Pretty casual. As my first job out of college they didn't expect much from me but later told me the other devs were impressed. Best group of devs I've ever worked with. All of them were pretty smart, wrote nice code, comments, knew how to use version control, and configuration management. They wrote their own JS framework that interfaced with a Java backend. I would later realize (in retrospect) this code was really well written and maintained.
Worst company I worked (work) for (but pays well) had me answer a few questions on a whiteboard. One of which was 'not even wrong' (the answer was: "HTML5 gave us the <strong> tag to replace <b>").
They were desperate for bodies after a bunch of people left. They also partake in the usual H1B/contractor games and wonder why they have shit code. Meh, my project is going well. If they have me work on their main .NET monstrosity though, I'll quit. Haha, jokes on them.
It's not important. You're skipping out on a large pool of fantastic candidates who have families and hobbies outside of work. People who save their best programming effort for their job. Relying on GitHub / side projects as a barrier to entry is ridiculous to me.
The interviewer has checked the "codes in his spare time" checkbox" and I've guilt tripped them into skipping the dance like a monkey test once or twice by pointing them at my github but that's about it.
I'd be super impressed if a prospective employer looked and made some sort of salient comment, but it's never happened and probably won't.
As much as I hate it, the problem with taking the github profile as evidence of proficiency is that it's easy to plagiarize, and the applicant has a significant financial incentive to do so. Obviously plagiarizing code samples would be a terrible career strategy, but that doesn't protect you as an employer if you get the one in a thousand con artist who can collect six months' salary before people start to ask difficult questions.
Another hiring manager here who reads GitHub profiles and loves to have a candidate walk me through what challenges they experienced, design decisions they had to make, etc.
One question I have for the grandparent post: what would a meaningful question be? Is the description I mention above seem like a meaningful way to discuss the work you took the time to share with me?
FWIW, I'll look at a candidate's Github account whenever they list it on their resume. That doesn't mean I'll bring it up during the interview unless there was something particularly interesting to talk about.
It's pretty useful for screening candidates, especially looking at code written <1 year ago. I do keep in mind that code written in free time might not have the same standards as production code, but often there are some red flags that carry over.
You realize that github dates can easily be falsified, right ?
Besides, you are only using this as a negative ? So you'll actually hire people who don't put in extra effort over people who put slightly substandard free time code online ? That seems like a losing strategy.
I've always found that willingness to put in effort vastly outperforms ability. Not to an infinite extent, but quite a bit.
> You realize that github dates can easily be falsified, right ?
If someone knows that much git, I'd hire them regardless. I'm so sick of untangling other peoples failed merges or trying to explain what the "not a fast-forward" issue means when their push fails.
To be fair to the people whose merges failed, I believe this is a shortcoming of git (the tool) and not the people using it.
It is fair to expect a developer to invest sometime in learning their tools well but git is a different beast. I know it solves a very complex problem but the fact that it exposes a complex interface to the user to do so seems like a shortcoming of the tool to me.
Heck, we even have a comic for it that shows how sometimes just saving my work, deleting my clone, re-cloning the repo and applying the changes in my work is easier than understanding the Git error messages: https://xkcd.com/1597/.
The tooltip in the comic is also sound advice: If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything.
Haha nooooo, it's really not that difficult! I really don't think git is a different beast. It's much, much harder to master a programming language or web framework.
Compared to something like Rails, iOS development, or React + Redux + Redux Saga, Git is just a couple of commands and basic concepts. Everything is listed here, and I don't think that's an unreasonable number of commands to know: https://git-scm.com/docs
The number of commands you show may not be unreasonable. But after spending many years in the industry, I think it is far easier for me to learn C++ with all its different types of pointers than it is to learn what Git is trying to tell me when I have screwed up something.
Either Git has a complex user interface like I claim or I am beginning to grow old.
> To be fair to the people whose merges failed, I believe this is a shortcoming of git (the tool) and not the people using it.
I disagree. Like everyone, I've experienced a failed merge that turns into a diff nightmare. However, when it has happened I've figured out how to solve it myself instead of wasting someone else's time with it, and it hasn't happened in years now leading me to believe it is directly correlated with git skill-level.
>You realize that github dates can easily be falsified, right ?
Yea, but why would someone bother in this case?
>Besides, you are only using this as a negative ? So you'll actually hire people who don't put in extra effort over people who put slightly substandard free time code online ? That seems like a losing strategy.
That's not what I said at all. It's potentially a positive or a negative, just like anything else on a resume. I've seen plenty of Github profiles that have files with 2000 lines of spaghetti code and no structure or testability. Just like I've seen profiles with neat projects and excellent code.
>I've always found that willingness to put in effort vastly outperforms ability. Not to an infinite extent, but quite a bit.
Anecdotally, as someone who has been involved in hiring and (sort of) cares about side projects, it's not actually the technical implementation I care about, that's true. It's about the applicant signalling "I care about this stuff". But it's far from the only indicator and shouldn't be given too much weight. I'd gladly hire someone who had no side projects but passed our technical test/interview and soft skills interview.
As for why I don't take Github profiles too seriously, we had plenty of applicants who did have projects on their Github profiles who tripped all over themselves on our simple coding test. Maybe we would have found out something similar by digging into their commit history, but that would be an even greater time investment than the hiring process already was.
I think that coding tests and challenges apply a sort of artificial pressure and requirement to have things memorized that aren't there in the real world. I think it would be a mistake to discount a candidate who has good code on their github when they had time to sit, think through problems without being under a magnifying glass, but trips up during a technical interview challenge/puzzle/whiteboard or whatever. Maybe in those candidates you could actually walk through their projects with them and try to determine if they have a deep understanding of what they wrote. To me, that seems a better indicator of how they would perform on a team with real problems, rather than having to puke up a pseudocode merge-sort from memory.
Code is for tech reviewers (CTO or inside developers). Most often, they will look at your repos, but they are not the ones you will chat with.
It's still useful to have material for non tech people, though. That's why, additionally to my github profile, I maintain an angelList profile on which I document the why's and how's of my projects from a non developer perspective.
But of course, the single most important thing you can do in an interview with a non tech guy is to show them you understand their business, what they're trying to achieve, and that you find it exciting (provided it's true, obviously). From having been on the hiring side, I've learned that the worst thing to say is : "yeah, actually it doesn't really matter what we will do, I'm mostly interested in coding".
There was one, (literally: ONE) time I check out somebody's GitHub profile when making a hiring decision. It was a clusterfuck of forks, and source repos were a total mess, no documentation, nothing. In such case I would rather NOT see a GitHub link like that, really. He didn't get a job.
It would be nice if GitHub offered a grouping function for "random" forks. Sometimes you just fork something out of interest or to fix some small bug and they mess up your profile...
I don't share your experience and my guess is that you're not advertising your projects enough.
If you have projects that you're proud of — mention them on your website, on your Twitter's bio, on your LinkedIn profile, mention them everywhere. Even better, once per year go to a conference and talk about those projects in front of an audience, such that you can then have videos on YouTube too.
We like building things and there's absolutely no shame in marketing ourselves or in talking about the things we've built.
I think maybe there's a miscommunication here. Of course I've had conversations about my projects. Of course I've discussed them at length and in public spaces. Prospective employers have never asked. And, yes, it's clearly highlighted on my resume and my LinkedIn profile, with an entire section of my resume calling out interesting and high-quality projects.
Employers do not care. Other people? Sure. Employers? No.
There are also employers that downplay your achievements just to have a reason to offer you less money. The decision to hire you was already made and they advanced to salary negotiation but without telling you.
You just have to know your real market value, how good are you compared to others.
Thanks for mentioning this. I just finished a desktop app. They wanted to pay X but when the little app was done another colaborating company found out so I made 2.5 * X in total. Now the first company came back and they want another app for 4.5 * X. Is this how it all starts? :)
I have put my GitHub + GitHub projects on my resume as individual items with clickable links, but very few employers (mostly nontechnical recruiters) acknowledged them.
I imagine it varies. I have gotten some good mileage out of my github projects in interviews that have resulted from the HN whoishiring thread; I'm sure if I went in for an interview at some line-of-business software shop here in Houston this would only result in a blank stare.
So when I was interviewing as a intern and junior developer, I had _most_ places that actually interviewed me look at my side projects I'd listed on my CV. The one interview I've done at an intermediate level (at a company that reached out to me) also did.
I agree with this, the whole need for a portfolio for a back-office role is bizarre to me - no one who has asked for my github has asked me about them, they are much more interested in me talking through my work related projects.
I've been taken aback during interviews and client conversations when they brought up details about projects I'd posted on my off time. There are people who look at that stuff.
One company I work for rejected a candidate based on Github - he'd cloned some repos and stamped his name on it, and claimed they were his. The hiring tech smelled something fishy, and the candidate said that he worked with these various other repos on the backend. Hiring tech reached out to the owners of several repos, and none of them had heard of the candidate before.
Github was used in this hiring process to reveal a fraud - a different 'success' story to others commenting here, but it definitely birthed 'a meaningful question' or two.
Likewise I've deleted resumes because they claimed to have coded a website when it's clear they simply installed out of the box software. They didn't explicitly lie and say they coded it from scratch, but I felt like they were implying that
Another time I rejected due to side work was a candidate claimed to have written the "worlds fastest framework". Even if it was fast it's possible there's something out there faster, so it showed lack of touch with reality, ego, and lack of self awareness. Note I gave the candidate the chance to substantiate their claims and was met with profanity
I am technical and we will sit down and go line by line, haha. And I know where alllllllll the fun code is hiding, not just the boilerplate. I get real deep in there. I’m sure my methods probably weed out some folks who don’t or can’t drop trou, but I never expected to catch every single fish in the ocean.
You're espousing a false dichotomy. The options in evaluating a candidate aren't merely "give them whiteboard coding problems" or "examine their side projects". Give them a take-home assignment. Give them an in-person assignment where they have several hours to complete a smallish design-and-build task. There are a lot more options, and I'm getting tired of people claiming they don't know how to evaluate technical candidates when it seems like people are just saying "whiteboarding is a bad test" and throwing up their hands and giving up.
Sure, you can use side projects to complement other data, but if you're relying on it as the primary measure of a candidate's programming skill, you're doing it wrong.
Giving a candidate a "take-home assignment" is actually the most disrespectful of the options listed.
Unless you're an awesome company, with really cool projects and offering me a jaw dropping salary and benefits, then no, I'm not going to do free work for you. Even if you are an awesome company, people probably have to actually work for you to see that, so no, I'm not going to do free work for you.
I'd rather spend those hours doing work that I expose on GitHub.
> in-person assignment where they have several hours to complete a smallish design-and-build task
That's another proxy that's as useful (or as useless) as a coding exercise.
I don't know what kind of homework assignments those companies give but I can't even imagine how something a candidate could code in a few hours could have internal use. It takes days for even new hires to start contributing useful projects, let alone a never-before seen candidate without knowledge or access to the codebase and internal systems.
The homeworks are mainly a time saving device on one hand, where they replace an hour of phone screen time for an engineer with hopefully less than 30 minutes of grading. For the candidate, they may take a couple of hours instead of 1, but they also allow for a more relaxed setting with use of IDEs, Google, etc. and no interviewer watching the typing and tapping their foot.
"Free work" in this case doesn't necessarily mean "free work which is useful to the company" it just means doing similar things to what I'm payed to do normally for free with no benefit to myself.
I've gotten complaints from companies where I've done homework assignments for interviews that it didn't seem like I put enough effort in and my reply has always been that I get payed good money to do this stuff at work, they're getting the left over hours in the evening when I'm of course not performing at my peak. If they want work-level quality they should pay me for the assignment.
That's fine, I'm happy to hire someone who is dedicated, passionate, and loves coding enough to to a quick assignment. Its not free work, its a demonstration of skill.
In fact, we just hired someone who did that, and her assignment came back better than expected. At first we were so-so on her due to potential lack of experience, but the assignment (and her projects on her personal site) showed us were wrong.
Was it paid? If not, then it's free work. Call it whatever you want, in my experience the people talking about passion the most are those that are just looking to pay the least they possibly can.
Until we have established a name (track record) for ourselves, and/or have a number of respected people vouch for us, we are called on to demonstrate our skills, just as musicians and actors are.
In principle, I think this is reasonable, especially since there are reportedly many fakers and exaggerators applying for jobs.
In practice, it appears that there are so many shoddy auditions that we must endure when looking for a job, that it becomes almost a full-time waste of time. This is unreasonable, methinks.
The problem will become serious when nearly every company that is hiring runs a low-quality dog and pony show in which we must perform, or not be hired. We can already see an analogous issue in the ubiquitous presence of objectionable binding mandatory arbitration clauses in seemingly every contract we sign nowadays.
That's another reason the "audition"/side project analogy doesn't work. I'm a musician. When you audition for a band, it's a matter of walking in, plugging in or setting up, and playing a few songs with the band.
If the musician is any good compared to the people they've already auditioned, many times you won't play another song. The band will hire you on the spot.
If I owned a carpentry company, and I was trying to hire a carpenter, yes, I would ask them to build me something. Maybe not a dog house, but a bird house. You don't think that would be reasonable? "If you want us to hire you as a carpenter, prove to us you can build a bird house first." That seems totally reasonable to me.
If I hire them to fix my roof and they leave a huge hole in it, I am expected to sue them and wait for a few years to recoup my losses (while having a huge hole in the roof).
So you are admitting you are bad about making decisions about people? Luckily you have something empirical because you are no good at judging someone. Thanks for admitting that, the first step is accepting you are no good at evaluating people.
> So you are admitting you are bad about making decisions about people? Luckily you have something empirical because you are no good at judging someone.
This is almost entirely the point of take home assignments. In fact, this is almost word for word what my response would be to anyone who doesn't like take home assignments!
> Thanks for admitting that, the first step is accepting you are no good at evaluating people.
Step two is admitting that, in general, evaluating people using non-empirical means is an enterprise fraught with peril.
I largely agree, but I have had one experience that opens a tiny bit of wiggle room for such assignments. During a phone interview with hiring manager, he asked me if I had experience with X, Y, or Z open source projects (all relevant to the team). I told him that I did not, but that I'm always eager to learn new things. He asked me to pick one of them and 'build something' that uses it (no more specific than that). I instantly recoiled at the idea, but I didn't verbalize it. I went along with it. I decided to take the 'when given a lemon...' point of view and build something that was of interest to me.
A few weeks later I came onsite for in-person interview. I brought up the assignment and was able to use it to show my interest and capability of quickly learning and putting something to use. I really believe it worked to my advantage.
If the assignment were to implement something very specific I would not have done it. In my case the assignment was so completely open-ended and was able to convince myself that it wasn't a 'work for free' situation.
You can actually achieve a happy medium between the two. About 2 years ago I interviewed with one of the large SF-based enterprise companies. They emailed me a cool little assignment (parse a text file that describes dependencies and build a graph, output install manifest) and asked me to send back a solution in an hour and half. An engineer was available to call on the phone to answer any questions, but otherwise I was left alone to code in peace, with no screen sharing or other kinds of watching as I coded.
It's probably the best phone screen/coding assignment experience I've ever had. No pressure from someone looking over your shoulder, but limited in time and scope, so I didn't spend all day working on it.
It's kinda funny that so many people have this attitude, when, as a salaried employee, we likely have all done more than a standard 40-hour work week on occasion (or habitually), without extra compensation.
Do you also consider time spent prepping for an interview (brushing up on algorithms, learning about the company, researching interview questions, whatever) as "doing free work"?
I just really don't get this attitude. It's not "work", it's a evaluation. And it's an evaluation that actually displays skills relevant to the job, unlike many other approaches.
Most people already do not like brushing up for algorithms. Learning abou the company should take 20 minutes at most. When these assignments take hours of your time with little to no feedback (from my experience), it feels like busy work.
Depends who you're hiring. Early career devs with a lot more time than prospects, and who have already spend a good portion of that time working for free on exercises and toy projects in the name of learning, might not have a folio of work to prove their skills. Crusty HN regulars probably prefer to chuck a github profile around, or provide samples of work in some other way. I don't think it's one size fits all.
Our industry could follow after the restaurant industry and implement stages/trialing. You come in and work a full day. If you get the job that days pay shows up on your first paycheck, if not they send you out the door with a check.
True, but a paid short-term contract to do an actual task for the company would work. Knock out a small feature during the night/weekend. Keep it something contained and relatively straight-forward. If they can get it done, it demonstrates the candidate's ability to parse your codebase (so they are learning something they'd need for the job anyway) and they have contributed.
I think most companies just don't want to take the time to set this kind of thing up. Easier to just pass on people that won't do the requisite song and dance.
No it still wouldn't work for someone with a current job. That's a huge risk if you're responsible for supporting a family. If you quit and the new job doesn't work out, then you're kinda hosed.
Doesn't really work for any larger scale product, it's unlikely that any candidate will be productive in their first day. Sure they could build something separate but then the value for the company probably diminishes. Unlike serving dishes the process of making software differs quite a lot between workplaces.
That's not entirely true. The way kitchens are set up/configured, what goes into dishes, how stations are set up, etc can change quite a bit from place to place. Additionally there's usually kitchen slang/words for most items on the menu which need to learned.
Also I've had many dev interns at my company, it takes work on my end to enable them to be productive quickly, but it's not impossible. Maybe you need to write some skeleton code for them to fill out and unit test, maybe you need to document things well and spilt up your tasks well, but you absolutely can have some one come in and be productive day one.
In fact my interview was a college hire group interview, we were given a laptop with skeleton code in multiple languages, a problem to solve with fixed inputs. The problems were similar to what you'd likely encounter for whiteboard coding, except I got to be left alone with a computer, the internet, and my editor of choice to write actual code to solve the problem.
My current employer, when hiring me, said "Have you ever looked at the Firefox codebase? No? Good. Here, take this Firefox bug. Fix it by Monday, or at least analyze the root cause, and let's talk about it during the interview".
Needless to say, they had no interest in Firefox per se. It was just a cool open-source project, and a good way to give me "actual work" while making it plainly obvious that it wasn't for their own benefit/ they weren't looking for "free code via tech interviews"
This seems like a weird position to take from the employee's side. I'd much rather work a few hours on my own schedule and on projects I choose and that I can then show to multiple companies, than to have to write multiple custom hours-long projects for each company on a fixed day.
I would say take-home assignments complimented with an assurance of an in-person interview is the trade-off that I'm willing to make. I recently interviewed with a company that gave me one and told me that my solution would be the basis for the final onsite interview, which made a lot of sense to me.
After I submitted my solution though, the company came back to me and said that they had received a lot of submissions and would not move forward with my candidacy. This made me intensely angry as I had spent an entire evening coding up the solution.
To add insult to injury, they even asked me to remove the solution from Github where I had posted it (I had not posted the question so it wouldn't really make sense to someone just glancing at it). At that point I stopped all communication with said company.
Likewise the companies that think they are more important than my private life are not worthwhile for me to apply.
If the HR isn't able to evaluate my skills from my references and the projects I helped my employers and customers to earn, there are also lots of companies to apply for.
Just like employees, companies aren't special snowflakes.
Besides most of my github stuff is useless for my type of work, because I am forbidden by contracts to publish anything related to our projects.
I don't understand the haughty attitude with which many companies treat potential candidates. And there are some truly terrible ones out there. Its worked well for me since I wouldn't want to work in a place that treats potential future employees that way. But in most big orgs, HR and hiring is somewhat divorced from the actual day to day so I keep that in mind as well.
Isn't that what pretty much every side project is anyway? Unless you're an active OSS developer the chances of any of your projects being worthy of judgment is pretty slim.
I've got 10-12 repos on github I can show you...they're all half baked weekend projects that I did just to tinker with some new technology or idea I had. None of them are production quality, and most of them I'm appalled at anytime I go back and look.
none of my private doodles have gone through design review, actual testing, user feedback, deployment, and the 500 (or 1000 or 5000) closed bugs it takes to make them representative of professional work.
neither does that 1 wk coding exercise you made me do unpaid which I'm pretty resentful of.
If you have an open source project and want me to fix a couple bugs and do some reviews to see what kind of work I do, thats pretty fair (Rethink asked me to do this, I couldn't afford the time, but I thought it was a good plan)
Otherwise, I really don't know what you expect to learn
A lot of programming is real grimy and there’s a lot of skeletons in every closet. Par for the course. I’ve seen it all. The code isn’t the code, it’s a conversation we have about how you think. So many people dragging me in this thread think it’s about the code. It is not. I’m interested in the person. The code is just an artifact and a conversation piece.
Most assuredly. But what are we talking about on a whiteboard? Not the things that I personally am interested in, or the things in my opinion most important to the success of a project.
Honestly the code review isn’t for the obvious rock stars. Anybody can pick them out. It’s for the sleepers who might not get a fair shake but who can deliver.
I feel the same whenever I have this discussion. The "Look man, I have a life and I don't want to do extra unpaid work just to get a job" attitude is misunderstanding the motivations (to be fair, there are some situations where they are not).
I look at what people do outside of work that isn't writing code. Having something means you are probably healthier, less likely to be burned out and more likely to have experiences that let you better understand what solves real customer/client/user problems. I don't want to hire someone who only writes code, they aren't as good at solving problems.
Now I have to know if you can actually code. The best way to do that is to look at some code you've written. That's basically the extent of it. I'll do some extra work to come up with a take home project if I have to but if there is a great candidate already, and they have a github with good code in it ... I have to manage my time and I'm often chasing them when hiring, not the other way around.
Open sourced code on Github is just the most common way to do that, and it does get bonus points for having examples of dealing with actual users in issues and involves giving back to the open source community that you almost certainly take from.
But honestly, I really just want to see some actual working useful code you wrote.
> Having something means you are probably healthier, less likely to be burned out and more likely to have experiences that let you better understand what solves real customer/client/user problems.
I didn't learn to write code until my late twenties. I have a fine arts degree. My early and mid twenties were focused on activities unrelated to technology. I have a reasonably large amount of life experience unrelated to programming. I haven't found that this experience gives me an edge in solving problems in my job as a programmer. Can you provide concrete examples that demonstrate this idea that people who code less outside of work are more effective problem solvers? I've seen this truism floating around quite a bit lately but have yet to see it demonstrated.
Not that you code less outside of work, but that you do other things and meet other (non-programmer) people.
As to how that helps: it doesn't help you solve implementation problems, it helps in designing the software to do what the client wants in a way they will like.
It is hard to put yourself in the shoes of a different person to design something for them if you only hang out with people like you and only use software built for people like you.
As a concrete example: what would a piece of software for artists be like if your only-engineering coworkers designed it vs. you having some input? By the way, it would definitely be either a portfolio hosting service or some kind of art database software. What problem do artists have that could use some software help that they aren't even aware exists?
The reason you have a hard time with it is because often the skills acquired through disciplines in the arts are less tangible then something technical.
If nothing else, you might be more interesting to work with, have a clearer communication style, better taste in evaluating what "looks good", etc. etc.
These aren't a substitute for skill, but past a certain skill threshold other things start play more significant roles.
Edit: I really don't understand this pattern of down voting comments without offering a rebuttal of any kind. What exactly about this comment was against HN guidelines? Last time I checked, disagreeing with a comment wasn't grounds for down voting.
I agree and would like to emphasize all of your points.
It's somewhat ridiculous not to hire someone because she has no line of code to show, as there are plenty other ways to poke at their knowledge.
But I'm bewildered that this person has zero line of code to show. The only case I could think of where that makes sense to me is that the developer is still in college. Imo even recent grads generally have something to show off for what it's worth.
You don't even need to be hacking every night and week-end for that to happen. If you're a minimum into what you do, chances are you put at least a night or week-end aside to hack together something.
Personally, I'm far from behind a great developer, but you can find loads of "unmaintainable junk" in my GitHub (github.com/hery). And as many pointed out, when you're prolific, you tend to accidentally produce valuable things, and I do have some decent projects in there that I explicitly pointed out in the process of interviews, which helped me skip technical challenges or interviews straight to offers. A bit extreme huh?
Most developers have a life and hobbies outside of coding, and I believe it holds even truer for the best developers. But with decent priorities, it's easy to invest some time in hacking side-projects. Otherwise it feels like you're putting 99% into other hobbies, and 1% into coding, i.e. you're just doing it to make money. Balance is key.
I think the author is confusing the search for passion with the search for better information. If you can’t share code from past and current employers, and you don’t believe that your quick and dirty solution during the interview represents your best work, then a side project that shows a little carefully crafted code is one way to give a potential employer better information. And better information derisks hiring decisions. With perfect information, hiring decisiInd make themselves. It’s perfectly fine to prefer art projects to side projects in code, as long as you also accept the informational disadvantage and its repercussions.
There seems to be a weird inversion in the minds of many commenters here: that they are somehow entitled to dictate the terms under which they are selected to work somewhere.
Isn't the point that if you want the job, you do whatever it takes?
Why are we not celebrating the fact that we work in a kind of meritocracy where it really is possible to showcase your skills without any credentials or reference to your past?
All of this bloviating about "wasted time" in the context of demonstrating skills reeks of bitterness from lost opportunities to me.
People who refuse to do that are only hurting themselves.
If an employer passes on candidate for the wrong reason then the employer is hurt as well. A good hiring process shouldn't rule out people for reasons that aren't related to their capability to do what they'll need to do in the job, and very few jobs require a good github profile. It's a useful proxy for development ability and passion, but that's all. You can be an awesome developer and never touch Github.
If you want people to show up with code why aren't you asking them to take home something and show you their solution in the interview, working through it step by step?
I guess I see that as disrespectful of their time, but I could probably work something like that out. I run a small shop. I am allowed to use my good judgment.
What about the time it takes for interviews? Is it being disrespectful to take up an hour of their time for an interview? What if you do a 2nd interview for another hour? What if you have a 3rd? It's not unusual to have 2 or 3 interviews before hiring. What if you replaced one of those hours with a coding task that should take under 1 hour to complete. Is asking for 1 hour disrespectful to their time? Why is asking for 1 hour of their time to code different than 1 hour of time for interview?
I think the expectation that I have random projects that I'm passionate about to be more disrespectful of my time. I have to compete against an unknown, I don't know what the other people interviewing will be doing for their projects so I have to try and make it more impressive than projects I don't even know about.
It's much less stressful and takes much less time to give me a basic to intermediate coding problem to solve on my own with a pre-set number of days/hours to work on it.
I think many of the people on HN that say they won't do a take-home assignment would actually do a 30-60 minute take-home assignment if it meant avoiding the "code some algorithm on a whiteboard while the interviewer glares at you" situation. Then on the on-site, you can focus on the design/behavioral type things appropriate to the role's level of seniority.
Also, if you give the same assignment to multiple candidates, you'll get a better sense of how people use different approaches to solving a problem. You can still use discussions around side-projects to complement the process, but having a standard approach for all candidates is helpful.
> I think many of the people on HN that say they won't do a take-home assignment would actually do a 30-60 minute take-home assignment if it meant avoiding the "code some algorithm on a whiteboard while the interviewer glares at you" situation.
Except it never means this. It's always "and" and not "instead of". Many companies do these irritating programming challenges now, and then when you pass them, will still bring you in for the standard Whiteboard Hazing sessions.
Most people would not think twice if a potential employer interviewed them for 30-60 minutes and then asked them to do a follow-up interview. It's not that unusual to have 3 interviews before getting hired.
But if you ask them to do a 30-minute coding task, that suddenly becomes a total disrespect of their time.
>I’m not mad at you, but as the dude on the other side of the desk, I have to decide whether you can cut it and I’m fine saying no. I could make you do some whiteboard problems, but I think whiteboard problems are pretty far removed from your day to day development and I am uncomfortable relying on them as a proxy for your ability to ship code.
So, are architects and engineers expected to have built side-houses, and side-bridges, and side-cars?
If you're working 60 or 80 hours per week churning code, surely you have some code to show. </sarcasm>
Really now, the fact that you can't showcase what you've done for your previous company is an implementation detail. Using a portfolio to judge a candidate is perfectly valid and works great with other industries. The reasons why you don't have one are your own concern.
Like I said in other comments, interviewing is (for better or worse) a game / competition. You need to optimize for success.
Yep. I've built quite a few useful shell scripts over the years for various employer tasks or demands. Only one of those have I taken with me, which was a quick 5-minute job to figure out what was causing a system to crash in absence of a significant monitoring solution that could give minute-by-minute specs.
At my last gig I spent a few days writing and troubleshooting a script that would perform automated tasks for setting up servers for DBAs given their specs and demands. Easily one of my most shining examples of making bash work for me. It's back with the employer since it's their property.
what you do at work absolutely is - there's a question about non related work done off the clock and with your own equipment - but its unlikely that most have the $$ to be be able to fight a lawsuit
Sure, sure. And if you followed the letter of the law I’m sure you deleted it all from your laptop promptly and is unavailable to you no matter what.
But if you didn’t, for whatever reason, and you happen to have an illegal copy of some production CRUD app hanging around so I can look at how you organize your thoughts, nobody I’ve interviewed has ever gotten even a whiff of heat for letting me look over their shoulder and see how they wrote their schema. I don’t want a digital copy and I could give a shit about your illegally retained IP (and there’s a whole lot of it floating around). I want to know what you name your variables.
The best way forward is absolutely some open source code, folks clean up better in public and you don’t have to make apologies for things that weren’t your fault.
But this smells like folks just wanting me to take their word, and it ain’t gonna happen. I’m flexible, but when in doubt I choose ‘no’. If the next guy can prove it and you can’t, hey, plenty of fish in the sea.
exactly. I work damn hard when I leave a place to make sure I have absolutely zero IP. its likely none of it would be useful to anyone anyway. But thats what I agreed to explicitly, thats what my former employer wanted, and as unlikely as it is that anything would happen I wouldn't want to taint a new company with code that can't be clearly attributed to them (which is what they paid for).
I was kind of with you up until this point. That's a line that is foolish to cross.
Any candidate who plays fast and loose with their previous employers' code is going to play fast and loose with _your_ code. Or your corporate secrets. Or lifting GPL code. Or pretty anything else they think they can make off with. Such employees are a lawsuit waiting to happen and are best avoided, as are employers who tolerate such employees.
I don’t know their arrangment with their old employer and I don’t ask. Very often folks will have an ongoing maintenance consulting relationship and retain some IP just in case. More often folks will just have some stuff lying around, and they’re already breaching their contract by having it.
Believe it or not, there’s next to nothing I’ve ever seen that was the remotest bit interesting on an industrial espionage level. Just regular old business logic that was either cleanly done, or not.
I honestly could not recall any of the crap from the interviews I’ve done beyond a sense of how people thought.
Anyways, you wanna do some interviews your way, be my guest. I will happily send the guys who don’t want to do show and tell to you. I’m not trying to be all things to all people. No open source, no closed source, no side projects? We can play API bingo or code a b-tree, but prob not a culture fit.
I have the feeling that the point was the simplistic and damagingly narrow screening process here not the criticism of screening as practice, quite the opposite.
The side project request became so mechanistic that everyone can expect it but the reliability is questionable as the authenticity of the product is beyond validation. When people face something expected in a competitive situation then the really competitve - and unethical ones - will go to great lengths for raising their profile even through manufacturing reliable looking evidence (doing it continously, possibly plagiarizing), posing as excellent through acting.
No good and easy - and cheap - screening process is available as the reliability of workforce is multidimensional beyond the human capacities to comprehend, also beyond the technical level.
Over the years I had bright but unfit colleagues (damaging the team effort, jobhoppers, unsteady performance, cheaters) as well as average ones with grey personality carried the company on their backs.
The real test of the bread is eating. They have to show in the particular environment if they are capable in that very specific situation or not.
Side projects will tell nothing on this. Using it as a turning point is very ... to be polite, unwise.
Still not questioning the need for first filters so the chance of wasted efforts is minimised by not nurturing someone inadequate into the precious environment for months in vain. But that first filter must be way broader than the topic of side projects.
Sure. But you seem to be approaching interviews as a one way street like, "I hold this thing here which I will give it to you if I deem you worthy". That is not how things work these days in tech, especially in hot markets. If you are not willing to carve out time there are plenty others who will. Sorry dude, just the reality of the rare market situation where the power is balanced between companies and talent.
I agree 100% with this viewpoint. I would much rather sit down with a potential hire and go over some scripts and projects they've written than go to the whiteboard. I don't care how big the project is, I think it's just much more pragmatic to share ideas and stories over code than algorithmic gotcha questions.
I'm sure you realize that it takes 6 months for the average person to become productive at a new job. If you can't factor that in to a new hire you're probably working at a typical coding sweatshop.
The best piece of advice I got about hiring was that the interview is to find a reason to say no. Too many people want (expect?) the point to be to find a reason to say yes. For better or worse, some companies will use lack of OSS contributions or side projects as a reason to say no.
If you hire explicitly based on code with no way to gauge ability to collaborate with others, design, or probe business requirements, I really wonder how strong your team is and how competent you are as a manager.
Our client always ask for code samples. Code samples we use from projects. When we hire a dev. The dev needs to at least have a github and "some" code samples. its what the client wants ( i know ignorant but here me out)We work with the project owner, who's boss ( signs the check) applies pressure on him ( blames him really) for any fuck ups in code / app failures) Meanwhile the boss changes the app features on a daily basis. So the PM does not know any better since he has to have the code approved from another teach lead. So if you want to make money you have to provide ( proof of work / code) which may take the form of a side project ( demonstrates your not in it for the money without passion) I don't know, just my experience with hiring a dev.
Do the side projects have to be domain specific? What if I were applying for a front end developer job and had some hobby projects doing GPU shaders or a toy database in C?
I work on internal tools for a major company. You can't see them, some I probably shouldn't even tell you about.
When I get home I play video games and watch tv and play with my dog. sometimes I'll screw around with a new language or something else. I don't post stuff on github and keep a blog or anything else like that.
I think your view is pretty myopic. Ask me to talk for 30 minutes about one of my projects and force me to answer some tough questions about it. whiteboard some designs.
Maybe I should just hire some guys off a freelance site to write me some side projects.
This will sound flippant, but you can’t win them all.
There are hordes of false negatives in any hiring process, anyplace. My process is more accurate IMHO but it’s indisputably more work and it does not scale at all. Ultimately everybody is going to beef with any criteria they don’t align well with and I have to remain flexible enough to not throw the baby out with the bath water. I don’t mind getting drug a little on HN— I have a good team, and their open source contributions might not be as impressive as you assume.
> When I get home I play video games and watch tv and play with my dog. sometimes I'll screw around with a new language or something else. I don't post stuff on github and keep a blog or anything else like that.
Presumably you also don't think people should stop thinking side projects and public code is important in hiring. You've made a choice to not have these things and asking the world to change one of the few sane things in hiring because you just don't fit the mold is a whole other story than just accepting that this is something you lack that could potentially sway an employer.
As another comment said: You can't win 'em all.
By chance, I happened to have a pretty productive few years on GitHub and having no degree I still managed to land the first job I went to interview for, in part because of my GitHub profile. Am I "for" the current situation because it benefited me at the time? No, because I think it's a clearer indicator that a colleague won't be a nightmare to work with than a degree or if he can implement the correct data structure on a whiteboard.
As somebody who has been on the hiring side (not the hiring-manager, just the technical person assigned with deciding whether someone looks like they are what we want or not), I've often just been given a CV after they've been 'pre-screened' by HR.
The issue is I'm usually given a bunch of CVs, and I need to fit this in to whatever other work I've got going on (probably too much already which is why we are hiring). I can arrange interviews, but that probably means I'll need to stay after hours (a lot of people can't just take an hour off in the afternoon to go for an interview), so it's in my best interests to filter down that list. Plus arranging interviews won't just happen the next day - although we need someone yesterday, just deciding who we want to hire is going to take another few weeks.
If I can see that you've got some open source projects or a blog or anything to show how you work, it really helps to make you stand out from everyone else, because most people don't have anything to show. If I had a candidate that looked good, I wouldn't throw them away because they didn't have any side-projects, but if I've got two candidates who both look good on paper, that probably would be the deciding factor.
So yes, hiring someone to build some side-projects for you might be beneficial. At the very least you could use it as a management side-project :D
Another place I worked at gave a small programming assignment (build something to import a CSV into a database). It was pretty simple, and would take you no more than two hours, but it was rather good to see how people work and whether they could follow instructions (>50% of candidates ignored the "write tests" line). This was used to screen people for an interview, during which we would ask them questions about it.
Eh, the Duds can fork github projects too, add some minor feature and release the "project" to rot.
You do not get to see people who get stuff done- you get to see people who optimized their "work"-life for the impression of getting stuff done.
Not beeing ready to pour unreasonable hours in- actually is a good sign. Such a person values his/her time- and thus will think on there own, for example when handed ridiculous feature requests. Such a person will stand up to me, and ask questions that might save month of development time sunk into unnecessary work.
Sorry, but we are not building the pyramids here. We are making software- and for that a lazy-loading brain with a clever work-avoidance Algorithm, in a un-passionate mercenary can be very effective as a development tool.
Since you can see right there in Github's UI that something is a fork and that they are not the main contributor to the project, the dishonest applicant would have to go through some trouble to fake it as a sideproject.
The same dishonest person can also just lie about their work history.
It's funny that the tech industry is so insistent on side projects. I mean - would you hire a marketing person based on their 'side projects' or a corporate lawyer purely based on their pro-bono work? Likewise, who on earth asks a building contractor if they have any side projects? You would ask for references or find a contractor via someone you know. What about recruiters themselves? How does one judge if a person is going to be good recruiter or not? What about sales guys? Does anyone ask them - do you sell stuff on the side - Y'know maybe you just do door-to-door selling as a hobby. Or what about other engineering disciplines? Does one really ask a Mechanical Engineer or a Civil Engineer about their side projects?
Side projects are for software what a portfolio is for other creative industries. You don't hire a designer sight unseen -- usually you ask for a sample. It makes perfect sense to expect the same of technology.
> Only if you believe software development is neither engineering nor science, and is purely creative.
I have to believe it "is neither engineering nor science, and is purely creative"? Only those extremes? I believe it is some of all 3 and I don't think requesting (i.e. not "demanding") a portfolio or prior work is any more unreasonable than not asking for it.
Fine, then you must believe it's mostly creative. Far more than you think it's engineering or science. Otherwise a portfolio would simply be at best an interesting conversation piece and not at all indicative of ability.
Why do you think a portfolio can't tell you about someones engineering abilities? Can engineering not be judged by looking at source (and potentially surrounding documents)? What would be missing for you to do that?
In traditional engineering disciplines like civil engineering, organizing bodies and licensure communicate competency, applicability, and ethical awareness. Software development has no industry-wide equivalent. There are small certifications for Cisco et al but for the general practice there's no standard.
This frequently comes up in discussions like this. Licensure is a joke with respect to demonstrating competency. Yes, the initial hurdle is high. However, once you are licensed it's hard to lose it. I would never rely on licensure as a measure of competency or currency.
On top of that, many electrical and mechanical engineers are not licensed because they don't need to be. (Everybody likes to jump to the civils in these discussions and forget about us, since civils are basically required to be licensed.). EEs and MEs don't get put through the same bullshit that this industry puts developers through.
I hear this a lot but I think it's deeper than that, such that letting the industry age isn't going to lead to the same end. The issue is the very one that is in this thread: programming is at a weird intersection between art, science, math, and engineering. Credentials and licensing matter a lot less than simple output. You can gain a ton of experience in the field even if you're stranded on an island with no internet and just a solar powered laptop capable of executing new code. Even without a computer you can still work like a mathematician and propose problems, even creative problems with no engineering applications, and then solve by coming up with and writing down algorithms for a computer you don't have. You can imagine arbitrary business details that get in the way of a clean program and force you to start thinking in architecture and system design.
Demanding a portfolio isn't a great hiring strategy simply because a lot of people's best work isn't out in the open. Who would demand a portfolio from someone like Mike Acton? It'd be enough to know what he's worked on and talk to him. And at the same time requiring a licensing proxy is no help either, he never went to college AFAIK and that'd probably be a minimum requirement for most actual licensing proposals.
Software development is all of those things. You need the engineering experience to know what to do. You need the science to know ways to / not to do things. And you need the creativity to put them together.
Is your "portfolio piece" spaghetti code or well-thought-out modules? Is it doing something recursively that shouldn't be? Do you have elegant code or brute-force solutions? Is it write-only?
All of these can be seen in a portfolio or side project if you choose to look.
> Only if you believe software development is neither engineering nor science, and is purely creative.
It's certainly not a science, and it's very rarely engineering. About the
creativity, it's a craft. There is some creativity baked in, but about the
same amount as for mechanics or carpentry.
This is what I don't get about this requirement. I guess you can quickly see if a developer uses design patterns, writes tests and how easy the code is to understand. I don't think that's necessarily mind blowing though and you could still get stuck with an individual who checks all those boxes and still sucks.
You are thinking about this in terms of one applicant. When you get 200 applications it's very useful to be able to quickly weed out people who are obviously not a fit.
You can also just throw out applicant number 26 and up. You most likely have a few solid candidates in the first 25 worth a phone call. And if not, look at 26 through 50. No reason to look through all 200 at once.
For example, an applicant that goes through the trouble of writing a thoughtful, reasonable README for every one of their projects signals a positive quality.
When comparing two candidates, that's certainly something to consider.
Why? A lot of people (if not most) treat their non-work GitHub as a place to host random experiments and projects. Unless one plans to publish projects for others to use, no one should be forced to have perfect code for a one off idea if they don't want to.
There are a lot of great engineers with empty or "bad" Github profiles.
When I look at a developer's Github profile I know that:
1. They care enough to have a Github profile
2. I can see their actual interests.
3. I know they're interested in random experiments
4. I can see if and how they treat their projects. Are they dedicated maintainers, or do they just fire off one-shot projects without ever deciding to maintain them?
And a whole lot more. A person who maintains a single shell script project with diligence is worth more to me than a thousand developers with bullshit lisp and haskell repositories.
Yes, there's a bunch of great engineers with empty or bad github profiles out there. But those engineers aren't showing me that they're great engineers. The ones with a single or few well-maintained projects do.
I highly doubt there's any reliable signal in any of these points. Someone is only going to maintain a shell script if it has users or it continues to be useful to them. But that fact is not significant regarding ability to deliver quality code. Not maintaining a project on github simply signals that the code isn't useful enough to anyone to maintain it.
Many people have their favored hiring "hacks", and they almost never actually signal for the things they purport to. It's way too easy to fall into confirmation bias or overstate one's ability to judge others.
>I just know a lot of people find side projects fun because they can let loose a bit and try out random stuff that may not be their "best" code.
This is still a huge asset. It's important for a person to want to grow and learn new stuff. When it comes to hiring a person, there's a whole lot of stuff that's important. Maintaining a long lasting project is one of them. Having an interested in fun side projects, also. It doesn't have to be good code. In fact, I have my fair share of "this project is not maintained and should not be used in production code" repositories. That's just shorthand for "this code sucks".
It's funny to see all these comments about people's side projects being "loose" and "experimental". I have a few side projects, and they tend to be very clean, well-organized, polished, because code that you write professionally for a company tends to end up being the opposite: rushed, hacked together because deadlines, full of compromises, and littered with legacy crap that the business can't get rid of.
I mean, what am I supposed to look at? Unless it's obviously poorly written (e.g. no consistent style) how do you judge it?
Perhaps more tellingly I've interviewed people with seemingly impressive GitHub accounts who were just terrible. That experience leads me to believe it's easy to set up a GitHub that "looks good" without having the chops to back it up.
I agree, but the problem with this is that visual design is publicly available, and most professional code is locked behind IP and copyright laws. I can't bring my employer's code base to an interview with another company without risking a heap of legal trouble.
Software development is certainly more creative than electrical or welding work, and thus certifications are more meaningful. In software engineering, what certifications you have or what languages you're familiar with is a comparably poor predictor of your success on a given project.
The next time I'm interviewing in front of a hiring manager who asks me about my side coding projects, I'm going to ask them about their side managing projects.
I'm a hiring manager, and I've been dying for someone to ask me a question like that. I'm proud of the mentoring I've done, and I have a whole bunch of folks I'd love to have candidates talk to to see how I am to work for. But noone ever asks (understandably), and it feels pretentious to force the issue.
> Maybe that's not a job I want, if the hiring manager is lazy enough to 'require' side projects to consider a candidate.
I understand that you might not want a job there and that part of a job interview is deciding if the company is a fit for you. But I wouldn't call a hiring manager lazy because they want to see examples of your work, in fact that's their job. How is a hiring manager suppose to make a thorough evaluation of a candidate if they don't show their work?
So ask candidates questions. You really expect candidates to have work relevant to your interview to show? But you can ask how they deal with problems, cultural preferences, etc.
> So ask candidates questions. You really expect candidates to have work relevant to your interview to show? But you can ask how they deal with problems, cultural preferences, etc.
First of all thanks for being so disingenuous with your responses. But a programmer is actually creating things ie, code and programs which can be shown. A manager is talking to people, going to meetings, emailing people, ie not much work to show, because their work boils down to talking to people. So basically different jobs have different job interview processes, you wouldn't hire a designer or architect without seeing their previous work.
I realize that you're being glib, but I have had a candidate ask me about someone I've mentored (which is basically a management side project) and I thought that was a great question.
Then they'll tell you about what they do for their kids, or how they organise their local squash club or charity ... It's really not asking a lot to demonstrate transferrable skills outside of a day job.
yeah and they are going to write in the slack channel how you were so aggressive and extrapolate how bad of an employee you would be for the company, challenging every little thing with abrasive non sequiturs
You won't likely get hired anywhere without a work sample. Wether that be a side project, code from previous employment, or a coding test, you'll have to demonstrate you can do the work.
Many other professions also require work samples. Even salespeople are required to produce metrics from past jobs on the number of sales they made, and get put through practicals where they need to actually do a demo pitch for something.
>Or what about other engineering disciplines? Does one really ask a Mechanical Engineer or a Civil Engineer about their side projects?
Not civil engineers (because it's hard to build a 4-lane suspension bridge on a Saturday) but very often candidates in electronic and electrical engineering have side projects that can help them land a job. Are the electronics breadboard projects that you did in your garage absolutely required to get a job?!? No, but they help you stand out among the crowd.
The reason that <computer programmer> is different from your analogies of marketers, lawyers, recruiters, etc is that the activity of programming is often a source of fun and play. Some children with curiosity start programming on their own and continue it into adulthood. (And hence, they might have some personal github projects.) In contrast, people typically do not do "lawyering" for recreational fun.
Programming is enjoyable enough for some that side projects on github are mostly a voluntary and organic phenomenon. Some employers are taking advantage of that signal and prefer to hire those types of programmers.
Computing is really noisy and chaotic. There are a lot of dudes out there that just can’t cut it, for whatever reason, and there’s no good way to figure out who’s who.
Whiteboard stuff selects for a particular algorithmic dexterity that I just don’t need a lot of the time. And rejects some of the grungier virtues that make a big difference in moving units in production.
Hiring folks for a couple weeks is fantastically expensive in management overhead. I gotta be highly confident you will work out to take that step.
Just hiring a bunch of dudes and firing the duds is similarly expensive and I frankly don’t want to be that guy. I hate firing people just because I was lazy interviewing. This is my job and I take it seriously.
And there are a whole lot of guys that just don’t ship. They show up. They commit code. They are prompt and attentive at meetings. But if you need to ship, they just can’t shit it out. So many organizations are rotten with these guys- you wonder how so many devs can produce so little product, this is the reason. (Also shitty management- mgmt is ten times noisier and a hundred times more expensive if you fuck up.)
> And there are a whole lot of guys that just don’t ship. They show up. They commit code. They are prompt and attentive at meetings. But if you need to ship, they just can’t shit it out.
Inability to ship tends to be a project planning and scoping problem, not an engineering performance problem. If you can't ship, it's not because you have lazy developers but because you either bit off more scope than you could chew, or you don't actually have a plan that gets you from-here-to-shipping--one that is more detailed than "work harder, guys".
I'm kind of a slacker responding to HN stuff, but here's what I'll say:
Yeah, you're right, if shit isn't shipping, it's my fault.
But.
There are a variety of psychological profiles in computing, and they have various pluses and minuses. I need folks with kind of a... move fast and break things attitude. That's what I select for.
Furthermore, the 80/20 rule is a super real thing and the last 1% until a project ships hurts real, real, real bad. There are people who can push through that and there are people who can't. Yeah, it's my fault we're not sipping tea as we ship, but I've been doing this a long time and I'm pretty good at it, and I can't make that pain stop. I just can't. I've been on teams that shipped and suffered, and I've been on teams that didn't ship.
If somebody's cracked this code for me, man, throw me a bone. But while I'm always trying to do better, I also kind of have given up. I'll make it up to you on the other side, I promise, but it's gonna hurt a little pushing it out.
>Does one really ask a Mechanical Engineer or a Civil Engineer about their side projects?
Yes, sometimes. I'm a mechanical engineer, and frequently interviewers would ask what sorts of projects or engineering related hobbies I have. They're not necessarily looking for me to have brought a mass-produced consumer product to market in my spare time... most mechanical engineers I've met seem to be excited enough if you talk about working on cars or bikes.
I can see how software engineering may be similar. They may not be expecting you to be working on some hugely popular app, they may just be trying to get a gauge on what you're really passionate about. I don't like to wrench on cars in my spare time, but I've still gotten job offers after it comes up. In the end it's just a matter of finding the team that has similar values to you.
Asking for side projects is essentially saying that you think the resume is a pack of lies from back to front.
My work is my work, and my play is my play, and I question the wisdom of judging the play in the decision to hire someone to work for you. Even when I do code at home, away from the office, I do it differently. It might be in a different language, for a different target platform, for instance. I might write more automated tests, because I can't hand it off to a tester that isn't also me. I might write something with a command-line console interface instead of a GUI, because my user base is probably just me, and I know that person is not a helpless idiot who can't read a man page--a man page that I probably will never write in the first place.
Real work is reading the crap code written by your predecessor, understanding it just enough to change something without breaking everything else, and moving on to the next thing as quickly as possible. No interview has ever tested my ability to read existing code or to alter existing code for a specific goal.
Whiteboard this: "This third-party data grid inexplicably causes all text typed into this column to come out backwards. You have 60 minutes to fix the problem, because code freeze is in four days, test needs at least a week to bang on a release candidate build, we ship at the end of the month, and you have 15 more equally-stupid issues waiting for you." And then you are judged on the quality of your horrendous kludge. Those companies that look for perfect people that write perfect code at work, then go home and keep doing it, are living in Cloudcuckooland.
Right now, my side project is getting the last two achievements in Fallout 4. After that, it will be banging out an entire novel in November. Or maybe it will be making furniture to hold DVDs, with a built-in system to deliver a painful shock whenever someone puts them back out of the correct order (which is sorted first by genre, then alphabetical by series name or title). Or maybe it will be working out a plan to terraform Venus using wormholes. When I leave work, I do whatever I want. I don't want to endlessly prep for an unending parade of stupid tech interviews.
This is a great idea! I would love to have an interview where I was presented with some terrible code and asked how I would refactor. That would be so much more relevant to actual work experience than solving technical puzzles.
> It's funny that the tech industry is so insistent on side projects. I mean - would you hire a marketing person based on their 'side projects' or a corporate lawyer purely based on their pro-bono work?
I guess our field is so enjoyable that many people have side projects. Apparently, some recruiters think it's a good indicator of future success. I wonder if it's the case though. I teach CS and usually, passionate students (those who work on their own projects) are indeed better and spend much more time working on their assignments. But it's not the end of the story. For example, some are only motivated in things that involve coding, are stubborn, or are bad team players! Conversely, there are students who aren't hobbyist programmers but are smart, learn fast and are a joy to work with.
You know what's universally hard? Finding people who are good at their jobs. References don't matter, experience doesn't matter, education doesn't matter. Why not? Because it doesn't say anything about actual skill. What does? Side projects, where you can actually see if a person has skills.
> a corporate lawyer purely based on their pro-bono work?
You hire a corporate lawyer based on their public reputation. For a programmer, that's their github portfolio.
Business are in a unique position to actually judge programmers by their merit, not just hearsay or bullshit references or lies on a resume. Of course companies are going to factor that into their decision!
I think the big misconception is that a side project has to be a prolific open source project. As someone who has interviewed developers, someone who has _anything_ on a GitHub page stands out in the crowd. Even just a folder with a few batch scripts can go a long way.
I use side projects to figure out what aspects of software engineering the candidate seems to enjoy. Do they fiddle with the CSS nonstop to get the margins just right? Are they constantly trying to decrease the memory impact of a function? Does the README read like an appliance manual or a haiku of puns?
Side projects are a strong signal the candidate enjoys this line of work, and ideally I'd want them working on things they would enjoy.
Actually, the greatest predictor of employee success is their IQ, but that's illegal to test. That's why some employers substitute SAT, ACT, ASVAB, etc. scores, since those are abstractions to IQ tests.
In my experience the industry is not at all insistent on side projects; lots of people talk about having them, and the way people talk about them has become weirdly culty in the last five-ish years, but it is entirely one-sided; nobody who is doing the hiring cares at all.
Developers are more akin to musicians or artists than a marketing person. Yes, I do expect musicians to practice their instrument and learn new material in their free time, at least a little bit. A musician who _only_ played during paid gigs and never practiced 1 hour outside of the paid jobs, would never learn anything new. They would forever be stuck with their existing repertoire.
Would you hire a musicians who didn't have recordings of their work and wasn't willing to perform an audition? Would you want to hire a musician who didn't practice new things?
The development landscape changes rapidly. Frameworks come and go. If you want to keep up in the industry, you will most likely have to learn a new language or learn a new framework at some point along the way. If you only code during your 9-5 you are forever stuck with your current skill set and will end up like the people in 2017 who only know COBOL and can't do anything else. Your job options will shrivel and you will not be very marketable.
I think it's fair to consider how passionate a person is about improving their career skills. For programmers, that often consists of side projects. For other professions, it could include going to conferences, taking classes, reading trade publications, etc., all of which would be worth mentioning in an interview.
I don't think it is fair to imply that people who don't have side projects aren't passionate about improving their career skills. I don't have a lot of side projects, and the ones I do have were hastily hacked together out of boredom or convenience and aren't anywhere near the quality I'd want to show to a potential employer, but I do lots of other stuff to improve my skills, like reading books, listening to podcasts, attending conferences, etc. All of these things improve my career skills, but the improvement is primarily demonstrated at work not through a bunch of side projects.
> It's funny that the tech industry is so insistent on side projects.
Are they? I've yet to be asked about it. It might be different for new grads, but what people seem to care about most is if you've worked for a major firm, or in the case of the video game industry, a "AAA title".
This is like a doctor saying "It's funny the medical industry is so insistent on medical licenses. I mean - would you hire a software engineer based on their 'license'...".
It's a very well-known fact that interviewers will often want to see some code.
Because of this, I at one point spent maybe about 15 hours putting together a small project specifically to use as a code sample. This code sample, which again took maybe about 15 hours to put together, served its purpose for years.
To avoid this tiny amount of easy work that has such a high potential upside is, to be frank, just dumb and lazy.
There seems to be a lot of push-back around here on the basis that nobody asks for it/cares/looks at it. I agree that would be annoying if that's your experience. But, speaking as a hiring manager, I can say that I won't even grant you a phone screen without a code sample. And do not be surprised if I ask questions about it (I don't always, but depending upon the nature of the resume and position, I do probably about half the time). I read every sample and assess it for competence, quality of construction, style and...unfortunately these days...whether it was plagiarized.
I just have to know that you can write decent code. I don't want to waste my time or yours if your code in the language we need is not up to a minimum standard. When I have to train a new candidate on a million line code base, I cannot afford to spend time also training them to be competent in the native language of that code base.
This is not about "coding passion" or notches on some Github post...this is about whether you can do the job. Although one advantage to a Github profile is I can look at your repos and see whether you understand the basics of using git as well (yet another requirement of the position).
I, for one, think your 15 hours was well-invested.
Maybe, but if I had spent 15 hours 10 years ago it is doubtful that it would still be relevant or useful now. If I come to the point where I need some code to show for a job that I really want I'll just spend the 15 hours then.
When I vet resumes, I most definitely look at any code their provide, but I don't always ask them about it. If they didn't put it on their resume, I don't specifically ask them about it either because they should have put it on the resume. If you put it on your resume, you can't say for sure they didn't look at it and factor that in when reviewing candidates.
I'm planning to look for a new position in about 6 months and that's what I was thinking to do also. Build a sample application, maybe something useful I wish I had anyway (a very simplistic budgeting app with no external data access/storage was what I was planning on). Maybe even ask my employer if I could take some code of my last projects and re-work it into a semi-independet component.
I think this is a good piece of advice here, no need to call other people dumb and lazy.
> I at one point spent maybe about 15 hours putting together a small project
Inventing a project interesting enough to focus on for 15 hours can be difficult. Just like learning SQL without a dataset.
Inventing a project also isn't likely what you want to be hired for, so it's reasonable to have that low on your priority list.
Free software is constantly filling the gaps that I would want to create a "side-project" to fill. I'm not saying it's particularly difficult to find something to work on, but it certainly isn't trivial.
This is great advice. I would recommend that you do it any time you're trying to get a job so that you have a "fresh" repository but I'll spend 15-20 hours just watching algorithm videos when I'm getting my resume prepped so that I can answer the ridiculous question of how does bubble sort work. No it is not ridiculous to know that but I graduated almost 10 years ago and I only look that up when I encounter a situation that needs sorting and I don't want to use the built in sort functions.
Couldn't agree more. If you can't put in one weekend of hard work to give you a leg up on the competition for something as important as _your career_ you are just being dumb and lazy.
Meh, I agree in general and believe in work/life balance but you don’t need a huge side project.
Just take a few scripts written already, write a readme, and an hour a year per script tuning them up and adding tests. Maybe a code golf problem or two.
In short, if you can’t find four hours a year to put into your career, maybe you just aren’t interested. I think of it as page two of my resume.
Well said. These types of blog posts create the sense of a needless dichotomy where you either code 24 hours a day or 5 hours a day and there's no in-between.
I really don't have much of a github presence, but then again I'm not a day-to-day coder at work. The presence I do have I created in just a couple of hours and I could easily beef it up to something respectable by spending a couple of hours a month on it.
This has to be one of the best comments I've seen on this whole issue. Way too many devs seem to think it's a massive undertaking and they need a giant project. Hiring engineers don't even want to go through 100000 lines of code (they have lives as well!). Even starting by uploading your dot files is something and takes all of 10 minutes (with the added bonus of having them available if you need to switch machines).
I agree with this sentiment. I personally loathe white board coding as it has little in common with day to day work and would much rather discuss some real working code as part of an interview
When I am assigned a code test for a job interview, I publish my solution on github. It's not a side project, but that's code that I wrote that other interviewers can look at. No big deal
I sympathize with this guy. I think the "side projects" issue, like "write some code on the whiteboard plz" is a symptom of the dysfunction in our industry. Specifically, a startling proportion of people purportedly working as programmers cannot in fact perform even basic tasks and don't feel shy about pretending that they can.
A lot of my issues about the weird side project fetish come down to the fact that this is an award for the misaligned. I spent pretty much the first decade of my 'proper' career working on ideas that went into our regex matcher (now at github.com/intel/hyperscan fwiw). During some of the more intense periods I could barely take a shower or daydream without having to grab a notebook and start writing ideas down, many of which went into the product. When I wasn't doing that stuff, I really didn't have any energy left for building anything else. Reading these discussions, I often wondered what would happen if the associated startup (Sensory Networks) had tanked.
This isn't hating on people who do side projects; it's just to say that having the time/energy to do side projects often feels like it results from misalignment with your day job. I was happier than a pig in shit writing regex and literal matcher code (or designing algorithms) at Sensory Networks and I'm still that happy doing new software projects at Intel.
The main dysfunction I see with interviewing is that we’ve abstracted the interview further and further from what you will be doing day to day.
Code on the white board? Why not on a computer? Why not work on some real code for the project? Sign an NDA and work on an actual feature. Try to get closer to what you expect the candidate to do on a daily basis.
I think no one has said it yet, but I believe the diversity you bring with your non-standard hobbies is a very valuable resource. Diversity being missed by people looking "culture fits" of workers who like the same exact things.
For instance the fact that you write novels for fun suggests me you would be able to write good, long documentation or manuals if required. I've known good programmers absolutely incapable of communicating their ideas in writing to other human beings.
Some, when told that they needed to prepare a detailed, well written technical report on the software they are building for a client, looked like if they had received a death sentence.
>I think no one has said it yet, but I believe the diversity you bring with your non-standard hobbies is a very valuable resource. Diversity being missed by people looking "culture fits" of workers who like the same exact things.
Ha ha, good point. I agree, seen it happen more than once. Some people don't feel comfortable with anyone who is in some way different, even regarding likes about (often trivial) things such as tastes in food or music or sports, etc. Insecurity, I call it. Linus (of Charlie Brown / Peanuts comic fame, not Linux) and his security blanket come to mind. Images:
Having a breadth of non-technical knowledge (dare I say, "soft skills") also improves your value as a developer insofar as you may be better positioned to discuss requirements with people, and to understand the reasons why you're developing the things you are (i.e. not "tech for techs sake")
Also, people launching art projects, participating in active art communities, etc. have generally better "people skills" that introverts who prefer to spend the weekend at home doing technical side projects (like me!).
This is a highly valuable work skill for a technical worker if he/she has the need to work with clients, present updates or discuss requirements, much more than having a few small GitHub repos. By focusing in side projects you can be filtering out these skills in your workforce.
Exactly!
My best ideas come through exposure to broad topics of interests, synthesizing knowledge. Implementing approach from a different domain, seeing events in a movie that trigger an idea, reading about the ways living organisms optimise resources, etc. Not to mention social events on any subject when talking to professionals from other domains triggers solution to a long lasting problem. I also recall research on the positive overall benefits of turning our brain off/away/down for a while.
...
Yet I also admit the need for highly specialized work-force too, some stages or activities require narrowly trained carthorsers where a creative mind would be just damaging a realization process.
All depends on the situation.
> Not to mention social events on any subject when talking to professionals from other domains triggers solution to a long lasting problem.
This is becoming more and more important as science/technology keeps getting compartmentalized. Not to go as far as the medical doctor who rediscovered numerical integration [1], but I have the certainty that in my research I'm doing many things in a horribly inefficient way, out of ignorance. Just the other day I learned about k-d trees and sped up a piece of software in my lab by an order of magnitude...
I've always liked essay writing. I mean, not so much as an assignment, but they're satisfying to bring together; from perfecting the construction of individual sentences, to structuring the flow of paragraphs.
To that end, I quite like writing documentation, especially after finishing a large milestone. It's a good break from just coding, while also being very helpful for the team as a whole.
I like to have side projects, but I still don't like to share them. People love to find reasons to reject, and an 18, 11, or 7 year long side project (the age of all my side projects) isn't really a fair representation of how I code today.
Even as someone who enjoys side projects, the prospect of sharing a side project, and being criticized by a potential employer about the contents of it, turns it from "side project" to work.
Have you ever had an interview where you shared your side projects, and they were criticized?
From my experiences on both sides of the hiring game, side projects aren't really criticized in an interview but are rather used as a starting point for a conversation to explore the ways of thinking of the potential employee. "What was on of the most challenging parts about your project?" is probably one of the most common questions there, and I'd guess that long-running side projects (even if they have a lot of inactivity in them) contain challenges like any other project, maybe even more so.
Yes, of course, you can, but my comment was meant to address the concerns of the parent. If you have side projects, you don't have to be afraid that they will criticize and judge you X-Factor style about them.
If the applicant has side projects, it's often easier to talk about them instead of day-job code, since they usually are more passionate about that, and they can talk about it more freely because they don't have to be afraid to (accidentally) spill company secrets. Side projects are not a must and I've had good conversations with applicants about their work projects, though more confidence to talk about them is something that comes with seniority in my experience.
> I like to have side projects, but I still don't like to share them. People love to find reasons to reject
Nowadays you can share anything online (git or other) without fear of rejection, because unless you choose point select individuals to it, in today's deep oceans of "everyone sharing every random little bone they spewed up" it'll immediately drown and stay there forever undetected and unnoticed. Doubly so if you don't fill out repo description or tags.
(There's must be gazillions of solo hackers dumping their sources of the coolest little projects and experiments without any attention, simply because they don't go and spend the day yapping on about it everywhere --- they Just Keep On Hacking.)
The upside of doing so? If a code file that's way below your current skills is indeed many years old, this becomes clearly visible in the repo and there's no need to explain yourself --- if choosing to indeed point someone to your personal for-fun code-bases.
> Even as someone who enjoys side projects, the prospect of sharing a side project, and being criticized by a potential employer about the contents of it, turns it from "side project" to work.
You should be able to take constructive criticism of your work regardless if it's a side project or not.
Why? I strongly doubt any criticism from a potential employer would be any good in the context of hiring.
Almost all of the side projects would have undocumented constraints and requirements on which the design/engineering decisions were based. And I doubt the interviewer would take time to ask for design constraints beforehand and then go through the code enough to understand its design/architecture and have interesting criticisms that would bring something positive for the side project in the future.
You can't criticize design decisions without context. I would not be welcoming to someone criticizing my side projects without first asking for context/design constraints the work was based on.
I would not lash out or whatever. But I would not take the criticism without some sense of other person's care for the side project in question.
That's not the point they're making. What they mean is that if they consider side projects as potential criteria for being hired or not, they'll lose the fun in those side projects.
Because they'll then try to make every part of the code perfect and with complete documentation for everything, probably spending more time trying to present it rather than working on it.
Even if they dive into a corner of your side project from 10 years ago that works, but you realize isn't ideal, and you don't have the time to improve that part of the code?
I, as an employer would like to have a conversation about that and I’d absolutely take “I know this could be better, but it was written years ago and it works” as a perfectly good answer. Software can always be better, requirements change and so do capabilities and styles of the people writing the code. But we cannot rewrite all parts of all our software all the time for the sake of molding it to fit our current vision of perfect. Time is limited. Finding the line between “this is not perfect, but it does the job” and “this really holds us back and needs change” is in my opinion one of the most valuable skills a seasoned programmer can acquire.
> Even if they dive into a corner of your side project from 10 years ago that works, but you realize isn't ideal, and you don't have the time to improve that part of the code?
Yes, you basically answered the question your self. Tell the interviewer that you wrote that code ten years ago and while it works it's less then ideal, then explain why its not ideal and what a better solution would be.
The conversation where you explain what's not ideal and what you would improve based on what you've learned since is why I would want to talk about your side project in the first place. If you said your side project was perfect and couldn't be improved, that would be a major red flag!
He hadn't said he is afraid of constructive criticism. He said he is afraid someone will hold something in it against him. The two are profoundly different.
Here's what I've done for something like this - a few days before I was set to do rounds of interviews, I took a couple hours for each of my old side projects to comment what I would have done differently in my code. It's much easier to do and it gives the employers a dive into your current thinking when it comes to development.
As an example, check the source on my homepage: http://jjcm.org
This was neat. It also seems like a good way to show how you might discuss your work and others work, as well as your sense of humor. It almost felt like reading one of those "the annotated source code of X" sites. How many of these side projects have you done this for?
I did it for two other side projects. A simple connect four game that I made right when I was learning javascript and an old handlebars.js site I made. I got a lot of positive feedback regarding it from interviews though. Seemed like it worked well.
Also, keep in mind that some people can't share side projects or even work on them because their employers lay claim to all code they create, even on their free time.
> I ran 50+ miles a week. I pushed myself to excel. To excel within the boundaries of the time and life-balance I had set for myself.
Part of excelling at your job is learning new stuff - something that I am absolutely certain you do all the time, even if you only do it during work hours. Maybe this week you are starting a new project and need to learn Vue.
Publish those 100 lines of code to GitHub. Just like that you've demonstrated that:
* You are willing to learn new things.
* You know how to use a little Vue.
* You know how to use a little Git.
Make it clear that it's a learning project - call it "Learning Vue," "Learning C#," "Learning Node" etc. When a hiring manager looks at your profile they will see dozens of technologies that you have at least some experience with.
Edit: if they turn around and demand side projects; you would be completely correct to ask about how many office hours they allocate to side projects. Interviews are a two-way process and the more you stick your neck out, the more you get noticed.
Better check your employment agreement. My company owns what I write on company time, I don't have the rights to just "put it on GitHub", and yes, I take that seriously.
Ditto. At my current place my employment agreement doesn't allow me to publicly post code I write in spare time.
My previous employer was a defense contractor, so... yea.
I don't have any side projects that I can share. Sucks, but that's the reality. If I get fired/quit and can't find a job without side projects, I have a list of things in my head to build in ~months if that's what becomes necessary.
You shouldn't put _actual_ work code you wrote on GitHub, but you should write your own small sample programs that demonstrate you know how to use a certain library that you just learned, and then you have it as reference code for yourself later and it shows you know a specific technology.
100 lines of code is not a meaningful amount of experience with anything, and surely cannot provide any meaningful advantage over the lifetime of a serious project compared to another developer who starts fresh.
Having "dozens of technologies" at this level of experience is often a bad sign. Very frequently candidates who mention lots of technologies like this on their resume or github can't answer the simplest questions about them, even "why should I use this, what problem does it solve". Source: Years of interviewing people with a laundry list of technologies on their resumes.
Should people be expected to remember everything about all tools they've ever used? No! Is trivial experience with something useful? Probably not.
This kind of thinking is why most of my "side" projects aren't on Github. Sometimes a new algorithm or technology I hear about peaks my interest, and I spend a few hours playing with it. But in the end, I don't have something I would be proud to show or that properly showcases my skills, and so I don't want people extrapolating from that.
Then again, I don't claim to be an expert in these skills, and don't put them on my resume, which seems to be more what you are referring to.
100 lines of code is far, far better than zero, and this thus quite meaningful. Mathematicians can write proofs shorter than that and demonstrate mastery of their craft, and programmers can demonstrate basic competencies the same way.
Sounds like you weren't a fit for that company asking you for some code. And that might be a blessing in disguise for you. If you are a decent developer in Austin, you probably have lots of opportunities, so no need working for a company with those kind of requirements.
Just know that as a company in Austin, they have lots of employees to choose from probably too and this is their narrowing approach. No biggie, y'all aren't a fit. Just know that this becomes circular, because many of the types of companies that ask for this also allow you to open source some of your work-hour code which helps that visible resume.
Also, if you are in demand and have leverage, consider trying to work at places that encourage making at least some of your work visible to the world. Many other professions benefit from this. If you don't have leverage, I'm afraid you may be stuck in an endless loop of invisible, hard work you leave behind.
I really enjoyed this post. I feel the same way, I do love coding and working on software projects doesn't feel like work to me. I spent my high school years and college years(and I graduated years after I should have from taking two years off after freshmen year) working fast food and grocery stores. I know what work feels like.
However, I don't and won't spend every waking hour I have doing one thing. This life has so much to offer and experience, I do not have a drive to spend 80 hours, nights and weekends like that. However, if the project calls for it every once in a while, fine, it's not a big deal until the company comes to expect that.
It’s a bit crazy that the tech industry has grown to demand employees that live for their job and not much else. Maybe it has to do with the high income (when compared to loads of other jobs) and the fact that the world changes so fast that companies rely on employees that keep on educating themselves.
> However, I don't and won't spend every waking hour I have doing one thing
Why does everyone think that it requires every spare second you have to write a couple programs and post them on GitHub? Can you spare 1 hour per week? Why would it require every waking hour you have to write a couple scripts and throw them in GitHub?
Some "programmers" are just not good at programming. Actually, that is a vast majority of them. This is why they think it's so hard to have a side project, and it's the same reason companies that actually care about who they hire have to do 20 interviews to find 1 viable candidate.
There are plenty of new people entering the workforce, too. I can't remember the last time I took an Uber/Lyft where the driver wasn't in a coding bootcamp. It scares me just to think about having to be the engineer "training" the new hire at a company that didn't make its interviews hard enough.
(As a corollary, this means that if the engineering interview at a company is objectively easy, that's a RED FLAG, and you should not work there.)
I often feel like there's a silent expectation that you should enjoy certain things if you're a good software developer. Here are some of these things that I definitely don't enjoy:
- Side projects
- Developer conferences
- Meetups
- Hackathons/hack-days
- Tech podcasts
- T-shirts/stickers for frameworks and technologies
I do enjoy software development though, and from what people tell me I'm pretty good at it, so I don't think it's necessary to enjoy these things to get a decent job. It does concern me when I feel like I'm the only one who didn't stay up late to watch the Google I/O streams live (I'm based in Australia)
How would you go about putting a personal side project up on github if you are stuck with an employment contract that says your employer owns all your intellectual output, even that which you produce on your own time? Yes, I realize that stipulation is there for general protection of the employer and not typically intended to be used in a draconian way, however it still leaves the door open for you to get sued into oblivion for posting proprietary code that "belongs to your employer" (even if they've never seen the code before).
I had a side project that I wanted to make into a side business. I worked with my employer to write up a doc that said they'd have no claim on it and would let me own it. My employer did have the "we own everything you make" in my contract.
One alternative I've thought about, is how can you negotiate your way out of that clause when you start a job (seeing as how it is slipped into the paperwork you have to sign on the first day, too late to not take the job if you've already quit your previous one).
I wonder how most employers would react to a request to have an attorney look it over, and use the excuse that you want to make sure it doesn't interfere with any non-profit volunteer work you do.
They fired him for just asking? Then they're horrible, and he's better off far away from them. Most employers are not actually cartoon villains and will be reasonable.
He may be better off in the long term, but short term unexpected unemployment hurts. Can hurt long term too, since you will have to take whatever job you can get as soon as possible (unless you have enough savings). And that job you get may not be at the same point as you were in your career progression, since many employers prefer to hire someone who is already working.
If I remember the phrasing correctly from a fortune 50 company I worked at (during the dot com boom):
Any inventions, innovations, or ideas, conceived solely by you or jointly with others, whether or not using any company resources, at any time during the course of your employment, will be owned by the company.
Agree. I've been in tech as a developer, dba, sysadmin, architect, all of the above, etc. for more than two decades, and I don't even have a personal github account. I don't write code at home.
My open source projects have gotten me all but 1 of my last 4 jobs. Hands down.
Yes, I still had to pass the interview, but when you can claim that your NPM package ballooned to a million monthly downloads suddenly the conversation changes from writing code to architecture, product management, and leadership.
Essentially you are telling the guy on the other side of the desk that I can solve problems nobody else in the world is capable of solving (or willing to try) and here is my proof. The clear response from that guy on the other side of the desk is to refocus on the things involved with that level of effort/output.
I have never had to worry about competition from other candidates. It has nothing to do with what I think of myself (ego or arrogance) and everything to do with how they perceive the potential I could deliver back to the company.
Second and third order consequences of this, that nobody but the interviewer sees, is that you won't need your hands held like a child. You don't need all the popular abstractions, frameworks, and mountains of tooling that other candidates cannot live without. The reason for this bias, and it took me a while to see it, is that you are spending all that extra time outside the office solving many of the same problems as people at the office except that you are doing it without a financial incentive, greater time constraints, fewer resources, and often in a more portable way.
---
Now let's look at the candidate who only works at the office and has no open source projects to demonstrate and they are competing against somebody like me who would rather be working on open source for free than doing the job they are (well) paid to perform. What does the interview have to ask that guy to assess their skills?
It isn't about the code that is on Github. Nobody has time to scrutinize that. It is about the product, product quality, market penetration, the kinds of problems you have solved. It is about how you achieve popularity where other people did not and with a budget of 0 (maybe spending on a web server). But since you don't write open source and don't do work outside the office this conversation never arrises. The interviewer is limited to asking you about how to write code like you are a newb.
This comment really rubs me the wrong way. Realistically there are maybe, what, a couple hundred "million plus" downloaded npm packages, that are useful per language. That would almost seem generous. Now compare that to the number of programmers.
What you are essentially saying is that it would be a reasonable expectation to only get a job as a software engineer if you are the absolutely in the top .0001% of programmers in the world. Which, sure, I'm glad you're successful, that's nice. And as advice for one individual it's good - showing good work is a positive indicator for an employer. But in the aggregate we can't ALL be the best.
I went to school because I had thought that my chances of making a stable living were higher than playing basketball and praying that I would make it into the NBA.
You are correct that everybody can't get a first place trophy, or else it isn't really a first place trophy. We cannot all be the best.
That doesn't really matter though. In most cases you aren't competing with the rest of the world for a job. Typically you are competing against other applicants. In this more common scenario you just have to be better than the applicant pool, which is far less lofty (not that it matters). If there are 30 people that applied for an open position we can probably assume that between a third to a half are probably less qualified than the interviewers hoped for, so then you are realistically just competing against the remaining candidates that which is a lower number still.
In my original comment I mentioned my open source projects got me all but 1 of my last four jobs. The first of those occurred well before my software was popular and the company didn't even realize they were using it until it went up broken to NPM and broke their build. That madness didn't happen until after they interviewed me. During the interview I showed off my open source software just to demonstrate where I put my interests and how I am making effort to increase my personal productivity and solve original problems.
The software only became super popular during the prior employment.
---
On a different note I don't consider myself something special like a 0.0000000000001% programmer or anything like that. The popularity of open source software projects is a unique spiral death trap. Keep in mind you are doing this on borrowed time at personal expense and for years people will ignore you (or tell you that your software is garbage and that you are completely wrong) and use inferior products that have a more familiar brand name.
Your software becomes popular if you can solve original problems and refocus continual effort on product quality. It took me years of effort and lots of people telling me I was wrong. I just did my own thing anyways and kept doing it because it was a personal project that worked well for me. And eventually it works for a couple of other people. It is extremely rare, but there are people who like to experiment using unknown software just for the hell of it (or simply because it is free). Those people create word of mouth recommendations. Rain drops become a trickle and if the rain never stops on a long enough timeline it becomes a flood.
It is a death cycle because as more people use it the demands upon the product greatly increase. Your available time does not scale proportionately. You prioritize and do what you can. You can mitigate some of this, though, if you are able to close defects at the speed of light and can get to a point where maintenance and improvements are faster enough to allow deeper engagement with your users.
The attention is nice and the idea of breaking promises or letting people down crushes my soul. That is how I feel about unfulfilled enhancement requests even though it is completely irrational. Completing those efforts are what made the software popular, so you feel a need to not let people down and to continue to complete the requests.
Seriously now, how many hours does it take to start a simple project in a technology you're familiar with? I get it, you want time for your hobbies and programming might not be one of them. However if getting a job is important to you, is it so hard to spend some hours writing a piece of software that's maybe related to your hobbies?
> The silly art project that I launched in Austin. My dog business. Running, painting, writing.
Take any of these hobbies and write a small application related to it. Don't do it because "code speaks to you", do it because it's important to get a job. Do one application, spend some hours on it, and be done with it.
> It's important to me that these attributes be valued by my workplace.
I don't think that's reasonable. I have many great people at my workplace, some of them have become good friends. But really nobody gives a damn I do 3D modeling in my spare time and I don't see how that would make things better. People know I enjoy designing visual stuff, and they always come to me for advice on colors and UIs, but that's about it. And my design hobby is valued because it brings value to the team and the project.
Interviewing is a contest. Some people prepare more than others. Some learn body language, some study the company before interviewing, others prepare side projects to show. If you're unwilling to do anything that puts you one step ahead of the crowd, don't complain about the interviewing process. It's a game. Within reason optimize for success. Don't just complain about how unfair it is.
This is basically the sentiment that I share. If you aren't willing to put in a couple hours on one Saturday of your life to putting up one script in an effort to help your career, you probably don't care enough about the job you are applying for.
> you probably don't care enough about the job you are applying for.
It's not even about th particular job you're applying for. Is having a job in general. If it's important for you to have a any job, then surely you can do something to help yourself.
Getting hired is a game. People that have side projects usually have a leg up in that game. Whether they actually should is debatable. It's probably bad to correlate side projects with better employees. But since this is the game we have to deal with, it can help to have a side project and maybe a blog.
When it comes to open source on GitHub, what most people miss is that you don't necessarily need to do it in your free time. This is in general a misconception.
There are actually two scenarios which don't involve coding in your free time:
1. As software developers we are generating by-products all the time. And the trained eye can recognize reusable scripts that can be packaged and placed on GitHub. If you don't have a GitHub account with such by-products, then you probably have rotting folders on your hard drive with reusable stuff that will eventually wither away.
Good companies encourage or at least tolerate employees that do this, because it leads to higher quality code (by putting it out there, preparing it for the scrutiny of others), because it's good marketing for reaching job candidates and because once in a while such a projects ends up having other users, which end up contributing feedback, bug fixes or even features, aka work for free.
2. We end up using a lot of open-source libraries and tools and we don't have the resources to pay for support for all of them, plus if we are honest about it, we are cheap bastards in terms of wanting to pay other people money for the tools we depend on.
Open-source is a about having control. Does it have a bug, or a feature missing? You can code it yourself and send a PR. Which in many cases is quite easy if you've been working with the library or tool in question for a longer time — all it takes is for you to know what's needed.
As a software developer, you might work in an industry that doesn't benefit much from open-source, or in a company that doesn't allow such contributions.
Which is fine, but know that in many companies the people that have public projects to show the world will get picked over those that don't. It's simple market economics really — in absence of open source contributions, all you have to show for your work at that cool startup is a nice story of how it died or went sour. And some ranty blog posts.
Good for you, I’m jealous I guess. I am constantly developing and learning on my free time, and it’s a problem really. It consumes me often, tires me out over time. What do I have to show for it? Not much of real essence. I should probably focus on projects non computer related. If I only had all the time in the world
From what I have seen, most developers aren't working on anything particularly interesting in their day jobs. At best they are developing a new CRUD application using the latest framework, but at worst they are maintaining legacy codebases, battling management incompetence etc. It can be very hard to sound passionate about these things in an interview. In my view this is where side projects come in - they're the chance to do something actually interesting, which can be a great talking point in an interview.
I wouldn’t hire a sales guy that sells comparable products in his own time. Why would that be different for programmers?
You should only do sideprojects if it’s your passion or if you think it will help your career. If you’re passionate about other things: do that instead. There’s more to life than work.
There are a lot of things being conflated in this post.
Side projects
Geography
Running a side business
1) I agree side projects do not define a good developer (frankly, I don’t have any outside toy ones). But given 2 equally good choices, I can’t blame an employer who chooses a Dev with side projects as opposed to one without (since they can see their code). That being said, a better interview process would involve real coding which would eliminate this situation altogether.
2) I’m not sure where the rant about geography fits in. If you are limiting yourself to Austin you’re limiting yourself to an even smaller pool of developers than the Bay Area, NYC is Seattle. And there are many families with dogs living in all these areas.
3) Is suspect the fact that the author is running a side business may be a bigger concern. The author’s specific business may not, but as an employer, I’d imagine there is no way my job could compete with your side business since you actually have money invested in. I wouldn’t be surprised if this would, more than the lack of side projects, affect someone’s employment opportunities.
Just the way the author has setup the discussion it seems they basically left the company with no code to see at all.
I can’t show you the coding I have done, because it’s at work.
I can’t show you any other coding I have done because I have not done anything outside work.
But I did start an art project once.
I think a far more useful tack (which I have used in the past) is to ask the company to provide you with a task, and give you a week to solve it. This allows them to actually see that I can code and solve a problem.
Honest question: do you use open source at work? Do you contribute to open source while at work? If not, why not?
A couple days ago I spent several hours puzzling through how to use an open source library. When I figured it out, I made a PR for documentation. Our closed-source app will benefit from having its dependencies better documented.
I do very little coding outside of work anymore, but I still have public contributions to show.
Many employers take the stance that they own all the code you write while at work, and therefore you don't have the right to release it under an open-source license.
Proper response: "OK, so I found a problem with one of the open source tools we use and I know how to fix it. Do you want me to 1) not fix it, in which case our code is broken, 2) put a workaround in our codebase, which you'll have to maintain forever 3) create a fork of the codebase which you'll have to maintain forever, including merging upstream changes, or else forego future bugfixes and improvements or 4) contribute the fix back to the original project on company time, which means you'll never have to pay to maintain that code?"
A docs PR probably wouldn't satisfy this type of interviewer's curiosity. A code contribution large enough to be useful to an interviewer would likely require enough employer time that it'd be harder to sell your average employer on allowing you to open source it and/or contribute back.
"And when I said I have no side projects to show, what they heard - what interviewers hear - is: I am not the best. I am not a passionate developer. I don't spend the necessary time to keep on top of my education and skills. That development is "just a job." "
Are you sure you are not just projecting your own insecurities and opinions into interviewers? Majority of developers don't have side projects. According to FOSS survey, owerwhelming majority of linux (especially) and open source contributions is paid work. Sometimes it is that they work so much in day job, most of the time they work normally (which is enough) and do other things in out of work time (exercise, care about children, read books, socialize - social skill matters, craft). If you are coding 6 hours a day (generous 2 hours for meetings and chatting and organizing), then you should code plenty.
You could have loose that interview due to many other reasons, you could have run into that one company that does not hire without outside code.
But if you really worry about this one, maybe create an account with sample project and be open about that project purpose (e.g. dont be afraid to say that you created this project to show how I code, because previous interviewers asked for that). If it is really about code sample, then something you create withing two days should suffice.
And if they demand real contributions to real open source projects, ask them whether their company gives employees time to do such a thing on the clock. After all, they expect your previous employers to be so generous with time, so they should put money where their mouths are. If you dont hire me without having full public profile, it is only fair to demand that being employed by you makes continuing that work possible.
This really resonated with me. I am passionate, or at least I think so. But all my subprojects are for work. I work at a place where the problems are interesting, and we are encouraged to randomly skunk works things in the background. So I do.
None of those things are things that I can give out or show to anyone at all. I'm really interested in the field my company works in, and all my side projects are related to it, at least elliptically.
The only thing I can show you after 35 years are things like abandon shareware products from the late 80s and some really awful code written for no purpose long ago. Nothing that relates it all to what I've done for the last 20 years.
I also work in one of those companies that asks applicants to do some code problems and turn them in. On the other hand we really don't care how you solve them or even if you solve them. What we want to do is get in a group setting with the applicant and the code and four or five of us and talk through the code. The problems tend to be simple, the interesting part is talking to to a candidate and getting a sense of how they code/think.
The bottom line is, each developer is responsible for showcasing their own skill. One of the best ways to do that is through sharing programs you've written on GitHub. If you don't want to do that, you better find some other way to show off to an employer.
If you are unwilling or don't have time to create a public code repo or your own blog/website, you should be willing to take a skill assessment test from the employer. If you aren't willing to do any of that, I don't know how you can expect an employer to gauge your skill. You can't just provide a reference and expect them to hire you just because someone vouches for you.
You may think it's unfair that you have to go out of your way to make yourself look good to an employer but...that's the way the world works. I think the misconception is that people think 'having a side project' means writing a prolific open source project. You can spend 1 hour per week on coding small programs and have a great GitHub profile.
What if you work 16 hours a day because your current employer is highly dysfunctional and you are constantly putting in hail mary efforts to save them from themselves?
How is one supposed to have time for side projects then?
Most sane folks would like to find another job to quit into rather than just leave their job, but if you have a great financial cushion to rest on, sure, go ahead.
Having been poor most of my life and worked full-time since I was 15 years old (with an odd break or two), I can tell you that that is a luxury most people do not have.
Don't quit a job until you have another -- and actually being currently employed is like free bonus points when interviewing.
Have you heard the expression work smarter not harder? You're working 16 hour days likely for the income of a regular 8 hour day -- so you're literally making half the salary you think you are. That's not smart.
Some crunch time is normal and if you're lucky, compensated for. If I'm working all out weekends to finish a project (might happen this month for me) then damn straight I'm taking some days off in lieu for that when things calm down. If it never ends, that's not crunch time.
OK. That's fine. I have friends that will spend a month committing code on github everyday for the sole purpose to having greens on the page. It does help to get an interview because most often then not, all the employer sees is the green. No one is gonna go ahead and read the code. And if they do, what are they going to get out of it?
I've seen people fake it, adding trivial changes everyday, uploading public tutorials they followed, or just formatting.
I never ask for a github page myself because I don't know what to do with the information. But I do ask for a side project, and answering yes or no is not what makes or breaks a candidate. Instead it leads to a conversation about their coding and work philosophy.
If you don't have a side project to show for, well you must have something to talk about in our field that can convince someone that you are a good candidate.
If you do have one, well it has to be something that can convince someone that you are a good candidate.
My way of getting better was always to read about things around the subject I wanted to learn or understand. In my case Design.
I always look for how things are the same compared to the subject matter I am interested in.
What has given me the most ever is learning to play music and compose music. Once you understand how music work you understand how/why rhythm works, proportion, harmony, consistency etc.
But both music and design informed my cooking. When you boil things down (no pun intended) the underlying principles are all the same it's only the execution of those principles that's different. Philosophy is also something I have found ways to incorporate into something tangible in my life.
I also have side projects some of them do really well but i try to do as many different things in my life while still being involved with design and music. You need to have some strongholds.
What strikes me as weird about this is the assumption that it's an either/or proposition.
I am passionate about playing traditional dance music. And I have supported this by writing a program to generate high quality sheet music from ABC scores; scripts to download collections of scores or MP3s off the web; scripts to handle tagging/naming my MP3 files; etc.
I am passionate about RPGs. Back in the day I supported this with a script to convert a simple text markup to LaTeX to generate print quality copies of my RPG stories. (This was about a decade before Markdown.)
Etc. The idea that a programmer could have an entire second business and not write any interesting code in the process strikes me as really odd. There are NO tasks for the company that could be usefully automated?
> The idea that a programmer could have an entire second business and not write any interesting code in the process strikes me as really odd. There are NO tasks for the company that could be usefully automated?
He runs a dog business. Probably best using pen and paper... or microsoft office... definitely not custom code.
I don't know, man... My girlfriend is a psychologist and I built a small Python program to generate reports using python-docx based on input from standard tests. It was a small project that took me 2 months and was pretty fun (and I work with support, not development). My point being: one can find neat problems to solve anywhere, spend a few weeks, have fun and end up with something to show.
Having a second business is normally not allowed without permission. If its not related most employers might be ok.
Like a PM I knew at BT who had a side gig as a violinist - one year his band had a residency during the Edinburgh festival (at the balmoral no less ) - if it had been a job related to huis day job no way would have he been allowed
Code quality is overrated in a side project. As developers we love to inflate this fantasy that someone else is actually judging our line-to-line code.
Unless you're incompetent and making glaring mistakes, someone reviewing your code would have to credentialize in your codebase to identify things like bad architecture. Nobody is doing that.
I'd put your energy into polishing a quality README. That's actually something that someone else will see, and I'd assert that it's the most important part of a project for someone flipping through.
In fact, in the hiring position, when I see someone with projects but not a single README, I have to wonder if it's a bad signal. Sure, they could do the easy part of slapping code against the wall, but they stopped before the hard part of documenting/introducing it. Something to think about when you're competing with other applicants for a job.
Except, this isn't true. I've been on both sides of the table where less that stellar code has been on github and on both sides: it's more important it was there than the imperfections present in it.
I've come across places that wouldn't consider scripts and such to be "side projects". They expect something much larger to be of any consequence. And they want it to be somewhat relevant to the work they do.
I often laugh at people who use passionate not realizing the root of the word more or less means suffering. You want me to suffer for your company? No thanks, thats beyond the bounds of employment imo.
Indeed! I always cringe every time I hear the word in our industry. I suspect (and hope) that most who say it are really meaning committed/dedicated to their work (and no, not in a committed/dedicated as code for sacrificing work/life balance). My belief is that most companies (excluding startups) should prefer dispassionate people. Why? Because it's too easy for the passionate to be emotionally attached to things (language, stack, framework, methodology), to where it can interfere with objectivity. I've worked with guys who would threaten to quit (and one Perl who did quit) if $favorite-language was not going to be used in the future.
The other worrisome thing about the passionate is that they're more likely to burn out.
What's wrong in our industry about being non-passionate? I don't get it.
Given the choice between someone who's just doing the job to get paid, vs someone who's doing the job because it's what they enjoy doing, I'll pick the second guy every time.
I like to write side code projects. You might think I do not have a life outside coding, but I do. I do not spend more than 3 to 4 hours per week on side projects. I play the guitar and saxophone. I go out in the weekends. I love mountain climbing. Like the author, "I loathe hackathons" too. But unlike the author, I do have side projects.
As someone who has been doing personal as well as public side projects for possibly 20 years now, I think I can share some insights about why I (and perhaps people like me) work on side projects.
I grew up in a time when we had computers with 3 MB of memory and 300 MB of hard disk were considered powerful machines in my school. The students would get only 30 minutes of computer time per week. These were times when you boot your computer, type GWBASIC, press <ENTER>, and start coding. This was one of the very few ways to use a computer meaningfully. Writing code in GW-BASIC became like a mindsport for some of us. I would write tiny games, draw diagrams or solve math equations with code. It became a hobby.
I guess everyone has hobbies. I have some too. Coding is one of them. It's not the only one.
About 10 years later, I learnt that this hobby could become a career and I chose programming and developing software as my career. Is it fair to now be considered a "human machine" who "work 80 hour weeks" and have "absolutely no evening or weekend plans" just because my career also happens to be one of my hobbies?!
Here are the sentiments that I took away from this article, even if it was not the intention.
- “If I don’t have the time to be THE BEST, I won’t bother even trying to be great.”
- “I am okay, even proud to be a mediocre developer. I don’t want to commit lots of time to programming.”
- “I would rather have an employer who accepts me for being mediocre because I have interesting things going on in my life.”
- “I’d rather work on a team full of mediocre devs as long as the company had a great culture”
I’m not saying it is an “incorrect” attitude. Someone may want to put together a team of developers who don’t really care about their craft, as long as they like to hang out together. I feel very differently though. I would much rather hire a developer who is mediocre but wants to get better than a mediocre developer who has the attitude of ‘I don’t want to put in all that time to be good at my craft. Did I mention I had a dog business though?’
As someone who has interviewed developers, I can tell you that most candidates do not have side projects. If you have side projects, it is a huge bonus. Not having side projects is not a big deal. Plenty of people get hired who don’t have side projects.
But, if a candidate said no they don’t have any side projects, and then followed it up with something like ‘Yeah, I’m not one of those people who really likes coding enough to do any in my free time, plus I care more about my dog business that I run’ that says to me 'I don’t really care about this job."
I'm personally in line with the OP where I don't have any fully formed side projects that I would feel very comfortable as a reflection of my current ability. I really like stackoverflow for this exact issue. Spending time with family is just more important than coding, but I'm able to easily/quickly contribute to stack overflow during work or in the off time. If someone is interested in seeing examples of how I think, help or code I can say, look at the 1000 answers on stackoverflow :p
I always prefer being able to look at someone's work. I'm an adult - I don't expect to see that for someone coming out of defense or certain other industries. But, I will be clear: I want to see your work, and whiteboarding is kind of awful. So is coderpad. Take home projects are nasty because of time commitments and time pressures. How do I solve this problem?
For my sake as an interviewer, I need as much information about you as possible, as realistic as possible, as fast as possible.
For my sake as an interviewEE, github gives me the ability to do good work, on time of my choosing, and present it in the manner I see fit.
As a social awareness question, I prefer to work with people that have the social awareness of the broader software community to go, "yeah, this is how the community is rolling, I can play the game a bit". Whether that's github, or Haskell, or Rust, or assembly, or retro Pascal. I sort of don't care. The social cues matter a lot in The Work.
At the end of the day, passing on someone with no portfolio and a preference for doing art over spending time learning a bit more about a topic and doing a quick demo project is an easy pass.
(Personal note: if you're gonna just throw your novels out, maybe write code instead? worst case is you learn something fun)
I feel conflicted about the side projects thing. Yes, you shouldn't absolutely have to have some to be considered for a job.
But on the other hand, I look at my wife (who is a special ed teacher). She makes a fraction of what I do but to keep her certificate, she has to take for credit college classes, submit them to the state, etc.
This is ostensibly to prove that she can still do what her degree says she can do.
Most other lines of professional work have some form of continuing education requirement.
And that's what I look at side projects like: some form of public effort at trying to improve your skills, show that you can do what you say, etc.
Comparatively, side projects [1] feel incredibly egalitarian. They don't care what school you went to, they don't require much in the way of cash payouts to get going. They author seems to disdain Github, but they'll give you a free account and let you push code to it.
1 - I think we'd need to collectively define what this term means. But I think of it as bit size projects that scratch a particular itch. The author likes dogs? Great spend $1 and use AWS Rekognition to do image search over a bunch of dogs. They have kids? Work with them to put together a little project you do together. You like working at the art collective - GREAT! - do an awesome online art thing.
This is simple. It's Economics 101: Supply and Demand.
1. You work hard to improve yourself and gain more skills that people will want to hire you for.
2. More people will want to hire you
3. Demand goes up, while supply (yourself) is fixed.
4. Your price goes up.
On the other hand, if you care so much about your "life quality" and put absolutely 0 effort to improve yourself outside of work,
1. You don't have much to show other than what you did at current work
2. You are making yourself completely dependent on the company
3. When the company fires you, you have NOTHING to show to others. It's not like you can show people the code you wrote while you were at the previous company (the company owns the code and you're not supposed to share it outside publicly)
4. Since you have nothing to share, less people will get your value and less people will want to hire you
5. Demand goes down, supply fixed.
6. Your price goes down.
You can keep bitching about how the world is unfair and harsh and write some blog post that sounds almost like a beautiful piece of poetry, but that won't change anything, because that's how the world works.
It's not about companies "exploiting" employees by telling the m to work on something during the weekends. It's actually for yourself. If you don't believe that, that's fine, but you will stay a shitty developer and the law of supply and demand will kick in.
Yep, pretty much this. If the interviewer didn't think a person who had side projects was waiting in line behind you for the next interview slot, they wouldn't have passed.
I tend to be skeptical of most forms of software engineering interview tactics, but work samples is not one of them. Strong side projects is a strong indicator of skill. FWIW, for those who do not have projects like the OP, its important IMHO to offer a take-home variety. If you do not have side projects, and are not willing to do a few hours of take home work, then I usually screen you out since there are plenty of other candidates that fit in either bucket and will be easier to make an informed hiring decision about.
A strong work sample is an unnecessary but largely sufficient condition for assessing hands-on-keyboard coding skills (a subset of the skills needed to be a good software engineer), so screening out people who don't have them, when there is a glut of supply of skilled labor, as it might be in Austin, is a rational strategy.
Hmm, I suspect I'd have the opposite problem if I were to go interviewing again. As I teach students, there's an awful lot of whipped-together-in-an-hour demos on there from answering student questions by writing tiny non-meticulous examples.
To be honest, though, I've tended to find interviews go well when the interviewer goes off-piste. Probably because you've both decided your each reasonably smart, and are letting the conversation go where it leads.
You have to look at side projects as helping to build you up in ways that are not explicitly paid for. This isn’t limited to software. Consider physical labor; if it’s someone’s job to do lots of work that requires massive strength and endurance, is there ANY employer that will pay you extra for the time you’d be spending at the gym to meet the required strength? No; they’ll simply ignore the person demanding that investment, and hire the person that already fits their needs. School is another example of something you work hard on without really being paid.
On the flipside, I do hope that employers are good at actually understanding open-source project pages. For instance, GitHub is terrible about letting people create profiles with prominently-displayed forks of dozens of projects as if they’re contributing when those people may actually have done nothing on any of the projects they’ve displayed. Similarly, having a single project should not be an indication that you’re worse than someone with 10 projects; there are some legitimately huge problems and “one project” might be a full-time job in itself.
Some of the best most useful skills I've learned I've learned making side projects using technology that I wouldn't dare try to introduce at work. (too new / bleeding edge / untested)
With that said, I don't make any of those projects public since they embarrass me. No unit tests typically, poor documentation, etc.
With that said as a hiring manager I would never penalize someone for not having open source projects.
Having recently endured a few horrific interview processes, I considered writing an article titled, “No, I Won’t Run Your Fake Work Gauntlet.”
Take home assignments, coding as performance art, timed puzzle solving, obscure technical questions, full day interview gauntlets—these are what I had been through. These processes are designed primarily to avoid false positives. False negatives are okay. This is unfair to the candidate, but the company gets to pick the tune. Rather the candidate _lets_ the company pick the tune.
About a month ago I landed a job. The interview process consisted of two steps: an hour phone screen with the CTO followed by an on-site show-and-tell of a side project of my choice. (Coincidentally, the company is in downtown Austin, but is definitely not the company mentioned in the article.)
The process was a joy to me. I have side projects to show. In fact, I showed two. The audience was approximately 10 developers. My impression is that the CTO was looking for a lot of thumb to go up.
Here’s what I liked about it. First, it was not a time suck. Second, it made me the driver, allowing me to draw attention to the best parts, not just of my code, but of how I think about problems. It was downright relaxing.
To be sure, this is just a different way to prevent false positives at the cost of false negatives. If you don’t have side projects but consider yourself a great developer I can understand why you would consider this process unfair. It sucks to be a false negative. But for me, it’s way better than the alternative.
Not every company needs to draw from every talent pool. I’ve happily taken myself out of the pool of companies which use those other methods. I’m glad there are some which use a method that suits me.
I agree that it shouldn't cost you a job if you don't have side projects. It shouldn't guarantee you a job if you do—like any other demonstration of who you are, it should cut both ways. I always ask to see them if someone has them, and it's hurt in about as many cases as it has helped. If you can't program but have some side projects up on github anyway, I will be able to tell.
It's not that you must do side projects or else there is no possible way you are a great software developer. It's that lots of people are just as good as you are and also do side projects. Given the choice, why would you choose someone who is equally skilled but is less interested in the field?
When you are hiring people, you really have insufficient information to know how good they are. You can't see any larger projects they have done or get a feel for how they solve problems that aren't toy scenarios by a whiteboard. Having side projects too look at dramatically reduces the uncertainty in your estimation of their skill level.
So there you go, all else being equal of course you want someone who is 'more into' their field, and all else being equal side projects dramatically improve your confidence in their skill level. So to a competent hiring manager the author of this looks like he has less passion than his competition, and even his skill level is very poorly understood in comparison.
I'll take a look from both sides. But let me first explain the motivation and drives for some people to push them what they do, why they do etc.
We all have secret reward mechanism which triggers our dopamine receptors. Time to time randomly or intentionally we create those circuits in our brain. For example, for some people, it's really important to talk about baseball teams some likes football.
That's being said, we need to be in the flow also to self-transcendence (remember Maslow's pyramid last step ;)
Some people their motivations are not clear and they find themselves very in the middle of everything and it can be more then one specific skill like the guy's example in the blog post, he likes tracking, drawing, spending time with family etc.
After having a motivation towards one subject for long time you develop flow and being in the zone for this occupation that's why managers tend to see person with enthusiasm for coding and being in front of computers all the time.
It's exactly how it supposed to be! I recommend being stoic about it.
I had a difficulty getting an appropriate role because I am bad at answering Q&A format of questions. I have a decent github profile and side-projects (the recent one is halfchess.com). So I am coming from the opposite camp but I can relate to the author very well.
I think the problem is with the interviewers. It is a difficult task to interview and when everyone is allowed to lead an interview, it just leads to very random outcomes.
Companies don't really focus on developing interviewing skills for the people who are inside. Maybe they are just too scared to do that - pulling people away from their gut feel and not having an even distribution of people who can interview properly (across teams). It probably feels much safer to say a bunch of No's and then say Yes.
The lesser experienced and the hard-headed experienced ones are worst interviewers. They probably are looking more for people like us.
Am I the only one who likes side projects? I'm addicted to the idea of starting new projects in new languages. How many of them ever get completed or push into an environment is a different story... It's fresh, clean and filled with possibility. An existing code base is usually filled with hacks etc.
Some of my side projects exist only long enough to understand/solve the deep technical challenge required to make it work. Completing the project after that is just unfun work.
I'm certainly not opposed to them, and lately I've been itching to find the time for one. But putting side projects as a gate to employment seems like lazy interviewing work to me, and also doesn't really select for the best candidates.
Unless you believe "has no interests[1] outside of work aside from writing more code" gives you the best candidates, which I don't agree with.
[1] Yes, I'm being hyperbolic; no need to be a pedant.
If coding is such an art and so important to the industry, why are all people at the top do not have a git hub account to show? They must still be "passionate" about coding, no? Or is it a function of how much money you have?
Facebook worked not because of some guy wrote great, highly maintainable code. It worked because of the idea. Same with others great companies.
If there were these unicorn people who did not write "unmaintainable junk" there would be no security bugs, hacks, leaks etc.
All big companies have recruited "the best" for forever. Can any one of them guarantee a bug free software. They can't. Suddenly, all these passionate people with their github account do not look sexy.
Insisting on a side project is similar to people insisting on TDD and i am sure TDD does not solve the problem of bugs in code.
The "side project" culture is a by-product of not having a standardized approach to professional development in software engineering. Doctors, teachers, and pilots are all expected to refresh their skills, and their time to do this is baked into their salary. Software engineers need to do the same, but it's not baked into their salary, so they have to do it independently. You wouldn't pay a tax preparer for his time spent learning this year's tax laws, but you also wouldn't hire him if he didn't. So his hourly rate has to include the time that he will spend off-the-clock learning about the new laws that year. Software engineers should do the same, and treat their on-the-clock time as only one of the components of maintaining their professional readiness.
An independent tax preparer, sure. A tax preparer that works for a firm would almost certainly be allowed to spend their paid working hours learning this year’s tax code.
Why do hiring managers believe that github code was actually written by the applicant?
People lie incessantly about their ability to code; that’s why he industry considers things like fizbuz to be valuable. Why assign so much value to a public github account if you don’t trust their word in the first place?
Getting a job is a competition. There is no absolute criteria for whether you should get a job or not. So why should an employer prefer you over someone who loves programming and problem solving so much that they do it as a hobby? If your excuse is that your previous jobs were so invigorating that you had no free time for personal software projects, then your reward is the higher pay you've received at those jobs compared to other easier ones you could have taken. If you decide to hike and paint instead of work on software for fun, that is perfectly fine, but those activities are simply less valuable to an employer. To me, this article is a textbook case of the "I do less work than my peers but should receive the same opportunities" complaint.
I'd like to point out two aspects to this outside of workhours vs online profile/portfolio of work. Sometimes you can contribute to online tools during work hours. I've collaborated with Python folks to fix bugs or upgrade to new frameworks, or to Python 3, things that my work and libraries depended on. This was on the company's dime because I needed to get things done and didn't consider them ultimate obstacles. These are one off a few days investment sort of tasks, nothing super long term, but it's worth mentioning these are not mutually exclusive efforts.
Another detraction to working at home on side projects right now is just physical. I need to really take a break from the monitors to keep my eye strain budget reserved for work when I need it.
Just make a whatever tiny commit in your own public github repo. Its just the way interviews work these days,in a sense its like lying on your resume, its there and only 1 out of a 1000 will check it. I get you are pissed at the concept but as i said just work around it.
Since there is no standard definition of "engineering" in software, it is mostly driven by individual employers. If a potential employer wants to see you constantly programming in your spare time and have a GitHub account than that's how they view their "engineering" practice. You don't necessarily have to agree. But put yourself in an employer's shoes for a minute. If you, as a candidate, are not a certified engineer who practices what essentially amounts to a form of pseudo-engineering and works in a field where a large number of people don't even have a relevant degree yet claim to be "engineers" how else is one supposed to make a decision about your technical chops?
I'm curious about the companies where the author has worked, because they must be using a lot of open source libraries internally. If the author's GitHub profile is completely bare, then it means they've never forked a library to fix a bug, or added a new feature and submitted a pull request.
I don't care if you don't do that in your spare time. I don't know what languages or frameworks the author uses, but I probably won't hire a Rails or React developer if they'v never contributed to any open source projects. If they've never come across a single gem or npm package that needs a bug fix or a new feature, then they probably don't have enough experience.
And when I said I have no side projects
to show, what they heard - what
interviewers hear - is: I am not the
best. I am not a passionate developer.
I don't spend the necessary time to
keep on top of my education and skills.
That development is "just a job."
This isn't how I interpret it at all. Gauging how you write code, structure commits, and talk about your work cannot be done solely through face to face interviews. When I talk with someone who cannot show me any code, I feel like I'm lacking a signal for determining how well they'll be able to produce. It's not a deal-breaker by any means, just a complication.
I have a decent amount of side-projects and I build projects for fun (I even blog about them), but that doesn't land me any offers or opportunities. My Github has a decent number of samples that I've built. However, I get rejected more often than not because of my online coding interviews. Being a new grad, I don't have many other options but to oblige. We live in a world where nobody will talk to you unless you pass their coding challenge first. So I'm not fully in agreement with this article. If there are companies out there who truly want passionate developers, I'd love to know! Clearly, the big 4 aren't the right places to apply to.
Funny because I'm on the other side. I do side projects. I enjoy it. I also think of them as resume builders. However, not one company I've interviewed with cared about them. They wanted to know what I got paid to do.
I have this cooking website I started some time ago (http://cookarr.com), and apart from that I have some smaller projects, but I also say "No, I don't have side projects except of these, I don't have to do open source, I just... don't". It never did sabotage my interview though, because I am a specific kind of full-stack developer (good at prototyping and whipping up complete "MVP production apps" in a short time), and it's somehow valuable to many startups.
I went through majority of the comments here and it seems to me that for many programmers, their life revolves around side projects and they consider that other programmers should also do the same. There is more to life than just programming. It was not even a job until 100 years ago. Richard Feynman did not only do physics all his life. He learned how to paint, how to play music etc. Why restrict yourself to the programming bubble? The OP seems to me a sane person in this world of overworked zombies with fat bellies who call themselves passionate programmers.
I think you missed a lot of the comments saying, you don't have to live, eat, and breath code in order to have some code you've written up on GitHub. You don't have to spend every waking breath coding in order to write a script that will order you a pizza or something. You're life doesn't have to revolve around programming to find one weekend out of the year to write a program or spend 1 hour per week working on something.
I am a developer and I like to do plenty of things outside of programming. I ride motorcycles, read books (and writing a book!), play guitar/violin/piano, learn Russian, digital paint, make 3d art models, play video games, go out to eat, karaoke, go to meetups, blog, etc, etc. Most developers I know have plenty of hobbies outside of programming, but still manage to squeeze in some time for side projects. It does not have to consume your life...
Pet projects need not take up all of your time. All you need is a few hours every so often — an evening or so once every couple of months, or one weekend a year would set you head and shoulders above a lot of people. The whole thing of dark matter developers with no pet projects at all, versus "passionate programmers" who eat, sleep and breathe code, is a completely false dichotomy.
All employers are looking for is some publicly available evidence that you actually have the skills that you claim to have listed on your CV.
I agree that it shouldn't cost you being able to have a job that you like. That being said, I don't see why you shouldn't have a couple of side projects on Github or even a personal site. The side projects I've shown to employers were not gargantuan MVPs but simple applications that did one nifty thing well. It's fine if you don't want to do any of that; I personally would want to do things that give me an advantage with a company that values interest in coding and innovation.
I have this bad habit where I don’t do side projects for me, but for work. I get excited about ideas I have to improve our product/infrastructure at work (I’m an SRE) and given that I am more or less autonomous I work on those instead of some personal GitHub project.
This means that I write a lot of software out of hours that makes it to production, is well tested and maintained, but I could never show it off in an interview. I need to break the habit, but I just don’t get the time during the week to work on this stuff.
> That "the best" is happy to drink into the Earth every Friday and has absolutely no evening or weekend plans.
This looks very much like deflecting the disappointment experienced at the boutique app firm to all people like us who do love to code in spare time. I believe it is unfair to paint all of us with the same brush. I know plenty of people (myself included) who love to code in their spare time and still have weekend plans that have nothing to do with computers.
I'm super excited about this guy, looking at his background we had to have worked in the same computer science lab at Texas State. We're the underdogs in Texas and it's cool to see people that were successful in the typical ivy-league environments. Incidentally enough, I'm now getting into mobile app performance and worked at Amazon around the same time.
Related:
I find that interviews are mostly a crapshoot. I'm currently looking for a new job in SF, so I have a few experiences from this last week that stood out:
* Onsite with a ~100 person startup last week where the guy asked about my past experience ("Wow me with a past project") and then I caught him looking out the window as I explained a particularly gnarly problem we solved at Amazon. I was asked 5 coding questions (that I more-or-less solved), never spoke to a manager and then got a canned rejection.
* Onsite with a ~2000-10000 person tech company and met my would-be team, my manager and his manager. We discussed the projects I'd work on, did coding and architecture problems and I left super excited to work with them in the future. I received an offer from them within a few days, having already built a relationship with my team and management, that makes me feel much better about the opportunity.
* I'm currently going through an interview with a really great company (~60 engineers). I spent an hour talking to my maybe-future manager and we left both excited to work together. The follow up was a realistic technical project and pair programming with my future teammates- all of whom were awesome to work with. I'm still awaiting next steps, but I've really enjoyed getting to speak to my future team.
A litmus test I've found: Does the technical hiring manager talk to you before you phone screen? Do they seem engaged and ask follow up questions? If your only point of contacts prior to the onsite is a random engineer interview and a recruiter whom repeats a script, your past work is not going to be a major factor. Most likely your hobbies outside work won't be considered (I'd suspect for legal bias reasons?) unless it's a small startup that's looking for a friend-as-a-coworker fit. I experienced this at my last startup, we went from 5 engineers to 50, and the values started to shift.
Why doesn't he mention what he thinks interviews should be about? Does he think that asking a bunch of dry-erase-board-questions about algorithms is better? What about just a company going with their gut?
It's tough to agree with a post that doesn't offer an alternative. All I get from this is that he wants to talk about how his life is more balanced and hobbies are better than ours, and that alone should be enough proof that he deserves every job he wants.
It doesn't make sense to volunteer extra information that could be potentially used against you.
Unless you have done your time consuming best to ensure its 'perfect'. And this directly leads to a culture of resume driven development.
For those who are actually active on projects most interviews do not provide the context to absorb the information of your contributions; coding style, tradeoffs, constraints of these projects etc. They will all end up sounding like excuses.
I too don't have any side projects primarily because I find creating projects is a slower way of learning. The fastest is reading documentation, books etc. Creating side projects doesn't guarantee that you will learn anything more than what you already know. Looking at codebases of high quality frameworks/libraries, reading books about best practices, taking online courses are some of the faster ways of learning.
In the free time that I can set aside to code, I don’t use it to write complete programs. I poke at stuff that’s intellectually interesting to me. It’s not good code. It’s not structured well, the variable names suck, it’s buggy. But none of that was the point of the exercis. I don’t put that stuff on GitHub because I don’t want some hiring manager thinking it is my best code. My best code is my professional code.
If someone posts a link to their GitHub on their resume or makes mention of it during the interview process, I take that as "you are giving me free range to look at your code and potentially make a hiring/advancement decision based on what I see," and I definitely peruse and ask questions.
My motivation for (and lack of ideas for) side projects has dwindled over the years.
Most of my "side projects" are throwaway pieces of code or scripts that do silly things, or ironically are solutions to "cracking the coding interview" style problems.
I wish companies cared about side-projects as qualifications for hiring. I send full projects and they never seem to peer into them when I query. I want them to look so we can have a discussion around them.
In the last 10 years I've built 40 web-apps and that doesn't include ~20 codebases of my own
I don't understand how you can be a programmer without having side-projects or at least contributions in open-source.
I end up contributing open source or creating my own libraries via work, so I'd still have things to show outside the scope of standard hours.
I can get not wanting to do CS algorithm puzzles in interviews since thats a specialized discipline rarely applicable to web-app development but this I can't get behind.
I've definitely had my blog mentioned in interviews. My github is rather sparse. I'd rather do a coding interview in person, or better yet find a job through a referral.
It is hard to believe they would waste your time or theirs with an onsite interview, if they decided apriori a candidate with no side/opensource projects is unfit for them.
This was my hangup too. The author implies that it was simply because they didn't have any side projects that they were rejected. I find that hard to believe though because why would they bother bringing them in for an interview if they didn't have any side projects? Plus, 90% of the applicants I ever saw didn't have side projects, so they'd have to auto-reject 90% of their applicants. Why bother bringing in one of the 90% auto-rejects for an interview?
Honestly when hiring I think the exact opposite : I would only look to side or open source projects for an inexperienced candidate who would have no other way to demonstrate competence and a track record. In the case of a candidate with more experience, their having a body of work outside of their paid employment would be perhaps interesting and something to drive a discussion with them but it would also make me wonder if they were engaged in their day job.
I don't like the implicit assumption that only a person who's passionate about programming (and [nothing:little+1] else) can be a very good programmer.
I own the book "Pragmatic Programmer", a widely respected book about general programming principles. The bit about its authors:
"Andy Hunt is an avid woodworker and musician, but, curiously, he is more in demand as a consultant. He has worked in telecommunications, banking, financial services, and utilities, as well as in more exotic fields, such as medical imaging, graphic arts, and Internet services. (...)"
"Dave Thomas likes to fly single-engine airplanes and pays for his habit by finding elegant solutions to difficult problems, consulting in areas as diverse as aerospace, banking, financial services, telecommunications, travel and transport, and the Internet.(...)"
Isn't tunnel vision focus on programming a bit limiting ? What about a different perspective provided by different experiences and skills ?
A fox knows many things, but a hedgehog one important thing - attributed to Archilochus
"(Isaiah) Berlin expands upon this idea to divide writers and thinkers into two categories: hedgehogs, who view the world through the lens of a single defining idea (examples given include Plato, Lucretius, Dante Alighieri, Blaise Pascal, Georg Wilhelm Friedrich Hegel, Fyodor Dostoyevsky, Friedrich Nietzsche, Henrik Ibsen, Marcel Proust and Fernand Braudel), and foxes, who draw on a wide variety of experiences and for whom the world cannot be boiled down to a single idea (examples given include Herodotus, Aristotle, Desiderius Erasmus, William Shakespeare, Michel de Montaigne, Molière, Johann Wolfgang Goethe, Aleksandr Pushkin, Honoré de Balzac, James Joyce and Philip Warren Anderson"
(Wikipedia)
I think modern society and job market places too big an emphasis on hedgehogs. While backend programming is my profession, I feel more of a fox than a hedgehog. It works well for hobbies, but not really for jobs as currently available. For example ladies tend to compliment me I have a nice voice. I also like books, fantasy and science fiction, and prefer short stories to novels. So I can connect the dots and... record some audio books. I look for old short stories no longer covered by copyright, and intend to record them as "audiobooks". For instance about a village fool who became a werewolf. Another example: I like animals, I'm precise, patient and have an analytical mind. Anwer: Origami. Another example: I can't draw much (I really tried with Gimp and some hand drawing... admittedly, without a good teacher), but I'm somehow attracted to visual arts. As mentioned, I'm analytical, and I'm not too bad at math. Answer: Vector graphics, .svg, Inkscape, writing images in vim. It takes some introspection and observation, but you can figure out what new hobby would give you satisfaction. If you have many interests, try to think what they have in common, or how you could possibly connect them.
Yes, that's why he'll get a job at a large and average software company, but not at a modern, small software company that still has to make a name
for itself and has to rely on people living for code, having work life in their top 3 priorities being able to pull out the company out of closing down if needed.
It's great you're a passionate person, but this article's tone and implication is saying that's enough, and that projects shouldn't be viewed as a just ask.
As a career professional and founder of a career related company, I have some news for you: you clearly have the time and passion to create, but at nearly every chance when you have additional time, you're not putting it into programming.
Yes, you've found a job. That's great, but you would be experiencing more pay and a more accelerated career if you were spending 1/5th your free time on coding as well. If you want to blow glass, or draw, or write -- fantastic. But it's not wrong for a company to give the job to someone else, and...
BUILDING SIDE PROJECTS DOES NOT REQUIRE YOU TO BE IN THE TOP 1%.
More often than not, side projects are just a requirement. You don't have to love code like it's your calling to create a side project.
I recommend this to all software engineers: build side projects, and don't listen to this post as a calling to infer them as unjust.
Statistically speaking, building side projects is one of the best things you can do for your career.
I don’t really disagree with your philosophy of working while you’re working and NOT working in your downtime. I think the same way.
But I have a whole pile of stuff I can show you that I’ve worked on. I don’t ask anybody to take my word for it. In computing, you just can’t. The signal to noise ratio is too bad, there are too many guys out there making unmaintainable junk, if they actually ship anything at all. There are shops out there that can afford to hire a bunch of maybes and just weed out the duds when they wash out, but I don’t have that luxury. Nor am I going to go on some weeks long hiring safari where I hire you for a week or two and see if you can cut it. No time man. Sorry, don’t have it. I’m going to give you the job or I’m not going to give you the job.