Four years at Wikimedia Foundation

2022-07-19 22:48:59 +0200 +0200

Last month I celebrated four years of working at Wikimedia Foundation. 🎂🥳✨

That’s eons in tech, so to commemorate this milestone, here’s a post with four notes about these years–plus a bonus, fifth announcement at the end! 😉

1. Getting hired

I wasn’t looking for a new job, but the ad on StackOverflow caught my eye: work at the Wikimedia Foundation (WMF) and build user-facing feature on Wikipedia. Ok, that sounds cool! I of course knew about Wikipedia but didn’t know about the WMF. Working on such a huge project seemed out of reach for me. But I read on. And the more I read, the more I became committed to trying to land a job there.

I prepared my CV and cover letter and applied for, um, two jobs: one on the core team, and one on the collaboration team.1 The hiring manager thought I’d be a candidate for an engineering manager opening, so somehow I ended up on an interview circuit for three jobs 😅. (Pro-tip: don’t do this to yourself.)

There were many interviews. And a take-home coding exercise, which I really appreciated, having totally bombed a whiteboard style interview at a Durham-based startup ~2 years earlier, something that still gives me anxiety when I remember it.

About three months from the date of my application, I received a job offer: I’d be starting as a senior software engineer on the Collaboration team. I was ecstatic!


A couple of weeks later, I was at the Wikimedia Foundation’s office in San Francisco.


2. Getting started + hello, impostor syndrome

The beginning was a little chaotic. Onboarding is hard. Onboarding in software engineering is overwhelming. (We’ve made improvements to the process since I started here, but we can get better!) I wrote my first patch, and along with it, my first -1 and +2.


The label for -1 in Gerrit says: “There’s a problem with this change, please improve”. Sure enough, I got several -1s as I began submitting patches.

There’s a big learning curve to MediaWiki, the PHP framework behind Wikipedia. And then you also need time to learn the flavor and style that your team prefers, what the current best practice is, how that is perhaps not reflected in example code you’re looking at from two years ago, etc. Plus there’s a massive pile of acronyms and shorthand references to parts of the tech stack that people would refer to without necessarily explaining the background.

The combined effect was that self-doubt and impostor syndrome began to manifest. Was I really a “senior” software engineer? Did I belong here? Was I going to be able to contribute effectively? I am a self-taught web developer, who until then had mostly worked on Drupal projects at smaller companies for small-to-medium sized websites. Now I was working on one of the top-ten websites. Many of my colleagues had computer science degrees, or had years of experience in Silicon Valley startups. Could I keep up?

I don’t have some epiphany where I overcame these feelings, and these doubts resurfaced when I was promoted to Staff engineer last year. But eventually I became more comfortable saying “I don’t know”, acknowledging & learning from my mistakes, and understanding my limits, while also becoming more certain of my abilities and experience. Having gone through this type of thing myself, I try to support new colleagues to make the first months less stressful, but I don’t think there are easy solutions.

3. Solving puzzles

The new(ish!) CEO of WMF, Maryana, likes to talk about puzzles that face the Wikimedia movement:

[…] I have chosen to describe what I heard so far as “puzzles” because they will require collective ingenuity and shared problem-solving if we are to achieve ambitious aspirations and tackle complex challenges

I think “puzzles” are a good framing. From an individual contributor engineer standpoint, there are indeed many to solve. One thing I like about working here is that there’s a vast number of challenges and tasks.

A corollary to that: pretty much any idea you can think of, you will find a Phabricator task for. Thinking creatively and strategically about how to build features upon whilst also improving a 19-year-old codebase is a fun (most of the time!) challenge. And given our mission to “Imagine a world in which every single person on the planet is given free access to the sum of all human knowledge”, I’m incredibly privileged and fortunate to be engaging with challenges that have this kind of global impact.

4. Moving the needle

Since I started at WMF, I’ve been on the Growth team. My team’s mission is to increase new editor retention through building software to support newcomers. Most people who edit Wikipedia will do a single edit and don’t continue. We try to activate more users by getting them to make the first edit, and retain them so that first-time editors can become regular contributors.

We’ve built some neat features that are completely different from what the newcomer onboarding experience was like a few years ago:


…plus lots more too. Some milestones as of late:

5. What’s next

I’m excited for our next project, Positive reinforcement, where we will focus more on providing direct feedback and support to newcomers, so new editors can feel better recognized for their work. And, my team is hiring a senior software engineer–if the above sounds interesting to you, I’d love to chat!

  1. “Fun” anecdote and first WMF debugging story: the recruiter wrote to ask if I wanted a call, but my emails kept bouncing back. I couldn’t figure out why and was getting super stressed–this amazing opportunity was potentially open to me, but I couldn’t communicate to say I wanted to pursue it! Eventually I realized that my Fastmail email was bouncing due to too-strict rules on WMF’s side, and when I wrote with a Gmail address everything went fine. ↩︎