How I landed Mozilla as a client (and why they called me back)

Most of my work comes through Toptal, so I rarely apply for jobs on Upwork. I don’t even check it that often.

Then, one ordinary day, two invitations landed in my inbox within a few hours of each other. One was from a well-known fintech company. The other was from Mozilla.

Both were looking for the same thing: someone for email production. That means building, coding and testing marketing emails, a niche most designers happily avoid.

I applied to both. The fintech company never replied. Mozilla invited me to an interview.

This is the story of how that interview turned into two contracts, and what I think made the difference.

A designer who also codes emails

First, a bit of context. I’m a designer first, with more than 20 years in the field. But somewhere along the way I learned to hand-code HTML emails, and I kept that skill alive alongside design work.

It’s an odd combination. Designers usually want nothing to do with email code, and email developers rarely care whether the logo is crisp.

That overlap turned out to be exactly what Mozilla needed. A member of their email team was going on parental leave, and they needed someone to cover for two months.

For context, I sent them my email design and development portfolio with the application.

Step 1: The interview

The video call was with three people: the head of the email team and two developers from the production team.

It was relaxed and friendly. They asked questions, I answered. It went well, except for one question where they clearly expected a specific answer and I gave a rather general one.

I remember thinking, “Well, that’s probably it.”

It wasn’t.

Step 2: “Can you send us some code?”

Next, they asked for examples of emails I had coded by hand.

Here’s the catch. Most of the email industry has moved to visual email builders, and so had my clients. I had written plenty of hand-coded HTML/CSS emails, but years earlier. That code was outdated, and I wasn’t going to send outdated code to Mozilla.

So I told them I’d send examples later that day. Then I sat down and coded three emails from scratch.

It took me the whole day. I sent them late that night.

Step 3: The test task, and where I decided to stand out

They liked the examples and sent a test task: an email full of code errors. Find them, fix them, and suggest improvements if you see any.

At this point I thought about the competition. Anyone who reached step three could fix syntax errors and add a few suggestions. If I sent back corrected code and a Google Doc full of comments, I’d look exactly like everyone else.

So instead, I recorded a video walking them through what I did and why.

Here’s what I covered, from “expected” to “nobody asked for this”:

1. Fixed the syntax errors and explained where each problem was and why my fix worked. This was the baseline.
2. Suggested five or six improvements. The email wasn’t responsive, and its structure wasn’t solid. Still within the brief.
3. Flagged email client issues. Some parts would break in certain email clients, Outlook especially. If you’ve ever coded emails, you know Outlook is everyone’s recurring nightmare. I proposed fixes for those too.
4. Made parts of the email accessible. For example, I adjusted colours so people with colour blindness could clearly tell elements apart. Accessibility matters more every year in both web and email design, and it definitely wasn’t in the task.

Because the original structure didn’t follow good standards, I also rebuilt the email with all those fixes applied. Then I sent them the updated email and the video.

I didn’t record every single change, since that would have been a very long video. I showed the key parts and explained what else I would do.

The reply came quickly: they loved it, and I was hired.

Getting hired was the start, not the finish line

Signing the contract didn’t change how I worked. For the whole two months I treated every email as if it were still part of the test.

In my last week, I fixed a few small things that I, as a designer, kept noticing in their emails. The logo was slightly pixelated. The social media icons weren’t aligned, and they were pixelated too.

Nothing dramatic. But it bothered me, and I didn’t want to leave without fixing it.

They really appreciated that. I also mentioned that design is my main field, in case they ever needed help there.

Then they called again

About a year later, Mozilla reached out again. They needed someone for email production once more, and this time the engagement lasted four months.

I didn’t apply or pitch. They simply remembered how the first project went.

Working with their team was a genuinely great experience. Professional, kind people who care about doing things properly. I’d happily work with them again.

What I’d tell anyone hiring (or applying)

Looking back, nothing I did was magic. It came down to three habits I bring to every project:

• Do the work properly, even when it takes all day. Three emails from scratch was a long day, but it showed what I can do today, not ten years ago.
• Explain your thinking. A short video turned a code fix into a conversation about quality, compatibility and accessibility.
• Fix what bothers you, even if nobody asked. A crisp logo and aligned icons are small details. Clients notice when someone cares about them.

That’s also how I work with every client today, whether it’s an email campaign, a Shopify store or a full website redesign.

If you think I could help you too, write to me. Whether you need emails that render properly everywhere or a design that pays attention to the details, you can reach me at hello@vladimirkoncos.com or take a look at my work at vladimirkoncos.com. If you prefer, you can also hire me through Toptal.