Taro Logo
Profile picture

Canva

Okay

Senior Software Engineer
Former Employee
Worked at Canva for less than 1 year
March 18, 2026
3.0
Pros
  • Great office.
  • Excellent pay.
  • Reasonable onboarding process for general corporate things and general engineering things.
Cons
  • The team didn't use a structured container of work model, such as sprints.
  • The team didn't have daily video stand-ups, nor other regular rituals.
  • The backlog of work wasn't prioritised, and cards didn't have well-defined definitions of done.
  • The team didn't have shared deliverables, and the team was split into silos of knowledge.
  • A lot of implicit social coordination and coalition-building skills were required.
  • Nobody on the team was colocated.
  • There was a lot of red tape. To get something simple approved in one instance, I needed to get sign-off from my manager's manager's manager.
  • There was heaps of back-and-forth on design docs without being able to align quickly on what needs doing.
  • Newbie tasks were not already scoped and were secretly "redesign our entire team workflow".
  • There was a culture of everyone on the team working on their own thing, with no shared team deliverables.
  • The review culture was not aligned towards shipping and was mildly antagonistic.
  • There was a culture of introducing scope from, for example, a Slack message from the previous day that the newbie was supposed to be keyed into, into otherwise small pull requests.
Advice to Management
  • Even in the AI era, I believe it is useful to use well-defined containers of work (i.e., sprints) to determine what a team is working on. Otherwise, it is hard for a team to focus on doing one thing and one thing well within a given block of time.- Assuming reactivity on behalf of a team doesn't scale well. Teams shouldn't be reacting to things; they should be planning and executing as a team on things in well-defined containers of work. Note that reactivity is against the "sprint" philosophy, too. In Scrum, one makes the choice not to bring more work in to protect the sprint, unless of course everything else in the sprint has been done, in which case one consults with the Product Manager or Team Lead regarding what to bring in next.- Regular Zoom call stand-ups (daily), retrospectives, sprint planning, and card grooming sessions are essential, particularly if you have a geographically distributed team.- On that note, colocation is better for teams, as it helps people to build rapport and work together more effectively.- Teams should share the same work; individuals shouldn't be working on their own things. This way, collaboration and coordination are baked into the system structure rather than being reliant on the goodwill of individuals.- The review culture should be focused on "how can I help this engineer ship this?" and/or "how can I fix any potential footguns or key structural issues with this code in order to improve the other engineer's understanding of the system, while simultaneously ensuring that the change is safe and well-structured?" rather than "how can I have a back-and-forth with this engineer over the course of a month and stop them shipping any way I can?" This is possibly an unfair assessment, but it felt that way while working at Canva in many cases.- There is a bit of a fixation on design docs and going back and forth on those, which is fine, but as an engineer, I prefer to hammer out scope on Markdown files. Additionally, I prefer to work on projects where it is possible to agree on something quickly and get started on it. It is difficult for a new starter if they are expected to join and then spend two months debating a complete system redesign when they would much rather be writing code on an established system. Normally, how onboarding works (in my view) is that engineers, even experienced ones, are given previously scoped cards with well-defined definitions of done to work on in an established system.- Definitions of done are important to have on work. Having a culture where scope drift seems normalised is frustrating to work with as an engineer new to a team.- Expecting engineers to be reactive and up to speed with random channels in Slack, as well as constantly vigilant to Slack spam from apps, is destructive to maintaining a flow state for employees. A flow state helps engineers to be more productive and is important to protect.- Requiring engineers to do stakeholder management and alignment doesn't protect their ability to ship. This work does have to be done, of course, and someone has to do it. In previous organisations I've worked in, it has normally been the technical lead, dev lead, and/or product manager who've done this sort of work. Mid-level and senior engineers have largely focused on breaking down epics and working together on those regarding things that have already been hammered out in PRDs, DACI docs, etc., by team leadership. Expecting every engineer to lead their own little team of one I feel is a dysfunctional approach to building systems and an inefficient use of human resources.- I suggest looking into paying down accumulated organisational entropy, as failure to guard against system- and coordination-level entropy leads inevitably to the creation of more red tape over time, which stymies the delivery of the product.- Consider introducing team-based reviews on PRs and team-level ownership of code rather than individual-level ownership. It was very tricky to get people aligned on reviewing things against the main company monorepo, and being able to tag a team rather than an individual for reviews would have made things slightly easier to proceed.

Was this helpful?

Canva Interview Experiences

Taro Footer Icon
Taro Footer Logo
Explore Interview QuestionsTaro 75Google Interview QuestionsMeta Interview QuestionsAmazon Interview QuestionsApple Interview QuestionsNetflix Interview Questions
Explore Interview ExperiencesOpenAI Interview ExperiencesAnthropic Interview ExperiencesPerplexity Interview ExperiencesWindsurf Interview ExperiencesMistral AI Interview Experiences
Explore TrendingLayoffsPerformance Improvement PlanSystem DesignInterpersonal CommunicationTech Lead
ProductGreat DiscussionsPerksTopics
CompanyPrivacy PolicyTerms & ConditionsSupport
Taro iOS appTaro Android app
LinkedIn IconTwitter IconYouTube Icon
Copyright © Taro