Open source projects always need extra minds. Does your hiring process contribute to open source? It could, and it's easy to do.
Part of our hiring process is a day-long visit that includes a lot of pair programming. To make the day valuable for all involved, we want to work on interesting problems. Open source is made to order:
- There are no NDA or confidentiality issues
- If you want, it is easy to agree on (and study) projects in advance
We also do whiteboard sessions, where interviewees and Relevance folk work together to solve design problems. In the past, I haven't made a specific effort to find open source projects for these sessions. This morning I was reading about a Guice/Wicket integration issue, and it occurred to me that open source issue trackers are a goldmine of interview opportunities.
The next time you encounter a complex issue in an open source project, file it away for your next job interview. If you make interesting progress, contribute it back. It doesn't have to be code! Good analysis and documentation can be a huge help to the next developer on a project.
Oh, and if you are interviewing at Relevance in the next few months, be ready for this interview question:
There is an interesting Wicket/Guice integration pitfall documented on the Wicket wiki and as issue WICKET-1130. If you were free to change anything (e.g. Wicket, Guice, Java, the value of Pi) how would you solve this problem? How would your answer differ if you could change only Wicket?
I do something similar when I’m looking for fresh people.
As I’m working with Rails and this job market is next to non-existant in Poland it’s hard for new people to prove their worth.
Instead I let candidates to pick any Rails (or Ruby) based open source project and fix a ticket there. Once the solution is published to project’s bug tracker we continue the talks.
This gives them a good opportunity to proove themselves and also contributes to community.
Love it. Great idea.