I vacillated quite a bit on the title of this post. It is, after all, not me that is hiring you. Nor do I have the power to hire folks at will: it’s a team decision. But I also don’t want to claim to speak for anyone else, least of all for Mozilla—my excellent employer and we are, indeed, hiring—since this is really just the things that I know matter to me.
I suspect they matter to a lot of people.
Since I’ve been doing a lot of interviews lately, I’ve been thinking about how candidates can help themselves, the things that I need to know, and how someone starts themselves off on the right foot.
- Have a resume or CV. I know it feels archaic and yes, Github weighs more in my decision-making, but there’s a reason these documents have existed for so long: I need to know where you’ve worked and what your job was. This stuff matters. You don’t even need the fancy PDF (please, no .doc or .docx, though .rtf is fine) just have a thorough, up-to-date LinkedIn account. And put in details! Brag! What were your roles, your responsibilities? What new processes or tools did you introduce and how did they help? How did you kick ass?
- Have a Github account. I will accept BitBucket, but the UI isn’t as nice. (Also, I use git, we use git. Learning git is a good idea.) Put your website on Github. No one is going to steal your personal site and make millions, and it gives me some guaranteed code to browse. But way more importantly…
- Contribute to open source projects! This isn’t just “Mozilla likes Open Source,” though we do (and I do). This is about code samples. Often when we have to ask for code samples, we get contrived projects that don’t solve any real problems. Contributions to real projects show me how you write real code and, at the same time, how you work with others. Open source projects are communities, teams. Do you communicate well in pull requests or bugs? Do you revise patches based on feedback? Or, as a maintainer, how do you treat contributions from others?
- Have a blog. The cool thing is that** I don’t even care if you write about code**. In fact, I’d love to see that you write about other interests! But because it’s another website (I am looking for web developers, after all) and it’s yet another form of communication for me to think about. This is especially if you know you get nervous and don’t interview well.
And that’s it! Well, OK, that’s not really it, not even close. But these are mechanical things, things that are easy to do, for various values of “easy.” I notice the absence of these things*.*
Obviously there’s a lot more involved, but this is basic information that helps me, and helps me before we even talk. That’s a great place to start an interview.