Interviewing at Sigma

At Sigma, we make it easier for people to understand large amounts of data without having to write code. To make this happen, our engineers think about a wide variety of questions on a daily basis: How can we improve our visualizations to help our users explain what their data means? How can our graphical interface make complicated queries intuitive? How can we guarantee that we can always translate one of our spreadsheets into correct, performant SQL? How can we minimize the time between when a user changes their spreadsheet and when they get their data back?

Our interviews are designed to make sure that you’ll be able to help us answer those questions (and to introduce you to some of our engineers). To that end, we don’t ask LeetCode-style questions or brainteasers: we just don’t believe that those types of questions are good at giving us signal about the traits we care about. Instead, our questions try to mimic the kinds of problems we solve every day at work and allow a collaborative discussion between you and our team.

Here’s what you can expect from our interview process.

The recruiting team is your point of contact

Our recruiting team will be in contact with you during each step of the interview process. They will schedule your interviews and ensure that you’re prepared for when you meet with our team members. If you have any questions at any point during the process, you can reach out to the recruiting team, and they will help answer them.

Hiring manager phone screen

Your first interview will probably be a phone screen with a hiring manager (in certain situations we might skip this stage). We’ll introduce ourselves as a company and talk a little bit about what we build and why we think it matters. We’ll also try to understand what kind of role you’re looking for and what your requirements and constraints are.

Technical phone screen

Your first technical interview will be a phone screen with an engineer. You’ll spend some time coding in an online coding environment (as of 2021–03–29, we use CoderPad). We’re interested in how you reason about your solution, how you communicate your mental model, how you structure your code to make it understandable and extensible, and how you test that your code behaves as expected.

We care a lot more about these signals than about how far you get in your implementation. Think of the interview like a treadmill: our goal is to keep you running and watch your technique rather than see if you can get to a particular destination. We’d much rather see you finish the first part of the question diligently and with a thorough understanding of your code than race through multiple parts with poorly-tested spaghetti code.

On-site

If we like what we see in your technical phone screen, we’ll invite you to an “on-site” panel consisting of 4 interviews (right now these are, of course, also virtual). This panel gives us a chance to dig deeper into how you think about technical challenges and see how you interact with our team.

We have a few different types of interview questions in the panel:

Algorithms

These questions are similar to the types of questions we ask in our technical phone screen but are generally a bit more challenging. They may require you to manage complex state or keep your solution clean through many changes in requirements. As with the technical phone screen, these questions will expect you to write runnable code in a virtual coding environment. The signals we’re looking for here are the same as in the technical phone screen.

System design

These questions are at a higher level of abstraction than the algorithms/technical phone screen questions. Depending on the question, we may want you to write up some pseudocode or provide a high-level description of the system you would build. Our goal here is to see how you reason about your system-level design: What are the limitations of your system? Which parts would you change in response to different workloads or operating conditions? How do you maintain correctness in one part of your system when you change other parts?

As with the technical questions, we’re looking for how you reason about your solution and how you communicate your understanding of your system. This doesn’t mean that you have to narrate your thoughts; we’ll make sure to ask explicit questions to make sure we understand your mental model.

Product design

We’ll tackle a product design question — how would you design an interface? How would you structure your code? Can you explain your point of view so that others understand it? How do you handle changing requirements mid-way?

Behavioral

We’ll talk about some of your past projects and accomplishments, as well as the challenges you’ve faced in your career. We want to learn about you and understand how you will work with our team members. We will also demo the product if you have not seen a demo yet.

General tips

• Most of our interviewers will not ask you about your resume or background. We want to be sensitive to your time, and know you’re talking to quite a few people. We’ll introduce ourselves, then dive into the area we want to learn about.
• Take your time and think about the problem. Ask us to clarify anything you aren’t clear about.
• Share with us how you’re approaching the problem. You do not need to explain every thought in your head, but when you pick a direction, please let us know what it is.
• Interviewers are likely to be taking a lot of notes. The goal is to be able to share with other interviewers how the interview progressed. They aren’t chatting with anyone else or ignoring you.
• If you have any other questions about our interview process, our recruiting team will be happy to help out. Please don’t hesitate to ask!