Working at Mozilla

I'm the only community contributor listed on this AMA. Everyone else you see on the list are full-time Mozilla employees.

I've wondered about it myself, but I understand that even though non-profits shouldn't be greedy, we need to pay competitive salaries to attract and retain whatever personnel are going to advance our mission the most. IIRC, there are rules governing how much non-profit employees can make - i.e., can't pay exorbitant wages.

I used Firefox for years and just happened to see that Mozilla was hiring. But I know we've hired a number of contributors.

Accidentally. I hacked on web stuff as a kid, I thought I'd go to college and get a job in programming... Web development wasn't really a field. Then that changed when Paypal (the small startup back then), Trinity and other companies started yanking people from my school with huge offers and whatnot. I'm glad I stuck to doing what I enjoyed.

Honestly, a good on-ramp to a job with Mozilla is to [become a contributor](https://www.mozilla.org/contribute/) first!

I wanted a web page, and so I kept viewing source and reading things on the web. My career has shifted more and more into the backend which ultimately is in charge of writing the page. It's software engineering more than web development.

Yes, always! careers.mozilla.com

> What was your unique road that shaped you on your way to working for Mozilla? That's a long story. Tl;dr - I had a job, I didn't like it very much, I applied at Mozilla. Slightly longer, I was a tinkerer on the web since the late 90s. I like solving problems I'll have to solve again, so I ended up working on my own frameworks in PHP, and then building apps on them that solve my own problems. That created a portfolio I was eventually able to use to get jobs. > What languages did you start with, what did you become proficient with? Perl and JavaScript, together. I haven't written non-trivial Perl in 10 years and am pretty happy about that. Then PHP, and now Python. I've also dabbled in Java, Ruby, and C. I swear some day I'll get good at C. And I want to learn Erlang! > Was there any project you worked on in your early years (before Zilla) that really stood out? Why? It's always the one you least expect. I built [TodaysMeet](http://todaysmeet.com) to help my father teach a class. It was recently mentioned in the NYTimes and this week on RWW. I think it fills an important niche for educators. > What would you consider your best accomplishment to date while working for Mozilla? I think, personally, I'm proudest of the team we were able to build. We've more than doubled in size since I started and the average level of awesome has only gone up. I'm particularly proud of the support team, since I had the most involvement there. > What has been your biggest disappointment/failure/letdown (either project or expectations) while working for Mozilla? I really wanted to see Alex Limi's new concepts for bookmarks make it into Firefox, but I think they've been shelved. > What's one project or idea you want Mozilla to focus on next, that you guys haven't discussed as a group before? I'd like us to get more into education. There was recently a piece about the Hackasaurus project in The Atlantic, and it's a fantastic idea. Too many people are just consumers of the web. Part of our mission is creating opportunity and that means helping people become producers. Codeyear is awesome--I wonder why it wasn't our idea?

[Yes!](http://www.mozilla.org/en-US/careers)

I can only speak to our Web QA group, not the Firefox QA group, so this may or may not be interesting for you. We do even more rapid releases than Firefox, though, with lots of sites releasing updates every week or even faster. We've had to take a look at the philosophy of QA for really rapid releases. QA now focuses a lot on automation and exploratory (manual) testing of new features--which happens in our production environments behind feature flags. For us, as web developers and web QA, the choice of tool is most frequently Selenium, since it can do things within the browser and test integration in a way that Python unit/integration tests and JavaScript unit tests can't. We also use httplib/requests and unittest, and other tools when they make sense. The key is to avoid getting too tied to one tool, and focus on what it is you're trying to assure. Then just pick the best tool for that job. That means we try to keep as much as we can in our web apps Python and JS test suites, and use integration tests, like Selenium tests, for bigger things. We don't do a lot of proactive load testing, since we do a lot of real-time monitoring in production. That's so much more valuable, as long as you have the ability to respond quickly, either with patches, or feature flags, or something. We could definitely do a better job blogging about testing.

"Very beginning of your career in Mozilla" As a community member, I was excited about Firefox in 2004, and working professionally as an e-commerce web developer at RealNetworks. As an employee, I left Amazon.com to join Mozilla full time in 2008. As a web developer in general, I taught myself HTML in 1997. I had no background in computers. Education, talent, etc - If you like to play with the web and make things, keep doing it! Do it all the time! Make lots of experiments. See how cool sites work and take them apart. You can contribute to Mozilla today. Use github to learn and share. Everyone's career path is different. There is no special entitlement (school, family, wealth) needed to help change the world. The web is open and ready for your ideas.

We have some paid-staff working from Germany. We have some contributors in Germany. They all work from home right now but we're looking for a place to open a Mozilla Space in Berlin this year. [Submit your resume](http://mozilla.org/careers).

Yes (I have only completed 1 year of university, and there are other people at Mozilla that have not completed post-secondary education), but you had better be able to demonstrate that you have the skills. In the context of the web development roles, some of the people here have answered that what you have done is going to be more valuable than what you have studied.

For me personally, Mozilla is the first company I've worked for that has a mission I totally agree with. I love the web, and I love being somewhere devoted to the open web. If I ever left my job here, I'd probably keep working on Mozilla things in my spare time - and there are a number of people who've done just that. And, in terms of promotions at least, we seem to have a tradition of promoting people after they've already been doing the job for long enough that the promotion is an afterthought. That might sound cruddy, but what it really means is that people here generally gravitate toward what they want to do and what they're good at doing, and they do it. That kind of career flexibility makes me very happy, and I anticipate staying happy.

"Hierarchy" is an interesting question. Mozilla has it's Module Owner system, but within webdev we sort of do our own thing. We work with a number of different groups on different projects, and they become stakeholders as well as the community, us, our IT folks, QA, etc. Decisions are made on most projects with consensus from those groups. If you have an idea, no matter how crazy, and you build consensus around it, it can happen. A lot of those ideas come from community members who aren't employees, too. In terms of "how" stuff, like "how do we implement this?" We try to push decisions down as close to the people making them as possible. We have a couple of layers of hierarchy but I like to think of an inverted traditional structure. As a manager, I'm not here to tell my employees what to do. They know what to do, I'm here to help them do it, and grow as engineers and, hopefully, as people along the way.

I contribute to Mozilla Webdev in my free time. So every evening I spend a few hours catching up my bug mail and figure out what to do for that evening. It may be continuing to work on a branch that I've been working on, getting a quick code review from a fellow webdev, talking to the product manager to clear up confusions, and there's always the general chatter in the #webdev channel on Mozilla's IRC network. Sometimes, I participate in Mozilla meetings when they're at a reasonable time (yeah, timezones suck). Overall, I've found it very rewarding to be a contributor and to be counted as a team member even though I'm not a paid employee. One of the most challenging bits I took up was speaking at a recent Mozilla event that I was invited. I sick for the few days preceding the event and nervous with stage fright. Eventually, though, managed to pull it off!

Mozilla is a very, very remote-friendly company in general, and our team is (I think) remote as a majority. Personally, I'm hooked on it and would have a hard time going back to an office, now. IMO, the "easier" part is being able to work without outside interruptions, but the "harder" part is being self-motivated enough to work without interrupting yourself. My home office is mere steps away from a fully-stocked entertainment center with an Xbox. Of course, the office in Mountain View has that, too, but at least there my co-workers can see me slacking off :) There's also the issue of communications - but we attack that problem with documentation, IRC, IM, VoIP, video chat, and whatever else we can come up with. That's actually a good thing to attack, too, because we make Open Source software. Barely any contributors from the community have the advantage of being present in a Mozilla office, so being remote helps to keep Mozilla employees on the same level with non-employee contributors because most of the communication tech we use is not exclusive to the company. (For instance, did you know that our weekly all-company meeting is a public conference call? [Every week](https://wiki.mozilla.org/WeeklyUpdates).)

Mozilla pays its own bills. As to how Mozilla makes money, [refer to this previous question](http://www.reddit.com/r/IAmA/comments/oonrg/iama_member_of_the_mozilla_webdev_team_ama/c3iu19f). As web developers, we receive a salary basically like any other employee at any other company.

I started on GeoCities, and have no formal training at all. (My degree is in Math, which sounds related, but I consciously avoided all the useful, applied mathematics.) I started building web apps because it was fun. And after a while, bigger web apps, frameworks, stuff to solve my own problems. Then I got a job doing those things, and some freelance work, then another job, etc. When I interview someone, I don't care what their formal education is, I care if they're talented, and what they've already done.

[Yes!](http://www.mozilla.org/en-US/careers)

I'd love to see Web Technologies used everywhere. Not only on "the web" but in every object that has a chip. I'd also love to see how IPv6 and symmetric connections will help decentralise the content. Instead of putting our data on a few webistes, we'll keep it on devices we own and applications will pull them. I recommend looking at this video by Scott Jenson : [What's an app anyway?](http://blog.webfwd.org/post/13551125129/whats-an-app-anyway). It talks about how web apps can be much more powerful than native apps and that we'll have more and more Just-In-Time apps.

**Testing** - To add to what Fred said, we also use [jstestnet](https://github.com/kumar303/jstestnet) (kumar303 wrote it) to include our [QUnit](https://github.com/jquery/qunit) (JavaScript/front-end unit tests) in our CI results. Our WebQA and Automation teams are big contributors to and consumers of the [Selenium](http://seleniumhq.org/) test automation project. We're working to get those tests included with the nose/QUnit results, because a failure is a failure is a failure, no matter where it failed. We also have developed a culture of testing--this is something I've been meaning to write a blog post about. That means a few things: 1. Time to write tests is included in how long it takes to write the code under test. A feature isn't complete without tests. 1. If you break the tests, there's some good-natured teasing, and you lose points in the CI game. Light social pressure is incredibly helpful. 1. If you break the tests, your *first* priority is fixing them. Next I want to develop a culture of performance. **Deployment** - This is my favorite topic! I've been giving talks on it for around a year now. I actually started putting a joke about that into my talks about it. My goal with all the projects I touch is to deploy continuously. Not only does continuous deployment mean fixes get to users as fast as possible, but it has a bunch of requirements that are great in-and-of themselves, like... 1. You *must* have a robust, automated, and fast deployment pipeline. One-button and wait. 1. You *must* have a high confidence level from automated tests so you don't break things. 1. You *must* have active, [real-time monitoring](http://codeascraft.etsy.com/2011/02/15/measure-anything-measure-everything/) of the site. 1. You *must* keep master/trunk/whatever branch in a clean, working state, all the time. 1. Developers *must* develop a sense of ownership over their code that lasts all the way out the door. It also has a number of side benefits, like not doing code pushes at night when people are tired, or about to leave for the day. Some projects are closer than others. We learned a lot from [Etsy](http://codeascraft.etsy.com/2011/03/19/moving-fast-at-scale-slides-and-reprise/) (link to blog post and [video](http://www.livestream.com/etsy/video?clipId=pla_adbab6e2-c629-4bfe-b1fd-21c898693282), watch Kellan and Erik's sections). But their [Deployinator](https://github.com/etsy/deployinator) tool is Ruby, and it took them a while to open source it, so we built [Chief](https://github.com/jbalogh/chief) to do the same thing (run some shell scripts, print a bunch of output). We've got push-button production deploys with Chief or other, ad-hoc tools, for a few sites now. We've got it set up in the -stage environment Fred mentioned for a few more. We use another tool called [Freddo](https://github.com/oremj/freddo) to deploy -dev environments on Github post-push hooks. My goal is to have all new environments set up with Freddo and Chief by default in the future.

Contribute to open source projects. I met many of my friends through working together on projects and found two of the jobs I've had that way. Plus if you're contributing, your code is out there in public and you can point to it on your resume and some companies really value that in their hiring process.

Haha, no. However, our [web projects](http://github.com/mozilla) routinely have code names as well. Our rewrite of the careers website (not live yet) is called "lumbergh", Mozilla Add-ons' codebase is called "Zamboni", our newsletter signup library is called "basket", and so on. So, we could consider calling a project "bronco". What kind of project would it be? :)

If I'm not mistaken, we have people in the US, Canada, England, France, South Africa, India, Indonesia and one of us is gonna work from Thailand this week. In terms of nationalities, we are American, Canadian, British, French, German, South African, Swedish, Indian, Australian. I might miss some nationalities. Some people work from of our [9 (current) offices](http://www.mozilla.org/fr/about/mozilla-spaces/), others work from home or cafe or pubs. I personnally pushed a commit from a train between Paris and Amsterdam. I know others pushed a commit from a plane. And one of us wants to push a commit from a bike.

The [State of Mozilla Annual report](http://www.mozilla.org/en-US/foundation/annualreport/2010/faq/) answers this question very nicely. The report also gives actual numbers for 2010. >The majority of Mozillas revenue is generated from search functionality included in our Firefox product through all major search partners including Google, Bing, Yahoo, Yandex, Amazon, Ebay and others. Mozillas reported revenues also include very important individual and corporate donations and grants as well as other forms of income from our investable assets.

Cannot talk specifics but, suffice it to say Mozilla pays well

This question implies that you have already been accepted as an intern (correct me if I'm wrong), so that would assume you have shown that you can work in a team, are interested in the things we are doing, and that have written some relevant code. If you want to get a head start on the code side, familiarize yourself with Python and Django, as well as HTML / CSS and JavaScript. You will, however, get plenty of code reviews and advice, so don't panic :) You are also welcome to pick any Mozilla website you find interesting and take a look at its code, ask questions, maybe even file a bug or submit a patch. Also, go ahead and find us on IRC (http://irc.mozilla.org for instructions, channel #webdev) and say hi! Looking forward to meeting you soon :)

Bachelor of Science in Microbiology, minor in chemistry Master of Science in Management Information Systems

I'm not sure if there is any formal qualification *required* but a CS degree is probably helpful. Of course if you demonstrate your skill otherwise (e.g. write software that finds lots of flaws in our code or start working on our code and doing an awesome job there), then the chances are good to be taken as an intern or employee.

Participate. Mozilla is a very open company for this sort of work. See the other threads about contributing. If you have a coding related project, Mozilla has been a participant in every [Google Summer of Code](https://code.google.com/soc/) so far. Member orgs are announced in January or February. For previous GSoC info see https://wiki.mozilla.org/Community:SummerOfCode11 and play with the year.

Long career in security found a job posting on the Mozilla web site, applied and got it. I have been involved in security/computers for 31 years.

We certainly *think like* attackers. When we go through airport security, we have to be careful not to talk about how easy it would be to bypass their rules or create havoc. I don't know if my colleagues have *been* attackers, but I wouldn't be surprised if they have. When I was in high school, I pulled off some IRC-related attacks, such as MITMing sex chat participants and writing an mIRC script.ini virus.

1) Not for me, I love the challenge 2) There is a group that meets to determine that given the published critera. 3) If there had we would have made it public had it impacted sensitive user data (I think, I am not infrasec). As that is just the way we roll. 4) Not that I am aware of, we think every user regardless of who they are or work for should have the safest experience we can provide. 5) Really varies, I am a PM so I focus on PM types skills, how a person thinks and reacts to situations and people. Can they think like an attacker to find security issues, that kind of stuff. You're welcome, we share what we can without putting users at risk.

Not in my experience, we generally are prepared for things and expect things to go wrong at some point. That is the nature of security, the attackers generally have the advantage over defenders. As such we prepare contingencies, and contingencies for contingencies in some cases. And my job especially is to try and build a process that finds them and fixes them before we ship them so they never become huge problems.

I am not in HR, but if you are interested, here is the place to look for intern stuff: https://blog.mozilla.com/interns/join-mozilla/

Launch a startup, thats what all the cool kids are doing! (j/k) Really though, my experience has been that the deciding factor in finding a good tech job are the following: - Experience; proof that you can do what you say you can - Communication; the ability to explain yourself, your achievements, and your ideas, and the ability to sell yourself which is critical to get buy-in for your ideas, especially if they are disruptive to the business/industry - Cooperation; the ability to play well with others. Not just collaboration, but the ability to promote yourself, your team, and turn opportunities for personal success into win-win situations for everyone involved Other than that, hard work :)

That is so not an issue. Virtually everyone at Mozilla uses a range of browsers, for a variety of reasons. Firefox is our flagship product, but Mozilla's mission is about promoting the Open Web, saying only use our product is not consistent with that!

1. The hierarchy that exists is largely there for management purposes. The organization is run as a meritocracy; it doesn't matter if you are a day 1 new hire, if you have a good idea, you are encouraged to voice it! As an organization one of our important values is the ability to communicate openly and honestly about the challenges we face as an organization, and in the products we build. For individual projects teams are highly dynamic, and we bring in the resources that are required from other teams. 2. Although we have product owners and leads, the community (both employees and contributors) and our users inform the decisions that are made about bugs and features.

I worked for a very large financial institution. The most stressful part is deciding to work from the office or from home... today I chose to work from home for the morning... now I have to decide wether or not to keep answering questions, or head to our office for a team lunch! (Hint: to keep me answering questions, upvote this!) TYPE HTTP**S** Several departments of the US Department of Homeland Security, your ISP, anyone interested enough to sniff your traffic, and if you are in a coffee shop, that skeevy looking person in the corner. Did you forget to connect with a VPN? Mint Chocolate Chip Your welcome!

1) So awesome... The work we do is really cool (we get to play with all the new technologies), we can talk about the work we do (we are actually challenged by the amount of content to review to make public since opening stuff up takes time away from securing stuff!), and we get to support open technologies. The thing that makes Mozilla such a great place to work is the community. Every time I sit down and talk with people at a Mozilla office (in Mountain View, San Francisco, or here in Vancouver), I always come away feeling like I have learned something or have some inspiration for some new project. 2) The biggest concern we have related to risk is the impact our decisions have on our users. Whether that risk is to privacy, the integrity of the systems that host our user data and the systems that distribute our products to end users, or the integrity and security of our users devices, every security and privacy decision we make is made in consideration of the users. 3) Nothing too unusual here at Mozilla. I have found bugs in access control software that allows me to open and close doors on buildings, which was cool :D

On the front lines of cyber space our minds are the weapon.. or something like that...

When I interview candidates (which is often, because we are always growing!, shameless plug: http://www.mozilla.org/en-US/about/careers.html ), I look for the depth of technical knowledge, the ability to communicate effectively, and the ability to adapt quickly. In addition to those things, a candidate needs to be "a good fit"; they have to have values and ideals that are consistent with the core Mozilla mission, or be open to adopting those ideals. In particular, for technical skills, it is critical to be able to explain how multiple vulnerability classes work, and not just the common cases. Being able to explain modern security challenges or newer browser/server/operating system security controls and weaknesses is valuable too. Not at the expense of building a solid technical base, but you really, really need to understand risk management. I refer to my time in the finance sector as a technical backwater, but the risk management skills and focus that I picked up there was very valuable to me, and is something that is not always easy for people to learn. Being able to go beyond the typical ALE style risk equations and understand the role of threats to the business helps alot. EDIT: Reddit, why u no like numbered lists?

The rapid release cycle is confusing for some users, but the biggest reason for that is most likely the need for intervention during an upgrade. Some time very soon we will provide a silent update feature that will remove many of those headaches for non-technical users. As for the release cycle, it makes some aspects easier; since we have regular feature freezes and we know that a new release is coming soon we can a) focus effort on features that are going to ship in the next couple of releases, and b) hold a feature back for a release if there are security (or other) concerns since we know that there will be another release soon. It takes some adjustment, but it really is better for our users since it allows us to focus on improving the quality and feature set of Firefox in discrete steps instead of monolithic upgrades.

1) Securing passwords in a user friendly way. Doesn't matter if it is in government, finance, or even in a technical community. Password management (including generation and storage of credentials) is very challenging due to the human element. 2) Yep. I have profiles for Firefox, Aurora, and Nightly, each one with its own set of plugins. I also use Chrome, Safari, and every version of IE back to 6 since I need to verify if bugs in web applications are exploitable in these products. 3) I am based in Vancouver, so I am not 100% sure, let me find out!