What do computer science students learn on a tour of Canva?
Here’s what it’s like to take a tour of Canva’s HQ
This week we received a visit from UNSW CSE Society, who heard talks by Canva speakers, did an office tour, asked questions and enjoyed some of Canva’s famous fried chicken.
Canva speakers gave students a practical overview of some of the engineering areas that students could go into. These included frontend development, mobile, product management, backend development and data science. We also tried to answer the question “What should I study at uni?”
If you’re interested in the content of those talks, read on! If you want to hear some student impressions of the tour and the Canva vibe, skip down to the bottom.
Chris Chen — What should I study?
It’s a question people often ask. What subjects should I take if I want a code-focused role at a company like Canva? Chris had one concrete study suggestion: Concurrency (or anything non-deterministic).
It turns out that concurrency is super common in the real world these days. Gone are the days of single processes running on giant mainframes. These days your code is operating in a weird, scary, nondeterministic environment with lots of other things happening at the same time.
If you’re working on the frontend, you have to deal with asynchronous frameworks. If you’re doing native mobile dev, you have to think about work versus draw threads. If you’re working on the backend, you have to deal with concurrent requests and horizontal scaling. Concurrency is unintuitive and difficult. When things go wrong, you’ll get corruption of data or $60M re-entrancy bugs. Studying concurrency at university isn’t going to fully prepare you. But if you’re at least aware of the problems, you’re going to save yourself a lot of headaches.
But apart from that, Chris had some feelgood advice too: “Take whatever you’re interested in. Most CompSci subjects have surprising practical applications! “ And she didn’t just mean “critical thinking” and “independent thought”. For example:
Algorithms and data structures: “When does one start caring about the difference between O(n), O(n log n) and O(n2)? When you’ve got 10TB of data and users who hate latency”- traditional web company proverb.
Networks, hardware and microprocessors: You never know when you’ll have to look under the hood of your “pretty abstractions”. Or maybe you just need to run cost assessments on investing into GPUs.
Formal methods and security modelling: The ability to think of a problem in terms of worst cases, and being specific about what you want is incredibly important. This is true of everything from privacy and threat models, down to deciding what one API function really does.
And the list goes on — machine learning, operating system design, programming language theory, or almost anything else come to think of it.
Nick Whyte — Frontend Engineering at Scale
Frontend Engineering at Scale by Nick Whyte (thanks to Brendan Annable for the original talk material)
What is frontend engineering? How do you scale a frontend?
The frontend is the thing that users get to interact with. Recently more and more logic that used to be done on the backend is being done on the client side. That’s landed us in the era of single page applications. Single page applications show the user interface to the users, then respond to user events. This response potentially involves issuing an AJAX request to the backend.
Canva has a very large frontend codebase, and that means a lot of scale issues. We need to be able to scale our engineering processes as we scale our codebase, and accommodate all the new engineers coming in. High quality code, modular code and testable code mean that things don’t break or become unmaintainable as the codebase grows. This is how we do it:
Rigorous code review not only maintains quality, it’s a great teaching and learning tool.
Code ownership, where each part of the codebase is owned by a certain engineer, also promotes code quality and distributes responsibilities.
Type safety prevents a lot of the trivial mistakes that untyped JavaScript can cause. Canva’s frontend codebase is 100% typed, thanks to TypeScript and Closure Compiler.
Continuous integration means that every commit runs a full build of the Canva website. Checking things like types and linting here helps pick up bugs that code review may have missed.
Harness pages are pages that allow us to run lightweight ‘fake’ versions of our webpages during development (so for example we don’t have to navigate to a page 10 layers deep in the UI over and over again) This is also great for encapsulation and modularity, because it encourages pages to be built in isolation.
Modular CSS — Using Block Element Modifier classes like “menuBar__item-selected” means we do away with nested CSS selectors, and means we can restructure HTML without changing the CSS. We’re moving towards CSS modules.
Testable code using dependency injection allows us to inject fake instances of dependencies, ensuring our tests are well isolated and only test the bare minimum.
Finally, mentoring ensures we can scale as an engineering team. Every new hire is assigned a mentor, who helps them get up to speed quickly when they join. We do fortnightly frontend forums, monthly engineering all-hands and of course review every line of code.
Shipra Mahindra — The role of product management in a startup
CSESOC — Product Management by shipram
What can you do with a CS degree other than write code? Have you considered getting into product management in the future?
Shipra Mahindra, product manager for Canva’s mobile apps, talked about the role of product management in a startup. Shipra started her career as a software engineer herself and worked her way into product management, with an MBA at UNSW on the way.
A product manager works at the intersection of business, tech and UX. We work to deliver the highest business value possible by creating new products or iterating on old ones. We also need to work out what our customers want, and deliver customer value by making sure our products have a great user experience. We need to talk to customers and do user research. We need to work with engineers to solve problems everyday, so a technical background really helps for understanding what can be built within a timeframe.
Shipra talked about product management in Startup versus established businesses.
Strategy is top-down: The product roadmap is set at an exec level. Product managers work to deliver the plans that have been made.
Strategy is collaborative: Product managers work together with the exec team to decide what should be built and what the strategy is.
Long term planning: At least 6–12 months ahead.
Planning for now: Product managers are usually thinking 3–6 months ahead. You need to be able to pivot and learn from what you’ve built very quickly.
Tiny product: There are lots of products in the company, and product managers are responsible for small areas within single products. You still have millions of users though.
Huge product: You work on all parts of a product, and possibly across multiple products. You really influence the breadth of the product and the company itself, not just the depth in a single area.
Focus on user research + business: You get a lot of time to focus on these areas, because you have a narrower range of responsibility within the company.
Focus on everything: You have a lot of responsibilities, so there can be less time for in-depth user and business research.
It’s important to be a servant leader. Your title may have the word “manager” in it, but you’re not really managing anyone. You’re managing the product! You don’t have direct influence over people. Engineers have an engineering manager, designers have a design manager and so on. So you can’t tell people what to do, it’s about influencing people, discussing the issues and getting buy-in. You need to show with examples and data.
Most PM’s I’ve met never set out to be product managers, that’s just the way their career progressed. A technical background really helps, but PMs also come from other backgrounds like marketing.
How can I prepare for product management at uni?
At uni the things you should pay attention to from a Product Management perspective are knowing how the software lifecycle works, things like how different software architectures work and how tech stacks are put together. All the big picture things. You need to be a bit business savvy as well, so if you can grab an intro to marketing, finance, HR or other business functions that’s great too.
Nic Wittison — Canva Mobile
Nic talked about Canva’s mobile journey and distilled some gems of wisdom he learnt along the way. These are the takeaways:
At the start of a project, iteration speed is more valuable than having amazing code.
If your product changes really quickly, having technically amazing code doesn’t matter if you just have to rewrite it anyway.
The important part is making your code easy to refactor or separate.
If you’re going to spend time on making something technically good, at least make sure you can reuse it somewhere else!
You always have to make compromises. Learn to identify what really matters so you can make better choices.
You can’t always do what you want. The APIs you want may not include everything you need, the timeframe might not be sufficient to do everything. It’s all about identifying the most important things for your project.
Debugging code is twice as hard as writing code. If you write genius-level code, you need to be a double-genius to fix it.
There’s so many times I’ve written code, gone back to it 12 months later and thought “Who wrote this? It’s nonsensical garbage!”. So write simple code, and make it straightforward to read.
If it’s important to your app, try to write platform agnostic solutions to problems.
If you can avoid tying yourself to technologies that only work on one platform, it’s going to be easier to move to other platforms later on.
Design your UI mobile first.
If you design a really complex UI and then try to squish it onto a mobile screen, that’s a lot harder than starting with a small mobile feature set and expanding it.
Use your demos to get feedback faster.
Developers love showing off their apps to people. Do it more, and pay attention. If your mum gets frustrated with your app, that’s a bad sign. Take mental notes, or even real notes.
Don’t underestimate the value of good communication.
Learn how to communicate with different audiences. Practice it. If you’re talking to a designer, using words that are specific to the frameworks or languages you’re using won’t help. Learn to talk in higher level concepts, and you’ll get feedback faster.
Automate chunks of process whenever you can.
You can save a lot of time in the long run with simple optimisations. If you hate uploading the app to the app store, turn it into a script. Automate the smallest chunks possible — this makes your scripts maintainable, and you can string them together into more complex processes.
Talk to the people at Apple and Google.
There are developer relations teams, and some are based in Sydney. It’s their role to find good apps and promote them.
Try to make at least one piece of demo tech.
Make the kinds of things that people feel compelled to show others. An example is the augmented reality demo we recently built into the iOS app. It’s built using Apple’s ARKit, and it’s super fun to show around. You can use it to see how your designs will look printed in real space!
Tiny Pang — What Data Scientists Really Do
What Data Scientists Really Do by tiny Tiny Pang, data scientist at Canva
What is data science actually? Could this be your future job?
Data science is a bit of a buzz word, but do you really know what it means? Data science actually covers a number of different fields. There’s product analytics, which is about measuring and analysing user behaviour on your product and using that information to improve the product. Then there’s data infrastructure, where you build data pipelines, choose the databases that store your data and run queries on it. You might pass that information on to product analysts, or do the analysis yourself. Finally there’s machine learning and AI, where you are algorithmically detecting patterns in large data sets.
At Canva we track a lot of events on our pages (for a funny version of this, see clickclickclick.click). For example we track an event called design_create which is triggered when a user creates a design. The event time, type and location within the product are linked to a user id, country, language and so on.
As a data scientist, I need to think about how to we’re going to collect these events and choose the right kind of data pipeline to collect it. That will depend on a few things, like whether the data is going to be hot (frequently accessed) or cold (infrequently accessed). I have a choice of various technologies, including Amazon S3, MySQL and Redshift. After that we need to decide what kind of analysis to do. That could be as simple as a SQL query or as complex as a deep neural network. So there’s a lot of variety within data science, if you’d like to go down this path!
Tiny Pang giving away her data about data science What studies would you recommend for getting into data science?
I did my undergraduate degrees in pure mathematics and computer science, and I did my research degree in AI. I actually recommend a standard computer science degree, rather than a specific data science degree. Computer science fundamentals are really important for creating, manipulating and cleaning data sets, especially strange ones.
What’s something you didn’t realise about data science when you started?
I didn’t realise how important it is to be able to sell your ideas. Often when you tell someone some information that’s data driven, it’s going to go against their intuition. If you don’t sell your analysis well, people sometimes don’t even listen to the data!
Brendan Humphreys — backend engineering at Canva
Brendan Humphreys fielding some questions Brendan gave students a brief overview of the backend of Canva and fielded questions. Brendan was one of the original four backend engineers at Canva, having started 3 1/2 years ago.
On the backend we use a microservices architecture. The idea of a microservice is enforcing separation of concerns. That means identifying the entities in your system and building a single-responsibility service for each. We’ve used the microservices approach from the start, and its helped us scale both in the amount of traffic we can handle, and the number of engineers now working on the backend systems. Each service exposes a cohesive interface, and services communicate with each other using REST over HTTP. Sometimes when we judge a service has taken on too much responsibility, we split it into two or more smaller services.
Today we are handling a ridiculous volume of traffic. Being a fast growing consumer application, we handle a lot of data from a very large user base — certainly more than the average large B2B application, for example.
Our users upload more than 1.5 million image uploads every day, and create more than 14 designs every second. That means petabytes of media data on Amazon S3 and hundreds of gigabytes of design data in our MongoDb cluster. We also have a large Cassandra cluster (tracking comments on designs, likes, and followers), several large Solr clusters (media and design search), and many more traditional relational stores (e.g. for billing, profile and subscription data). The backend infrastructure consists of between 200–300 servers keeping the whole show going.
What’s the interview process for the backend? Why is there a take home task?
We find that the homework challenge is a good filter. We understand that is requires some time to answer, but generally the kinds of engineers we’re looking for are able to solve it without too many problems. Lots of people actually prefer being able to sit down in their own time with a challenge, rather than being made to stand in front of a whiteboard for hours. If you get past the challenge process, you come in for more interviews and are asked to modify your code from the challenge. It very much simulates the kind of work you’ll be doing day to day, which doesn’t involve balancing red-black trees.
What we’re looking for in the challenge is “production ready” code, that’s written with a certain level of engineering maturity. That means taking into account edge cases, testability, maintainability, documentation, readability, performance and smart tradeoffs. We’re judging you as a potential peer.
Taking a Canva-style lunch break
What the students said:
I think Canva is one of the most dev friendly environments I have ever been in. The way the teams are organised on each floor with developers, product manager, and designers sitting across from each other was pretty cool to see. We even got to see the CEO sitting with a team. — Ainharan Subramaniam
Overall, the tour of the Canva office was a fascinating experience. Seeing the creative workspaces and getting to hear from a few people on the Canva team gave incredible insight into what life is like at Canva for a software engineer. The general vibe about the office seemed chill and innovative, with a bit of hipster flair. — Alli Murray
A really fun and relaxed atmosphere. Everyone seemed passionate about helping create such a cool and unique product. — Ray Zubair
There were insightful presentations given by talented people who work there, they were passionate and enthusiastic during their talks. We were also toured around the office space briefly, the office decor is simple but not boring at all! (and yes, the fried chicken was awesome!) — Vivian Dang
Originally published at https://product.canva.com on September 28, 2017.
