I crammed for a job at Canonical and this is what I learned

I recently jumped through the hoops that are the Canonical world famous hiring process. Here is the good, the bad, and the ugly.

Note: I published this with Canonical’s express permission!

Me, jumping through the hoops.

1. The beginning

I was attracted to Canonical’s job posting in UX because Canonical is the company behind Ubuntu. I have dabbled in Ubuntu myself, and I am a big fan of open source projects. Ubuntu completely changed the face of Linux and made it accessible for anyone. They also continue innovating and creating more products and services, maintaining that fresh start up culture of growth and open source. Now, that is a company I want to work for!

Additionally, they have a full remote culture: I understand office working has its perks, and is sometimes necessary, but as a person who spends most of my time in my current role in front of a computer, talking to people all over the world, I don’t see why I cannot do it from the comfort of my home.

I really cannot fathom why companies are reversing to office office, after such strides had been made towards remote during Covid! And don’t tell me about employee productivity and whatnot: it’s the manager’s job to understand the time needs for a role. If employees are slacking off on the job, there is either a misconception of the workload, or a lack of accountability. But I digress.

Here is the link to their career site, in case you want to, too! But I advise to read all the way through before.

The first step was a relatively straightforward CV upload, plus some questions. Some questions that, I might add, foreshadowed the coming steps. There was your usual “Describe your most complex web design project”, but also some questions about how you performed in high school. We will get back to this.

After applying, I got a response within 4 days that I was being moved to the next stage. I basically cried when I got the email. We are so accustomed in the applying world to never hearing back, or getting automised responses months after, this was truly a breath of fresh air. Kudos to Canonical for showing this decency.

2. The written interview

Don’t get too excited: there is still much road ahead.

Canonical has a system whereby you complete a written interview, anonymously, so that there is no bias in the evaluation. They only judge your answers by the content, not by the candidate’s experience. I love this concept, since I feel like I have a lot to offer, and being reduced to my resume is devastating sometimes.

But sending over a CV is a piece of cake compared to this written interview. Here are the questions I got:

UX experience

• Please describe a case where you found a simple solution to a complex problem.
• Please describe a change you implemented in your current team or organisation to meet the needs of your users. What has been the result?
• Describe any experience you have designing for expert, technical users. How do you think you need to adapt your design thinking for this audience?
• How do you balance deep thinking and long term strategy with rapid iterations?
• Explain your use of a design system. How did it move you forward, and how did it hold you back?
• Describe the ways in which you, as a designer, typically collaborate with engineering colleagues. What are the opportunities and pitfalls?

Education

We are looking for candidates who have excelled academically and ask candidates to give us a sense of their academic performance and strengths.

• In high school, how did you rank competitively in maths and hard sciences? Which was your strongest?
• In high school, how did you rank competitively in languages and the arts? Which was your strongest?
• What sort of high school student were you? Outside of class, what were your interests and hobbies? What would your high school peers remember you for, if we asked them
• Which university and degree did you choose? What others did you consider, and why did you select that one?
• At university, did you do particularly well at any area of your degree?
• Overall, what was your degree result and how did that reflect on your ability?
• In high school and university, what did you achieve that was exceptional?
• What leadership roles did you take on during your education?

Context

• Outline your thoughts on the mission of Canonical. What is it about the company’s purpose and goals which is most appealing to you? What is risky or unappealing?
• Why do you most want to work for Canonical?
• Who do you think are Canonical’s most significant competitors, and what do we need to improve in order to be a more effective player?
• Which Canonical products and services would you most like to work on?

Needless to say, it was basically an essay (write a comment if you want my answers). I think part of it is filtering out people who won’t take the time. I respect that. I go through it by thinking, if I don’t get it, it’s still good practice to think about these questions.

And, as promised, look at all the questions about high school. I thought this was because I am applying for a junior position, but went down a Reddit rabbit hole and apparently these questions are common to even senior developer positions.

Once I handed in the written interview, I got a reply the next day to proceed to the following step. Something tells me they don’t look into it too much!

3. The tests

Now come standardised tests stage. This is the official test page.

The GIA is not complex (like the really convoluted consulting firm figure sequence tests), but it is important to answer fast and accurately. There are some example tests I recommend taking. It consists of 5 parts:

1. Reasoning: there is a statement comparing two people, for example, Claus is heavier than Muriel. Then the statement disappears and you have to answer a question, for example, who is lighter.
2. Perceptual speed: you look at pairings of letters (caps and non caps) and determine if they are the same letter. You answer how many matching pairs you see.
3. Number speed and accuracy: they give you 3 numbers. You need to first identify the highest and lowest number. Next, figure out which one has the highest difference with the remaining number. That is the answer.
4. Word meaning: they give you three words, and you need to select the odd one out.
5. Spatial visualisation: they give you 3 shape pairs. The shapes are either the same, or mirror images, but they are rotated so it is harder to tell. You need to figure out how many equal pairs there are.

I scored above average in all tests, except the number speed and accuracy test.

However, I am ready to admit I am terrible at mental math, I rely heavily on calculators. Looking back, here is my tip if you struggle with this as well: prepare an excel spreadsheet, fill it with 3 rows of random numbers, and practice with that homemade test before taking the real one. I almost wrote the recruiter, hoping I could explain it away somehow, but before I could embarrass myself further, I got an email saying I was moving to the interview stage.

Another test that will come up later, before the interview with talent management, is the behavioural assessment, where you are presented with 24 slides of four words each, and in each slide you must chose the one that least and most describes you.

The scoring method for the Thomas PPA test is based on the DISC model. These four letters represent an acronym of the four fundamental personality traits used to produce your profile: Dominance, Influence, Steadiness, and Compliance.

Of course, this is a personality test: you can’t prepare for it in the way you can prepare a math test, there are no really right or wrong answers. Or are there? The thing is, depending on the job position, a personality type can be more or less desirable.

You should first identify what personality type the position might require: in the case of UX, I would go for Influence (outgoing, enthusiastic, high spirited, lively), and to a lesser degree Contentious (this is what I infer from this website, although I would say a little bit of Dominance is more in character). Probably the least desirable personality would be Steadiness, where there is no creativity or proactiveness. Again, it’s really hard to put a finger on it but, by understanding how the scoring works and what the words represent, you can make informed choices rather than desperately grasping in the dark.

In every slide with 4 words, try to determine which one belongs to which personality type.

All this being said, don’t go crazy trying to over analyse your responses. There is no way to know exactly what they want. If your personality is really not what they need, you can also see it as a sign that this is not the job for you!

4. The actual interviews

At this stage, you get an email asking you for slots. Again, a very well executed process, as I was able to select all the times in the next two weeks when I would be free. A few hours after submitting my schedule, I had my interview dates!

Yes, plural: right off the bat, you are scheduled with 3 interviews:

1. Design growth mindset
2. UX skills assessment
3. Web team interaction

And that’s not all. Once you are done with those, if you pass onto the next stage you get

4. Talent management team

5. UX Challenge

6. Management

After that, if the decision is a unanimous yes or no, you are in or out respectively. If it is ambiguous, you get another interview with:

7. Hiring manager

And maybe even

8. The CEO (you read me right, sometimes Mark Shuttleworth choses a candidate at random and interviews them, too!)

Now, what you have been waiting fore: the juicy interview details, and how I navigated them!

What not to do XD

Growth mindset

First, I figured out what growth mindset is, and what it means for design. A person who possesses a growth mindset believes they can always learn more information and skills if they work hard. You don’t have a notion that some people are born talented, and others are not. You learn from experiences and you build on them.

So what does this mean for design? It means you see every design challenge as an opportunity to improve and learn something new. You look back at your previous designs and take note of what worked, and what didn’t. You iterate on your work and are not scared to admit its flaws and change them for the better.

The typical question in this scenario is something like “what would you change about how you approach designs”. It’s important to talk a little about what you do right (this is a job interview, after all), but what they are looking for is reflection on your part about what you could do better. It’s the fact that you know you have not reached your peak. This is similar to a question I was asked, regarding what I have learned from past experience that I now implement in my process.

It’s also about adapting. How do you react to changing situations? Again, always have examples at hand, even if it means bending the truth a little: it’s all about how you would manage a situation, what your approach towards change is, even if you haven’t exactly had the best chances to show it yet.

As a designer, you should be learning new things continuously. It’s important to stay up to date with design tools and trends. It takes work and effort, but once you start doing it you quickly reap the benefits. Additionally, if you are really passionate about design, you will effortlessly fall into deep dives about new theories, and be looking for ways to ease and aid your design process with the latest tools. If not, I would consider a different field. This is not a dig: there is no shame in being made for something else. And employers can tell.

But don’t panic, even if you haven’t had time to read 20+ design books and form educated opinions on them, just think of all the tools you use. What new features have you taken the time to learn lately about Figma? For your last project, did you do research for some aspect, like how to make the best log in? Think of all the times you looked into some niche aspect of design in order to make the best UX out there.

This point also relates to knowing what challenges lie in the horizon. Are you preparing for them? For example, how tools are becoming more accessible to the general public lately. Nobody has the patience to learn how to use a program, everything is plug and play. How will you contemplate this in your designs? How do you design for this low attention span, low patience audience? How will you drive more engagement? You should prepare your answers for the problems you see coming.

A question that appears in GitLab interviews is regarding apps currently out in the market that you like, and dislike. I think this is a great question because you can show that you are always thinking about UX, even when you are the end user. Also, you should prepare a statement about how you would improve what you don’t like about the app (criticising is easier than doing). As a bonus, what you like about the apps you approve of, and how you would incorporate these good things into your own design.

Growth, as the word indicates, is about looking into the future. It’s important to learn from past experiences, in favour of improving future ones. What are your long term goals as a UX designer? Think about where you want to be in the future. Think about the context; are you preparing for change?

I imagine myself as a designer who uses these tools to free up time to think deeply about the consumer. I want to harness AI in favour of creating products we never thought were possible, and improving people’s lives through them. I want to work on cutting edge technology, and I imagine myself creating unique experiences through collaborating and learning from others. I want feel comfortable enough with my skills to push boundaries without compromising the user.

Finally, it’s about innovation. How do you innovate within constraints? And can you think about a situation where you found a solution to a problem by thinking outside of the box? Think about Tinder’s swiping gesture. Whatever moral quality you chose to attribute to this, they were pioneers in this simple way to like or reject someone. It was probably one of the reasons for their success, this gamification of the act of looking for a suitable match online, and it was truly out of the box thinking because no other company had done this before.

What is asked is bound to vary, but some questions I got here were

• How I present projects or implementations to stakeholders and the like (I said that I like to present the impact first).
• If and how I dealt with data pointing clearly towards a solution, but receiving pushback from implementing it from the decision makers
• How I communicate with the team
• What tools I use to manage pending tasks and completed actions (look up agile team tools and use them if you still have not). At Canonical, they use Mattermost.

BONUS: they will want to tell you about the role and about Canonical. Have some questions ready for them, make them frank: what do you want to know about the place you will potentially work in? This shows you care about the position, and is also a great opportunity for you to evaluate them!

UX skills assessment

By Abby Sanders

This is the classic portfolio review interview: you go through your portfolio while someone from Canonical looks at you. You probably already have a portfolio you applied with, but consider polishing it even more, to make it suitable for a role at Canonical (as general advice, if your portfolio is a website, create a PDF as well to cater to the specific company you are applying to). Here is the Figma portfolio I made for the interview.

Usually, they have already quickly scanned your portfolio, but this is your one chance to really impress them. Take it, and give them your best. Add cases they might find interesting, details that they would appreciate (for example, if you have a more technically complex project, show how you managed that complexity, as Canonical is a tech heavy company).

I would change some things in how I approached this interview. I invested a lot of time in making my portfolio look great and, although the interviewer verbally and pointedly appreciated it, I wish I had practiced talking through it more. It was strange to look at my own screen and not at his reactions while I presented (this is the unfortunate nature of Google Meet). It felt like a monologue, and that made me nervous so I tripped up a couple of times. I tried to pause for comment here and there, but should have taken a few more breaths.

Another very good point my interviewer made was that I was missing more of the raw process: he wanted to see my post its, and the raw competitor analysis. I didn’t want to show this because it ruined my “aesthetic”, and when he asked to see my original material, I didn’t have it at hand, or what I had would have made me look worse. The reason is he could tell I knew the process, but was probably not convinced I understood it as there was no personal touch.

He then asked me how I would deal with technically complex projects: here, I said I would consult a lot with the engineers, and keep the dialogue open to understand the needs of the user. Again, it is important to think about what Canonical wants, and how you could be a good fit for them.

Bottom line: practice with someone, or even alone, to actually present the portfolio in one hour. While I was presenting mine, I could hear some gaps in my speech that I could have prepared for had I practiced more.

Secondly, show how you approach all the classic steps in the projects, show the dirty stuff, and if you are worried how it might look, maybe just throw it all at the end like a mad collage. It’s better than them thinking you haven’t done the real work.

Finally, think about what you bring to the table. Think about what relevant experience you have you could translate to Canonical. I know it’s not always easy to have all the experience you need when you are a junior. However, even seemingly unrelated positions or projects you may have had can teach you valuable skills you can use in the future. And if you are really passionate about this field, you are constantly looking for opportunities to develop your skills and knowledge.

Web team interaction

This is an interview with one of the engineers in the Web team with the objective of understanding your knowledge and experience working in an agile development environment.

As a junior, it can be hard to have hands on agile experience. I recommend you really familiarise yourself with the process and the jargon of agile, as well as trying out tools like JIRA to get an idea of what an agile team’s organisation looks like.

For those of you who have some time to prepare, you can start applying the Agile (and more specifically, Scrum) method to your daily routine. If you work with a developer, or even on your own, you can start by creating themes (it’s like a category for the work you have to do, for example, screens, or marketing for your app), then split the themes into epics (for example, for the screen theme, you can have profile, log in, etc.), and later split those epics into user stories (for example, for the profile, the user wants to be able to log in with Google, or edit their profile). Finally, you get to the tasks, in other words, specifically what you must do.

Perhaps you already follow a similar methodology, but you just don’t call it Agile! Once you have your task list, or backlog, you can think about your sprints. Usually, sprints can last about two weeks, and you should have something to show by the end of them. Basically, you take some tasks from your backlog, and you put them on your to do list. If there are more team members, you can assign each task to the person responsible. When you start working on a task, you move to ‘in progress’. When you finish the task, you move to ‘ready for testing’. When you have tested, you move to ‘complete’. Depending on how the team classifies complete, or testing period, these last two categories might change, but you catch the gist.

And how do you know which and how many tasks to put into the sprint? Well, first off you need to give the tasks a time estimate. This is hard at first, but after some practice you get the hang of it. In Agile, efforts are usually represented by points. For example, you determine you can complete 9 points per sprint, so you could complete three tasks of three points each.

Secondly, prioritise, by determining your MVP (minimum viable product). What do you absolutely need to have a working app? If that is still too much to do in two weeks, you can additionally decide the order of progress by imagining the structure of the app (what sequence does the user see the screens in). Or, you could decide which the least effort tasks are to get done first. This is really up to you, at this point you just need to fit the tasks into your sprint schedule. This would be the planning phase.

There are a bunch of other buzz words, like retrospective, scrum master, product owner, etc. etc. Do some reading if you are not familiar with the process, but mostly try it out for yourself. Agile is about, forgive the redundancy, being agile. You should be able to adapt to the situation at hand. If your team is way too small to have all these actors, and it really isn’t worth it, then you don’t need to follow it like a dogma. Sometimes, daily stand-ups don’t make sense for your specific project or team. Don’t be scared to say this in the interview: in fact, as long as you know the reasons, I encourage you to talk as much as you can about how adaptable you are. This is the magic of agile, being able to adapt quickly to changing situations.

In this interview I got asked questions about how I managed workloads, what I liked most and least about working in small teams, and how I worked with developers. Some questions caught me a little by surprise, like:

• How is your team now, and how would you like your team to be in Canonical?
• What do you think about accessibility?
• What do you think about website performance?

I also mentioned I work with a sort of draft backlog on a shared Excel sheet, and he actually asked me to see it. I think this was great for my interview (I am proud of my obsessive organisational skills), and I add it as a cautionary tale about lying regarding your process (you can always say it’s proprietary, but again, I at least recommend playing around on JIRA and having something to show).

Talent management

This interview will consist of three discussions:

1. Career history: Chronological walk through of your resume (30 minutes)
2. Behavioural interview (20 minutes)
3. Working with Canonical (FAQs) (10 minutes)

The walk through your resume is pretty self explanatory: tell them about the different job positions you had, and be ready to answer the questions they might have about them. Be sure to review your resume for …exaggerations of reality. Don’t lie during the interview, but create compelling stories using your unique experiences to support your self aggrandising. It’s an interview after all: that’s what you are expected to do!

Another aspect to prepare is looking at the metrics you have (hopefully) included in your resume. If you say you achieved a 20% growth in sales, be ready to explain how you did it. The great thing about a resume interview is that you have the questions right in your hand, you know what they will ask about. Don’t waste the opportunity!

The behavioural interview is trickier. For this section be prepared to answer some competency based interview questions. These will require you to think of some specific examples that highlight your experience or skill in a particular area. A specific example for each question will allow you to demonstrate how you handled a situation and what your approach was. This is a meeting with HR, so the questions will not be very skill focused or technical, but more behavioural.

It’s key to think about what competencies are needed in the role. Some of the competencies needed as a UX designer:

• you are often required to compromise, or find solutions within given constraints.
• Adapting and pivoting your approach: you must show flexibility as a UX designer, as it is a field with constant change.
• Communicating effectively with stakeholders.
• Being a team player, working effectively with all types of people, even difficult ones.
• Receiving feedback positively, incorporating it into your work and being open to starting from scratch if evidence shows you should.

To answer these questions, the best way is to structure them is using the STAR method, which outlines:

• Situation
• Task
• Action
• Result

For example:

Here are some of the questions I was asked:

• Tell me about a situation where you resolved a disagreement with someone.
• How have you dealt with difficult people?
• Tell me about a time when a deliverable you handed in was not up to par.
• What are the challenges in your current position?
• Tell me about some successes in your current role.
• Why did you decide to apply to your previous role?

Finally, for the interview, be ready to answer:

• Your availability to commence work should you be successful
• The location that you would be based in with confirmation of the relevant right to work status
• Your salary expectations for this role should you be successful: fear not this question! I have a good way to answer it. First, stop and breathe. Next, ask them what their approved range for the position is. If they can’t really say, give them your own range. You can even say that you are currently interviewing for roles with salaries in this range. This should be based on your current salary, and/or the average salary paid for that position in the country you will be based in. Remember to emphasise that your range is flexible. This is a tricky question, I know: you are scared that they might lowball you, or write you off as too expensive. That is why, you should try to base your answer on their budget, and say you are flexible (maybe depending on other benefits) so they know they could still work something out with you, in case their budget is lower.

UX Challenge

Yes, there is more. I got two exercises to work on, and present in an interview.

1. Canonical products — juju.is

They wanted me to understand the product, and explain it back to them. You could present using your own words, and any of: whiteboard sketch, a sketch.app file, a sharpie-drawn flip-chart poster, or a (few) slides, etc.

Juju is a product for technical users. This task is a test of your ability to communicate it’s proposition using visuals and language.

As a plus, feel free to suggest amendments to the existing website.

2. The “Timesheet” UX challenge

You work as a UX lead in a large organisation. A stakeholder brings a new project, at an early stage: an internal timesheet system for employees and contractors is being considered.

Business issues:

• Some teams are failing to complete work in timescales close to their estimates.
• Some work for customers which are billed with an hourly or daily element, others don’t.
• Senior management say they “want to know what staff are actually spending time on.” They become misty-eyed about dashboards and actionable KPIs.
• There are existing systems for Secure login, HR — Leave, Sales — leads, customers and projects, and Accounting: billing and costs. In a perfect world, everything would seamlessly connect.

Challenges:

• Some teams, e.g. legal are comfortable with hourly billing from previous careers. Other teams are allergic to timesheets — “We’re agile, it’s done when it’s done.”
• Some staff are dedicated to particular work, others move across internal and external projects.

Your task:

• Briefly explain your process to solve “the timesheet” problem, at a high level; your sequence of activities and methods. (2 mins)
• Show one or two early ux/design ideas, e.g. an approach to the information architecture, user flow, or a key piece of information design or perhaps an important interaction detail. You will have to make some assumptions — that’s fine. (10 mins)

They’re interested to see the way you work. They tell you not to try to bring a complete or finished solution, because it’s too big and too early for that. They want to understand your design-thinking and see a little of your craft.

Of course, this doesn’t mean that they want you to bring something basic. My big problem with this task was that I managed my time VERY badly and ended up producing all of the work in a day or two, sabotaging myself as one does.

Here is a bit of my solution to the first challenge:

To see the full solution, please message me!

I did a simple drawing explanation plus a comic book type story which described how Juju simplified your life in every step of creating, for example, a blog.

They asked me who my audience was, because the explanation was very simplified.

They also asked me how I had gone about researching it. I said I had tried to understand how I would use it.

For my website corrections, they asked if they would really have a big impact on increase in people using it. I told them probably not, if their audience was very techy (as my corrections were a little usability, but also about breaking up chunks of information into more digestible and understandable pieces). I spoke about my experience in procurement, and how sometimes the final decision for purchasing a product came from people who had little to no expert knowledge on what they were buying. I also said that they could loose potential customers who were dipping their toes in Juju, and could be easily spooked by the daunting site.

However, I also admitted that some of my corrections were more minute details than actual high impact items. There is no shame in saying that you don’t have the answer to everything.

I also mentioned that the website has a lot of jargon, and they asked if I could differentiate between the Canonical/Juju jargon and the usual tech jargon. I really could not beyond Charms, which is obviously a Juju thing.

For the second task, here is the link to my Figma file. We went through the process I did, and I showed them my solutions. Some of what they asked me:

• How would you challenge the stakeholders’ desires to make this solution?
• How expensive is this solution?
• If you had to do the bare minimum of the solution, what would that be?

Interview with the Head of Global Design

I had another interview schedules after this one, but this turned out to be the last one. The idea is that you only have the last one if there is some doubt (a definite yes or a definite no will make the process end here).

This interview is another conversation, similar to the first interview regarding design growth mindset. Again, prepare this interview like before. Think of experiences that you would like to highlight as growth moments and successes, think about Canonical and why you want to join, and think about your own questions to shoot back at them.

Some of the questions I was asked:

• If the company UX was divided into two teams, team A doing only user research and Team B doing only UX/UI type stuff, would be in group A or B?
• What is UX for you?
• Why would people think that you are a tech person, other than you academic background (ie, what do you do in your daily life that supports this notion)? Advice: if you have Ubuntu installed in your device, SAY IT. If you dabble in programming, and building tools for yourself, SAY IT. I was shy to speak of this things, and it was included in my feedback.
• What attracts you about canonical’s mission?
• How would you explain canonical to someone who doesn’t know what it is, and is not a tech savvy person (ie, your mom)? How would you explain to that person why you want to work here?
• For what persona (of Canonical’s main clients) would you want to work for? He mentioned three examples: the software developer, the cloud architect, or the system orchestrator. Don’t say “Ubuntu user”: that’s too basic.
• What are you proud of that you accomplished?
• What kind of person would you have a problem with in a work environment? How do you deal with it?
• How would developers you worked with describe you in a few words? Tip: say two positives and one negative. It’s always good to show self reflection!
• If AI could do anything and you had a startup, what parts of the design process would you delegate to this AI and which would you still do yourself?

The end!

And that’s as far as I got! After the final interview, I got an automatic email saying that the last interview would be cancelled, because after careful consideration I was not a good fit for the role.

They also told me they “are not able to provide specific feedback”. A little disappointing considering the time invested and the amount of interviews I had to go through. However, I answered asking for feedback either way (nothing to lose am I right?) and for permission to publish.

My overall feedback was that they went for profiles with “stronger tech backgrounds whose solutions to the challenges were overall more flushed out and who were able to explain them in very clear terms”.

My conclusion

To begin with, I am a bit disappointed in myself for handing in a half baked solution. I do feel that if I had managed my time better, I could have handed in something of much higher quality. I have to kick myself for screwing up being so close to the finish line. About the tech background, like I said before, I should have highlighted it without being shy!

Overall, the process was a great opportunity to practice interviewing, and to get feedback and have conversations with so many people who are so knowledgeable in the field. It’s, of course, very difficult to let go of the idea that you are being evaluated and to just ENJOY the conversations. This is why it’s a great chance to practice doing so.

I would do it all again, simply because I got:

• Interview practice
• A revised portfolio
• A new project for my portfolio
• A better understanding of a company I was already interested in

I am lucky I had time to do this, and could wait for the process. If this is you, go for it! (Or you can look at it like the monster I drew below).

Comedic illustration of Canonical interviewing process