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.

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.

I would guess the environment candidates are selected from influences these numbers significantly.

And you're right, I'd understand that in some of these environments, OSS isn't necessarily considered fun or relevant.

Then again it's all speculation.

Out of curiosity, what do you mean by this? What sorts of things do they all have in common?

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.

show me freebsd or linux kernel contribution on github, for example

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.

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

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

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.

Just because we do side projects does not mean that we do not have a life outside of coding.

But certain people believe that in order to be a good coder, one of your hobbies MUST be coding.

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

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.

I don't expect a brain surgeon to mess with somebody's head because he's bored at weekend, though :p

This is a huge problem in the industry and is the source of massive waste.

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.

The critic points out that it is no longer curiosity which drives you when people expect you to do it.

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.

The internet needs less stuff on it, not more.

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.

> The internet needs less stuff on it, not more.

I disagree!

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.

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.

I bet that even people who have spend 20 years on side projects haven't reached those 10K hours of practice yet.

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.

Some jobs are easier to do on the side than others. I'll bet the gardener has some side projects too.

If you were looking for a drummer for a band, you would want to hear him play.

The latter one, sure. Makes me wonder if we should call interviews as auditions.

Nice! Agree with that.

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.

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.

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.

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.

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.

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, it is employers signaling how cool they are 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.

As a rule, I don't and have never consented to them because I find them exploitative.

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

There is a way to do this. But some people go a little too far.

Last years one start up asked me to write an entire backend application for them for free.

That they declared bankruptcy this year has been a tasty bit of schadenfreude.

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

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.

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.

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.

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.

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.

Would you expect a musician to practice their instrument in their free time or only play their instrument during paid gigs?

I've had too many "tests" that were a giant waste of my time to ask it of others.

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.

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.

i bet the question was: "what has HTML5 done for us?"

https://www.youtube.com/watch?v=Qc7HmhrgTuQ

I said, "CSS, but it doesn't have much to do with HTML5's features."

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.

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?

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.

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.

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.

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.

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

Either Git has a complex user interface like I claim or I am beginning to grow old.

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.

Same for regular expressions. Once you know the syntax, they're pretty easy to understand. It just takes practice.

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.

I agree with this in general too.

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.

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

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.

Employers do not care. Other people? Sure. Employers? No.

You just have to know your real market value, how good are you compared to others.

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.

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

feel like they'll fit right in with any number of startups out there! But good for you on calling them on it.

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.

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.

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.

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.

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.

"Well do you have any recordings you can show me instead?" "No, I do other things with my free time. I don't work outside of work."

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.

I think I prefer the coding test.

Ha, but seriously, I hate take home assignments.

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.

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.

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.

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.

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.

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"

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.

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.

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.

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

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

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.

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?

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.

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.

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.

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.

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.

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.

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.

But if you ask them to do a 30-minute coding task, that suddenly becomes a total disrespect of their time.

So, are architects and engineers expected to have built side-houses, and side-bridges, and side-cars?

Artists have portfolios. Why shouldn't software engineers?

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.

Yeah, if you work for GNU or for countries were NDA is not a notion </sarcasm>.

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.

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.

It's a matter of "if you want to know how they'll treat you, look at how they're treating their ex".

thats insane

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.

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.

So WHAT weeks long safari do you go on for your company? Product management? Raising fund? Sales?

It’s much more cost effective to invest in your existing people. That’s one thing I never skimp on.

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.

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.

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.

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.

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.

Sounds like a boogeyman.

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.