We’re very excited you’re considering a role at Visor on our engineering team. This guide will provide information to make your candidate experience seamless.

You’re being considered for a position on Visor’s application engineering team. Visor’s product is deeply technical in nature, since we’re solving some very difficult UX and data integration problems while building our version of a spreadsheet. Spreadsheets are tremendously flexible, which is why they are so powerful. That flexibility requires elegant architecture that delivers power through its thoughtful design rather than lots of explicit coding.

We have intentionally split our engineering team based on areas of responsibility. That’s because we believe that the growth-oriented work should not vie for the same resources building our core application; we shouldn’t need to make the choice between building a new feature or building the in-product orientation system that will help them use this new feature.

Even though the growth engineering and application engineering teams work on different priorities, we organize ourselves as one team right now.

The following areas of the product are owned by the application engineering team:

To learn more about what areas are owned by the Growth Engineering team, click here.

For a product as complicated as Visor, thoughtful infrastructure is the only way to achieve our goals. We can’t let spaghetti code solve our problems - we need to keep pursuing the platonic ideal for our architecture to deliver an architecture as simple as possible to deliver the needed complexity for our users. This means that our product infrastructure is complex by nature, but it’s no more complex than it needs to be.

Thriving on this team requires excellent ability to think in abstractions and hold large systems in your memory. Our product has lots of modularity, important centralized behaviors and information, and deep call stacks. The only way we’ll get where we’re going is by building on the work we’ve already done.

Given our scale, it will still feel like we have just one engineering team. We’ll still meet all together (typically for 3x per week standups). We also share the same planning and pipeline for work. The main difference is just regarding what priorities each team takes on.

Here are some of the technologies we work with today:

We’ve also build a number of important solutions in-house:

Our founder, Mike, was our very first engineer. He wrote a substantial portion of Visor’s main architecture — including the front-end SPA and the the architecture of the realtime data layer that powers Visor’s collaborative spreadsheet. It should come as no surprise, then, that engineering is a highly-valued part of Visor’s team and culture.

While Mike doesn’t code regularly anymore, we build with a balanced approach between a scrappy startup with minimal process to a mid-size company with some automation and systems in place to create order and predictability. While we maintain high standards, we organize and manage our engineering team with the empathy that comes from having been in the trenches.

We use Github for code collaboration with mandatory PRs and code reviews before anything makes its way into the product. In the repository for our front end, we have an env/dev and env/prod branch. PRs merge into env/dev, after being reviewed by at least one more team member. Merging into env/dev automatically deploys the front-end to a staging environment. We then create PRs to merge env/dev into env/prod for each release. We release generally as soon as we have updates to push, which varies depending on the scale of the projects we’re working on and the scale of our team. We will generally release at least three times per week.

We currently run human testing for QA, since the foundation of the product has been moving a bit too quickly for us to make use of more automated E2E testing. We’re actively considering ways to improve our efforts around QA.

We use Jira for project management. And, of course, we use Visor as a way to organize, plan, and communicate about our work for a given week. We use a kanban-like approach — each week we plan out the work we’d like to have ready for engineering. And then the engineering team will meet up periodically during the week to divide up the work.

We use Figma for design and Zeplin for design documentation.

Our front-end uses VueJS (2.7) and deploys via AWS Cloudfront for all static assets. We aggressively use code splitting to reduce bundle size. We maintain our own UI library, which has its own repo and gets included in our main front-end repo as a Git submodule.

Our back-end is split across about 12 different services, each of which has its own repo and deploys via AWS elastic beanstalk to auto-scaling environments. We use Python + Django for our back-end. We generally use Postgres for persistence, with Redis + Celery for our queues.

We’ve built our own realtime data engine atop Postrges, which we call CloudStore. You can read more about CloudStore in our blog posts (part 1, part 2, part 3) and our explainer video.

We use AWS API Gateway to manage our sockets, which power CloudStore’s realtime data engine.

We have an in-house data warehouse running on AWS redshift, which is where we send our telemetry data from the product (via a custom-built telemetry engine).

We maintain documentation in our internal Notion workspace. All engineers are asked to maintain this source of truth. This is also a critical resource we use for onboarding new team members.

To learn more about Visor’s engineering culture and how we think about balance, please check out this interview with Patrick Shanley, our Principal Software Engineer:

The following outlines Visor’s initial screening process for candidates.

These calls are helpful for information gathering. We’re looking for your honesty and want to ensure that you’ll happy with the role, and that we’ll feel that you may be a good fit for it based on your interest and experience.

On these screening calls, you will not be asked to code or otherwise tested on your knowledge. However, please be ready to talk about the technologies you know best and what types of projects you have worked on recently.

We believe that the technical interview should serve both of us as we get to know each other better and determine whether there’s a fit. We’re not looking to necessarily test the depths of your knowledge about esoteric programming concepts or language quirks. We do not conduct LeetCode interviews. What we are looking for are the very brightest engineers who can learn effectively, think quickly, communicate clearly, and solve problems elegantly.

Our technical interview seeks to provide us an opportunity to see how you approach day-to-day programming in a collaborative environment. It consists of two sections across two 60-minute interviews:

Our assessment is designed to closely mirror actual work and provide opportunities for us to collaborate together on the exercise.

We’ll conduct the interview over Zoom. We’ll ask that you remain on-camera and remain unmuted during the entirety of the interview. We may ask that you use your webcam (without any simulated background) to show us your surroundings and ensure that there are no other people in the room with you.

We will record the call for review by additional Visor team members. On the call, you’ll be asked to open a browser window to a CodeSandbox link, where the exercise will take place, and share your screen via Zoom so we can collaborate together.

The interview will be entirely in JavaScript. You should have familiarity with all ES6 language features, as some may be necessary to complete the exercises. There will be no HTML or rendering components to these exercises — they will just print their results to the console.

Section 1: Writing code according to a spec document

The first section of the interview will assess how well you can read a spec document and implement the module described. In this section, you’ll build a javascript class that represents a utility module with certain behaviors. This section is split into 5 parts, each of which builds on the last. You’ll need to complete each part before proceeding to the next. The parts grow more difficult as the interview proceeds. All 5 parts of this section can be completed within 60 minutes, but occasionally more time will be needed and spill into a potential second round technical interview. During the entirety of this section, you’ll be asked to speak aloud as you’re solving the exercises.

The first round of the technical interviews will be complete after this section is complete (or the end of the first 60 minutes, whichever comes first). Your interviewer may review the recorded call with additional colleagues before providing feedback on the interview. We will get back to you within 2 days. At this time, the interviewer will confirm if you’ll be asked to participate in the second round of the technical interview.

Section 2: Reading code written by someone else and improving it

The second section of the interview will assess how well you can read code, understand it, and build on it. During this exercise, you’ll be presented with a Javascript file that is poorly documented. You’ll be asked first to read the code and explain what it does to the interviewer. The goal isn’t for you to explain what the code actually does but rather what the function of this module seems to be. From there, you’ll be asked to identify and fix bugs in this code. And then you’ll be asked to add new functionality to this.

We’re looking for the following:

We run identical technical interviews for members of our core application engineering team and our growth engineering team. That’s because our technical interview is designed to test your general cognitive abilities — not necessarily any specific knowledge you have.

Here are some important topics that may come up on our technical interviews:

You’ll have an opportunity to demonstrate your specific skills relevant to this engineering team later in the interview process during the take-home project.

We believe the most effective way to determine how well we’d work together is to actually try it. That’s why we’ve included a collaborative take-home project as part of our interview process for all positions.

We value your time and have built in a compensation component to all our projects to show you that we mean it. All take-home projects are structured as consulting projects with a $175 flat-rate compensation attached to them. In order to be eligible for this compensation, you’ll be asked to sign Visor’s standard consulting agreement before you begin work. The general time estimate for Visor take-home projects ranges from 5 to 10 hours.

The take-home project consists of two meetings: a 30-minute kickoff and a 30-minute presentation (followed by a Q&A). You’ll do your work on the project between these two meetings. Typically we like to give all candidates about one calendar week to work on the project, but we can be flexible based on your schedule — planning on less or more time.

During the kickoff meeting, you will receive a set of instructions about a project that is specific to your role. You’ll review these instructions live on a video call with your interviewer. In the most productive of these kickoff calls, the candidates begin some planning work together with the interviewer. Please use this as an opportunity to ask questions you need to help you complete the project (you are also encouraged to follow up with additional questions during the course of your project work). At the end of this kickoff, we’ll schedule the presentation meeting.

The principle behind the take-home project is to see how well we work together. As such, you are expected to check in about your progress during the time between the kickoff and the presentation. Candidates who succeed during these projects are typically the ones that engage in the most conversation with the Visor team during their work.

During the presentation, be prepared to walk through your work and how you met the expectations of the assignment. Your interviewer will ask you follow-up questions to explain your work. Please deliver your project in a way that can be shared after this meeting with other members of the Visor team.

The take-home project is helpful in determining your ability to execute in a real-world scenario akin to those we experience at Visor. We will gauge how well you understand the core requirements of the problem statement, assumptions you make in the process, and your ability to explain how the deliverable may fit into the larger product strategy.

The take-home project for our application engineering roles involves architecture design. You’ll be asked to build a specific feature into a pre-existing boilerplate template. You’ll be asked to use VueJS, but most of the work will be architectural.

We’ll provide more information to you when you get to this point in the interview process.

Our team will conduct a 90-minute interview with you. Our goal is to get to know how you interact with various team members that you’ll work with cross-functionally. We’ll chat about all facets of the Visor product, ecosystem, organization, and culture.

At the end of the day, we’re a team comprised of very real people who come from different backgrounds with a shared purpose of collaborating together in the hopes of building something of value for lots of people. We all approach each other with honesty, openness, curiosity, and support. We ask that you approach this conversation from a place of honesty and vulnerability. We’re aiming to build a rapport, and to find out how you can become a culture add to our team. We’re looking for signs of your passion, drive, and commitment to our cultural values. You’ll earn bonus points if you demonstrate you’ve read this by mentioning “EPIC Drive,” our cultural values, during the part of the team meeting when everyone is together.

Keep the following in mind when preparing for your Visor engineering interview.

We’re all in this together, and we need to be able to communicate clearly and help each other. A critical part succeeding on our team is having strong communication skills. That means being able to explain things clearly and also ask for help when you’re stuck. Our interviews are made to mock real-world work, so don’t treat them like independent tests. Ask your interviewer questions.

Building a company is all about figuring out hard, new problems. As a result, we’re looking to hire team members who don’t just know how to write code in languages they know but also know how to solve unexpected problems. Let your intelligence shine through. Tell us more about your academic achievements that demonstrate your cognitive abilities. Or show us your intelligence by communicating very clearly as you’re solving the problems in our technical interview.

Early-stage businesses like ours depend on everyone on the team being driven to build a great business. And that means building an engineering team of builders — people who don’t just want to close Jira tickets but actually want to see something new exist. Show us that you are driven and motivated to do more than punch in and punch out.

Visor’s solving real, hard technical problems at the forefront of technology. We’re at the scale where we need our early employees to have a wide knowledge of technology and engineering to enable clever problem solving. Show us how you’re passionate about technology — so much so that it’s more than just what you do for your career, it’s a part of who you are.