This week I am sharing a series of posts to reach design candidates in far-flung corners of the Internet to fill this UX/UI designer role at Mozilla Foundation, and to improve the quality of design candidates everywhere! Check this post for a listing of all the topics as I post them.

First: a warning. Everything I’m writing about over the next few days is dependent on a number of factors – who I am, who you are, what kind of organization I work at, what industry we’re in, what time of day it is and whether or not it is raining. Nothing is a rule. Please don’t do exactly what I tell you; adjust it as necessary. My main objective is to just offer insight, a small glimpse behind the hiring curtains, data points – so that you can go forward and make your own informed decisions about what to do or say, what not to do or say. If some of this advice helps you find a job, amazing, the Internet works! If it prevents you from getting a job, then Brett Gaylor my previous boss taught me everything I know. :)

Okay, now that the disclaimer is out of the way!

Tomorrow we’ll get into the nitty gritty of how to be a better applicant, but today I wanted to start with outlining the hiring process. We’ve all been there as applicants, but not everyone’s been on the other side of the fence doing the hiring and it can be helpful to know how things look from the employer’s perspective. I’ll show you how it works on my team at Mozilla (other teams at Mozilla will be different).

For the record, “How does your hiring process work?” is also a perfectly legitimate question to ask in your first interview no matter where you are interviewing. It will help you avoid the stress of not knowing response timelines or how much time you need to set aside for future interviews or other activities you might be asked to do.

What happens before the job is posted?

Justifying that a new hire is needed to the powers that be can be a lengthy affair. I don’t fully understand every detail of it, but the gist is that at a company as big as Mozilla it isn’t as simple as factoring a new salary into the budget and posting the position. That’s part of it – employee costs at Mozilla have a huge financial algorithm behind them (salary, benefits, equipment, office space, travel expenses, setup costs, even snacks and meals, and then measuring that against existing and projected budgets) but there is also the factor of how new employees will fit into existing teams and strategic plans. That’s the part I have a better sense of.

In an ideal world, the amount of work a team needs to do will match perfectly with their ability to do so, which looks like that pretty straight green arrow on the graph below. There will not be too much work, and there will not be too little.


For this thought experiment lets focus on increasing capacity (rather than the less desirable alternative). The further that arrow moves right along the horizontal axis as the amount of work increases, so too must the team’s capacity increase in order to maintain a balance. When the capacity does not increase, that’s when you end up with a sad, droopy red line. This  might look like asking a team to keep working harder and harder but without hiring more staff. We’ve all been there. Green is the ideal. Red is the reality.


There may be better diagrams for this, but I think of that space between the red and green lines as stress. Stress on individual team members, stress on management and stress on the organization as a whole. The problem with stress is that it jeopardizes any work you’re actually managing to get out the door, and typically it stresses your best employees who are the ones that tend to take more responsibility for all the things falling into their laps.

Some stress on a team is healthy. Similar to how forcing design constraints can make people think more creatively, so too can limiting a team’s capacity; it forces hard decisions about priorities, it prevents people from going too far down rabbit holes (whether getting lost in details or working too much in isolation), and it can create a competitive and challenging environment that high achievers thrive in.


The trick to timing a new job posting well is to anticipate the point at which healthy stress becomes detrimental, and to make changes to address this as soon as possible. Generally, most people notice this too late – when someone has turned in their resignation letter, when design begins looking lackluster, or when complaints rise to an annoying din. Our goal on the Mozilla Foundation’s design team (especially in this period of product growth) is to plan well and create a repeatable, efficient process – both for design in general and for hiring.

The other basics to understand are this:

  • Good job descriptions are both well-written and well-thought-out. They address a clear need in the team. So hiring managers should be able to easily answer a question from an interviewee about what projects they would be working on, at least in the short-term.
  • I wrote the job description, not a robot. It wasn’t taken from a template site. And since I am human it’s definitely not perfect. Feel free to challenge me on any of the assumptions. For instance if you don’t think you need to know UX design and UI design and animation, please, convince me why and tell me how you could still do the job.
  • Many conversations happen before a new position is posted. I talk with my team, my manager, our HR manager, and often other team leads to assess everything from whether or not we actually need another person to what kind of skills we need. By the time actually posting the job surfaces on my to-do list, it is one of the final steps in the process. I point this out mainly to illustrate the process’ complexity, which might come in handy when you are thinking about how to negotiate your contract.

What happens when you apply?

If someone applies at Mozilla, they submit their résumé and cover letter through Jobvite. Jobvite recognizes me as the hiring manager for this position and so I get email notifications for every applicant, which I typically look at in a filtered list in Mail. What Jobvite includes is the cover letter and résumé. I might skip the résumé as it generally looks junky by the time it arrives in my inbox, so most of the time I just scan the cover letter looking for a link to your portfolio. I love people who make this easy for me by including a link in their cover letter!


I do skim every cover letter and open up every link I receive unless there is something clearly wrong with the application (e.g. the letter isn’t written in English, or the applicant is not within our hiring jurisdictions which we state very clearly on the job posting – currently US, Canada and the UK).

Often I spend less than five seconds on a portfolio, and probably less than a minute on most applicants in general. But I do look! I am very proud of that – I doubt most people even look past a bad cover letter.

More on that coming later this week but I will say that a well-done portfolio can hugely make up for a terrible cover letter. However, seeing both in great condition is what gets me really excited about a candidate.

What happens after you’re selected for an interview?


First interview

As the manager for the position being hired, sometimes I will conduct the first interview and other times I enlist help. This is where companies might typically use a recruiter but I like getting my hands dirty. The initial thing I’m looking for in the first interview is whether or not you’ve done your homework. Do you know what position you’ve applied for? Do you know anything about the Mozilla Foundation? It’s amazing how many talented applicants do not pass this first interview because they cannot speak to these questions. It seems really basic to me, but there it is. We obviously can’t justify moving forward with a candidate who hasn’t prepared for their first interview.


The first interview may seem slightly technical when I ask designers to walk me through a project in their portfolio, but this line of questioning is actually more about communication and personality than it is about the work. How well can you speak to the objectives of your work? How excited do you get when talking about it – are you mostly positive or negative? What seems to motivate you? Have you represented yourself accurately in your application materials? Are there opportunities here for me to figure out how well you work with others? This is probably the most stressful interview for a person, so while I actively attempt to put the candidate at ease and get them to see why Mozilla is an awesome and friendly place to work, it’s also a good chance to dig into how a person handles high-pressured situations.

A third part of the first interview is to figure out if you meet basic requirements for the position. We have a budget and want to know if your salary expectations fit, and we don’t want to waste time if this basic point of agreement is wildly off, so we will ask you this upfront. We also ask about where you would prefer to work (in an office or remotely) and we will want to make sure that occasional travel is okay with you (we currently travel around 2-4 times a year to work in person as a team). The ability to hit all these questions on the head is not necessarily a deal-breaker, but these answers are all super useful information to have to inform our decision-making. If you are ever wondering in an interview why I am asking a particular question, I am more than happy to oblige you with an answer.

Second interview

The second interview is much more technical. This is the point where we can really geek out about typography, illustration, photography, animation, copywriting or whatever you’re into. Sometimes I’ll do the second interview but often this is a great opportunity for you to meet another designer on our team. It’s worth saying that sometimes when you meet other people from the team they can be less experienced in interviewing candidates, so talking to you is actually practice for them. It’s hard to know just how experienced an interviewer is, and it shouldn’t change the way you should present yourself as they are still assessing your skills, but perhaps it makes it a little less nerve-wracking to know that everyone has the same kind of butterflies in their stomachs when meeting someone new for the first time.


It’s usually during this interview that the candidate starts to relax. They’re talking about their work, what they know, they have a slightly better idea of what they’re getting themselves into so their excitement starts to show and they generally ask better questions. I really enjoy second interviews both as a person doing the hiring and those times when I’ve been a candidate myself.

Moar interviews?!

Past the second interview, we are generally looking for any red flags: Does this person really know what they’re doing? Would they be a good cultural fit? How well do they handle stress, get along with others? Does their desired career path match up with what we can offer?


You are probably wondering, ‘How many interviews are there?’ In Mozilla’s case, typically at least three: one with the design team manager (me), another with a teammate (another designer or engineer), and a third with my boss, VP Product, David Ascher. More commonly I would say there are four or five interviews. I had six when I joined. We want to make sure we have a well-rounded picture of you from various perspectives and teams and we want to give you a chance to meet people and get a sense of who you would be working with. Interviews truly go both ways!

If all the interviews go well, we are ecstatic at this point. We’ll ask for three references – one from a previous manager, one from a peer, and a third of your choice – which we will do the legwork to follow up on. This is a very important step in the process and we take it seriously. Typically it is me doing the follow-up with these people as it is a great opportunity for me to figure out how I can better support you as a manager. What I ask references is another blog post for sure!


The debrief

After these boxes are ticked the entire hiring team will debrief and talk about you. It’s an uncomfortable prospect to think about, but it’s ultimately good for you. If you had a crappy day during one interview and were really tired, but came to life and gelled well with a team member during another interview, that stands out. We understand that interviews are not very much time to get to know someone and we take that into account by considering the experiences of all interviewers and doing our best to create a well-rounded picture of you and your skills. This debrief also helps us surface any discrepancies and figure out if we need to ask any harder questions or if we are prepared to make an offer.

The offer

By the time we make an offer you’ll usually know it’s coming. It is, hopefully, a moment of celebration for both of us! And it usually is pretty easy given we’ve discussed expectations upfront in that first interview and talked extensively by this point about what you’re looking for in your next position. In my experience when thinking about an offer, it has paid dividends to take a moment before accepting. Consider everything outside monetary compensation: the work-life balance, the work itself, the team, benefits, what your day-to-day will look like, and how you actually want to spend your days. It can be difficult to turn down an offer at this point after you’ve invested all this time in the application and interview process, but I’d rather that than hire an unhappy camper. That said we (I) have been turned down and it sucks! I know, boohoo employer, but I’m just telling you this because it presents an opportunity for you. The next section is about that.

A note about doing work before you’re hired

It seems everyone has a different opinion about this but here’s mine. On the plus side, contract work allows both employer and employee to get to know one another in a real working context before committing to a full-time position. On the downside, it favors candidates who are able to work in their spare time or who don’t need full-time benefits and can take the risk on you. We don’t have a clear stance as an organization, but I lean toward not doing it if at all possible. I would rather use the tools we have to assess someone’s work and character, despite that being difficult and not foolproof, because it seems more respectful to me and I’m usually confident in the final assessments. However, some teams ask candidates to fly to a city to meet the team in person (likely Vancouver or Toronto) for a final interview and in the odd case where we do hire someone on contract before we make a full-time offer we will always pay. These decisions are far from rote and are very situational, but whatever you do please don’t work for free, potential hire or not!

Hiring in waves

When we make an offer it is not guaranteed that the person will accept. We whittle candidates down to an elite small group and chose to pursue just one person, but when we make an offer and that person ultimately chooses to go somewhere else the hiring team goes back to the drawing board. It can be an exhausting turn of events. We sometimes revisit applicants who already applied, but in my experience that rarely works out and it’s usually better to start fresh.


So just because a position may have been posted for awhile is no reason not to apply. The team may just be starting to examine a new wave of applicants and you might be a needed breath of fresh air.

I hope that some of this has been insightful. It’s turned out to be much more long-winded than anticipated so I am going to go ahead and press publish, extra commas, grammar problems and all. I’d love to hear some experiences from other people whether from the hiring or the interviewing side and figure out ways to make our process better. Share in the comments or send me an email. Tomorrow I’ll share even more unsolicited advice for improving your cover letter and portfolio. Stay tuned!