If I were being interviewed by you I'd have a question: "If you hire me, can you guarantee that either (1) I'll be contributing to open source as part of the job, or (2) the job will leave me with enough free time and energy that I will have both the time and desire to do programming outside of work on open source?".

If your answer was "no", then my follow up question would be "so basically you wouldn't hire someone whose prior career had been spent at companies like yours?".

If your answer to the first question was "yes, option (2)", I'd have some follow up questions probing why the job is not able to provide enough interesting and challenging work to fully engage me.

I think you are missing the point. This isn't about the job you are going to be doing, this is about getting me to even consider you for a job.

To answer your questions though:

(1) I'd expect you to continue doing open source, as both part of the job and on your own. I do it, so should you. Case in point, we just integrated our site with WePay. WePay didn't have Java API, so I wrote one (along with my business partner) and we made it open source [a]. This benefited my company, open source and WePay all in one shot. This isn't the only one, I can point at many more large projects [b], [c], [d] (for just a short list) that we've either open sourced ourselves or contributed to. I have a clear history of coding in multiple languages. Anyone who is going to hire me knows my skill set without having to give me silly brain teasers or even read a resume. Why would anyone want to hire someone without a clear record like that?

(2) How you spend your time is up to you. There is a certain amount of work that needs to get done as part of the job and I'd expect that to get done. As long as you are getting your work done, in a reasonable time and of a good quality, I'm fine with whatever you do with your time. If that 'policy' doesn't leave you with enough energy, then I'd suggest either learning how to do better time management or find another profession / company.

As I already said, I wouldn't hire someone without seeing their source code. The single best way to really see it is to see how they've contributed and worked with open source projects. Bonus points if you find a unique project to create yourself.

[a] https://github.com/lookfirst/WePay-Java-SDK [b] http://objectify-appengine.googlecode.com [c] http://batchfb.googlecode.com [d] https://github.com/lookfirst/bootstrap

I am pretty sure that majority of people doesn't have public repository. I don't have problem showing my code but it is not public.

Here is my problem with that statement:

You are saying that you only have code which is entirely private. This is most likely code you wrote for your employeer, which you can't show me anyway because chances are that it is NDA private. Or, you have code which you wrote for say, an iPhone app which you are probably never going to show to anyone. That is all fine.

However, you are also telling me that you've never integrated any open source projects into your code or relied on any non-commercial external libraries. Or, maybe you have done that.

But then I have to wonder why you've never contributed back to any of these projects that you've depended on. If you are a great dev, I'm sure you found them lacking in some way and wanted to contribute a bit back to them.

Thus, we've come full circle. Any developer that I would want to hire, has figured out that there is a massive ecosystem of open source projects out there. They are integrating them and contributing something back to them. They are drawn to these projects like flys to sh*t. These projects teach them new tricks because they are studying others code. They are drawn to give back to these projects because they are taking so much good from them. That is what makes a good developer in my eyes.

Here is a really good case in point example. Last night I was working with the amazing Underscore.js library, which I'm fairly new to. I found that I wanted to do something with it, couldn't figure it out and made a suggestion on how to improve it [1]. Someone from the community responded quickly, we had a bit of really positive back and forth and in the end I learned something new about the library. I expect that anyone I hire has the gumption to also be doing similar work.

Go fork some projects.

[1] https://github.com/documentcloud/underscore/issues/425

You'd miss a lot of really good people with that standard. I used to work at Amazon, so I'll use them as an example. (Keep in mind, it's been about 1.5 years since I left, so some of this may have changed.) Amazon has a policy that requires you to get open source contributions approved by legal. That is, legal has to review every commit you want to put into open source to make sure 'it's not in a competing product', reviews can take weeks, and when you ask a lawyer every product is competing.

The whole company is built off of Open Source, but there are teams the fork the projects into internal repositories (Perforce when I left) and put a bunch of Amazon-specific 'things' into them. As a developer there, I didn't use the Open Source sites, docs, or mailing lists at all -- I used Amazon's. We had wiki's, ticket queues, and mailing lists -- all internal to Amazon. Maybe the core team that's doing the forking and merging from the trunk would or does contribute back, but for any given project >99% of the developers at Amazon don't ever work on that codebase -- or with the codebase of any of these projects.

As a developer, we just have a 'team' somewhere that does. If something doesn't work in Tomcat, we don't go find the Apache page and file a bug, or jump on the mailing group, we file a trouble ticket with the team that owns Tomcat at Amazon, and they fix it. Maybe they go to the Apache pages and mailing list, or maybe they just see the line of code in the codebase and fix it, I have no idea.

I've been waiting on approval from legal for a diff viewing tool. It has been under review for over a year now. On the one year anniversary of the ticket I pasted in an ascii art birthday cake and there has finally been some progress. It is among the many reasons amazon loses great devs.

I'm ok with missing those people, they already have a nice stable big company job they are happy at. There is a lot of value in that and I'd never want to take that away from anyone.

In high school, we were all told that in order to get into college, you needed to have extracurricular activities. I consider spending some time at night or on the weekends on an open source project part of the deal of being a software engineer. Not everything needs to be taught or done on the job. The people I want to hire make their own time to learn and grow.

I might "fork some projects" if I was interested in impressing you. I am not.

I can find any number of jobs without your approval or that of the "cool kids."

Thanks anyway.

That's not really latchkey's problem.

It's different for big companies (Google, Microsoft etc.) that have to hire by truckloads, but small, startup companies (say, <40 people), only need to hire a couple of good people and therefore can be selective and therefore can use a filter that rejects "majority of people" (especially given that filter also strongly correlates with "people they wouldn't want to hire anyway").

Now, I'm not saying it's your problem, as you also need to be hired by only one of many companies so it's perfectly valid to ignore companies that have a strong preference for open-source contributions.

However, if you do want to be considered by such companies, it's a small investment to build a portfolio of open-source code on github.

I believe this is becoming more and more important because more and more startups are founded by people who grew up in a world where open-source projects and github are a norm, not some extraordinary event as it used to be just a few years ago.

Out of all the devs I respect and admire as mentors, the majority of them do have publicly contributed code and are involved in some open source project. Not to say there are not a few who don't, but I think the point is that the majority of really talented developers out there seem to have something.