How to Interview for an Open Source Job (Part 2)

In my first blog in this two-part series, I described how to interview for an open source job. In this post I describe how to go beyond the mentality of just “finding a job” to creating opportunities for yourself and your employer.

What many interviewers and interviewees forget is that the interview process is much more than simply filling a job. In the collaborative setting that is typical of open source communities, the interview process can open doors to new relationships and opportunities, potentially growing the software community and giving rise to new business.

For example, a Kitware interview might go like this. Our potential new employee shows up for the formal interview (of course only after several pre-screen interviews), and goes through the usual gauntlet of presentation, interview, and lunch meetings. During the course of the day, we discover that the candidate is using CMake on a new OS project which is addressing some challenging high performance computing task. We are able to help the candidate use CMake more effectively, and suggest ways to use ParaView and/or VTK to solve the HPC problem. In the mean time, we learn that the candidate is working with a team of researchers who are actively receiving funding to address their technology challenge, and need some help.

At this point several things may happen. The candidate may be hired, in which case Kitware would work with the new employee and her former associates to further a new relationship. Or possibly the candidate does not accept an offer due to geographic or family considerations, or an offer is not made due to “fit” issues. Again, this does not prevent the parties from pursing a professional relationship.

The point of this fictional story, which by the way is pretty representative of many interviews, is that the interview process is a chance for two parties to exchange information about their work, challenges and opportunities. Viewed in this light, the interview process can become a marketing exercise which frequently leads to further collaboration. It is also a chance for a candidate to “sell” their work to Kitware, with the possibility to continue their efforts while in the employ of the company, or to collaborate with Kitware in a business venture. This enables both parties to help each other expand their horizons, and mutually benefit each other in pursuit of their goals.

I would encourage all candidates to go beyond just trying to “find a job”. Think about what opportunities you can bring to the table, and how you and Kitware can further an exciting opportunity. If you can sell an exciting project which fits in the pervue of the company mission (Rule Scientific Computing with Open Source Software) and are willing to do the hard work to realize your dream, you have just set the stage for what will certainly be a very happy, productive, meaningful, and self-directed career.


One Response to How to Interview for an Open Source Job (Part 2)

  1. Tony Duarte says:

    I worked at a Fortune 500 company that said all inter-department communication must be written. Otherwise, communication gets lost.

    Another Fortune 500 company had rules against writing when a phone call could be used instead. Writing is less efficient.

    My point is that many systems work. And every executive believes they’ve found “the way” — proven by the fact that they are currently making money. (Aside: This begs the question – do we really want executives so unable to distinguish between correlation and causation?)

    I can’t help but wonder what people might be excluded by this particular process. Is this really the kind of world we want?

Questions or comments are always welcome!