From candidate interviews to developer crits: how Figma engineering uses FigJam to scale

Since we launched FigJam back in April, teams having been using it to connect and ideate together. We recently caught up with three of Figma’s engineers—Alice Ching, Joey Wang, and Greg Blaszczuk—to learn more about how they use FigJam to navigate their day-to-day. Here, they share how jamming helps them break down complex problems, work through feedback together, and add more fun to the workday.

Tell me more about what each of you does at Figma.

Alice Ching: I’m an Engineering Manager and I work on FigJam. As a manager, my job is to help the FigJam team work collaboratively to build new features. Since we’ve been remote, I’ve spent more time finding ways to keep the team connected outside of their day-to-day work.

Joey Wang: I’m an Engineer on Figma’s mobile team. I have seen the mobile team grow from the early days to now over 20 people, so I’m often thinking about how we can keep up with and stay ahead of that growth. To me, that’s focusing on how to scale team processes and help new teammates learn our infrastructure and tech stack.

Greg Blaszczuk: I’m also an Engineer on the mobile team, primarily working on our Android apps. The newest version of the app is in beta, so I spend most of my time collecting feedback and testing for bugs on new code we roll out. Like Joey said, our team is growing like crazy—if I’m not coding, I’m probably interviewing candidates.

How are you maintaining team culture now that much of the team is remote?

AC: Now that we can no longer catch up casually like we used to in the office, we’re experimenting with more ways to make the most of our time together virtually. For instance, we realized that stand-ups over Zoom started to feel transactional and almost always ran late now that our team has grown.

We’ve started to run stand-ups in FigJam where we set the timer for ten minutes and everyone puts their update on the board asynchronously. Each person can add stickies or drop in pictures from the weekend, then go to other people’s posts to react, add hearts, or even chat individually. It gives us a chance to catch up on what happened in the past week without needing to go one at a time.

GB: Before we used FigJam, when stand-ups ended we would just leave the call and head back to work. But now we often find ourselves playing games or just being goofy as a team since there’s a canvas right in front of us. Our latest end-of-meeting tradition is a game we call “20-second animal” where someone picks an animal and everyone gets 20 seconds to draw it. It’s a great way to end a meeting on a high note.

You mentioned that the engineering team is growing quickly. How have your interview processes and approach to hiring evolved since Figma introduced a hybrid working model?

GB: When we interview candidates at Figma, we want to understand how they would collaborate with us in an architecture or system design exercise. We love whiteboarding because we can see how the candidate thinks, and because that’s how teams actually work together at Figma. When we went remote, we swapped the physical whiteboard for a digital one in FigJam. Just like we would before, we share the prompt, watch them solve it, and then talk it through—except now everything happens on a virtual whiteboard instead of a conference room.

To make it easy for the candidate to get started, we’ll start an open session and then spend a minute or two showing them how FigJam works if they aren’t familiar. We typically ask candidates to map out a hypothetical architecture followed by writing the code that would make that possible, both of which they can do in a FigJam board. Candidates can use shapes to create the architecture diagram and then write code in a code block that looks just as it would in a code editor. Because the code is already formatted, candidates can code without losing context and quickly spot flaws in their code. And, because everything happens in a FigJam file, we can refer back to the candidate’s work later. We tend to pull up the file when we debrief on the candidate so we can cite specific examples.

As more people join the team, how are you helping new teammates onboard faster?

JW: This is something I think about a lot. I tend to be the go-to person for questions about how the app works and who owns which codebase. As the team has grown, we've realized that it's pretty time consuming to explain the interactions and systems behind our apps. In hopes of making this clearer for all involved, I created an interaction diagram in FigJam.

I dropped in pictures of the actual UI, dragged them into the right places, and added connectors to show each interaction. I also layered on shapes like folders and cylinders to represent the services and teams that underly each interaction.

Seeing it all laid out in one place (versus me trying to verbally explain it over Zoom) helps teammates visualize the full picture and make connections faster. The next time they start a project, it’s easy to see how their work intersects with other teams and which systems they’ll need to access. It’s incredibly helpful for onboarding new hires, too.

It’s no secret that teams have had to evolve the way they collaborate to be more remote friendly. How have you and your teammates approached that adjustment?

AC: One thing we notice now that we’re remote is that it’s harder to get feedback from people who aren’t on your project team. To counteract this, we started hosting a weekly developer critique (just like a design critique) where engineers can share and get feedback on their ideas from across the engineering team. Engineers who want to participate can sign up in our #eng-crit channel in Slack. When it comes time to present, most engineers will drop their work into a FigJam file and share the link for everyone to join in. Sometimes we’ll embed code blocks right in the file so folks can see the code in question. What’s nice about using a shared file is that people can use stickies to give feedback and ask questions asynchronously.

JW: What’s great about using stickies, versus going person by person around the room, is that it lowers the barrier for giving feedback, so more people participate. Plus, if it’s a full room, you don’t have to wait to give feedback. Critiquing work async also gives people the the space to form their own thoughts and avoid being biased by the people who speak before them.

AC: Some of us were a bit nervous to share work at first, but now developer critique is one of our most popular meetings. People love that it helps them reinforce their thinking and see problems in new ways.

Is there anything you haven’t tried FigJam for yet but would like to?

AC: We’ve used FigJam for what seems like everything at this point! That said, I’d like people to be able to hang out in a FigJam file as they work, so they can be in the same space as their teammates even if they are remote. Basically, recreating what it’s like if people are sitting in the same pod just chatting here and there.

GB: I’ve been curious to try the CoderPad widget for whiteboard interviews with candidates. I like that you can see the output of code while you or the candidate write it. It seems like this would be a much more natural way of working through a problem and would help both of us spot errors and address them in the moment.

JW: Bug bashes! We recently saw on Twitter that a team is using FigJam to collect and process their bugs in one place. The FigJam team does this today (very meta) but I think the broader team would benefit from this as well. We like the idea of being able to see the full scope of bugs in one view.

If you’re interested in meeting us and learning more about how we use FigJam in our day-to-day, be sure to register for our livestream on November 17th.