General notes
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.
Why we have a split engineering team?
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:
- Visor’s authentication system (logging in / out)
- The architecture of the main application (including frameworks and libraries)
- Our back-end services:
- The CloudStore realtime graph database
- Websocket / push messaging infrastructure
- File upload infrastructure
- The integration architecture on the front-end and back-end
- Visor’s views (table, timeline, gantt, etc.)
- The collaboration system, including inviting and sharing access
- Workspace management and settings
- The licensing & permissioning infrastructure
- The front-end integration experience, including importing, syncing, and configuring
To learn more about what areas are owned by the Growth Engineering team, click here.
Notes about this team
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.
How this team collaborates with the growth engineers
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.
Our tools for application engineering
Here are some of the technologies we work with today:
- Notion for documentation
- Github for version control and deploying via Github actions
- Sublime or VSCode for IDE
- VueJS for our front-end framework
- AWS for our hosting & infra
- Python/Django for our back-end services
- Postgres for our databases
We’ve also built a number of important solutions in-house:
- CloudStore as our realtime graph database
- In-app analytics and telemetry
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.
Why we have a split engineering team?
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:
- Visor’s authentication system (logging in / out)
- The architecture of the main application (including frameworks and libraries)
- Our back-end services:
- The CloudStore realtime graph database
- Websocket / push messaging infrastructure
- File upload infrastructure
- The integration architecture on the front-end and back-end
- Visor’s views (table, timeline, gantt, etc.)
- The collaboration system, including inviting and sharing access
- Workspace management and settings
- The licensing & permissioning infrastructure
- The front-end integration experience, including importing, syncing, and configuring
To learn more about what areas are owned by the Growth Engineering team, click here.
Notes about this team
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.
How this team collaborates with the growth engineers
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.
Our tools for application engineering
Here are some of the technologies we work with today:
- Notion for documentation
- Github for version control and deploying via Github actions
- Sublime or VSCode for IDE
- VueJS for our front-end framework
- AWS for our hosting & infra
- Python/Django for our back-end services
- Postgres for our databases
We’ve also built a number of important solutions in-house:
- CloudStore as our realtime graph database
- In-app analytics and telemetry
Tips for the technical interview
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:
- Classes
- Promises
- Symbols
- Proxies
- Arrow functions
- The … operator (rest/spread)
- Maps / Sets
- Default parameters
- Arrays
- Strings
- Dates
- Scope & hoisting
- Debugging
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.