When making a career move, it can be challenging to know whether a company is a good match for your skills, your talents, and your personality. Electric wants to help you become more certain. By showing you how we hire and how we work, you’ll see our culture and learn what it’s like to be a part of our engineering team. If you have questions along the way, let us answer them for you.
Based out of New York City, Electric's Product & Engineering team has 80 members, spread across the U.S. and Latin America.
Mostly Remote
Personal growth is a cornerstone of our culture, and something we care deeply about. We want your time at Electric to advance your skills and career as much as possible. Here’s how we bake this into our culture:
Autonomy is one of our core values. Accordingly, we trust you to use our flexible schedule to manage your own time. Instead of micromanaging and throwing up a lot of controls, we want you to create the environment you need to do your best work.
Our team is located all over the U.S. and in Latin America. Many employees are fully remote, and some who are local to NYC choose to utilize the office in some capacity. There is no obligation to show up at the office whether you live in NYC or not.
We run cross collaboration teams, so here is a snapshot from three of our frontend teams working in different areas. Team 1: Our primary goal this year is to mature our micro-frontend infrastructure. We're building a component library on top of a shiny new design system. Storybook is the foundation for our FE design system. We're playing some of our BFF (BE For FE) with GraphQL. We're paying extra attention to performance and stability, and building observability and automation with DataDog and Cypress. We rely heavily on React and have little to no FE legacy codebase. Team 2: We'll be looking to improve our UX across the Platform, and continue adding value to the platform by exchanging manual work we've been doing for our customers with platform functionality. Team 3: We're expanding and improving our home-brewed RTS software so it can provide help desk functionality as well as specialized IT-related UX. We run cross collaboration teams, so here is a snapshot from three of our backend teams in different areas. Team 1: We are wrapping up a migration from Ruby/Heroku to Python/AWS/AWS Lambda this year. The list of services we've got on Production that's already based on these technologies is growing fast. We're using RDS, Dynamo, and Redis, to solve our data storage and caching needs, choosing the right solution for each problem. In 2019 we've experimented with Node and Go, and believe polyglot programming can play an excellent role if you use it at the right spots. We rely on SNS and SQS for cross-service data hydration, and continue to improve our AWS infrastructure to serve our growing scalability needs. Team 2: This year we're looking to bring full visibility into our platform by redoing our device management infrastructure, incorporating frameworks such as OSQuery and Kollide Fleet. We're also looking to improve our capabilities in gathering and presenting data on other aspects of IT such as network, security & compliance, and SaaS licensing. Team 3: The main challenge is to build a next-generation real-time support solution. We're looking at serving our customers through multiple chat technologies, as well as other modes of communication. When we provide IT support to our customers, there are several needs and goals. We need to understand what the problem is. We need to assign the right level of technician. And we need to provide automated solutions to common requests. The focus, consequently, is on two fronts: one is building a communication-agnostic platform, through solutions such as a chat middleware (Python, AWS Lambda) and some API integration such as with Slack API and MS Teams. On the issue-resolution front, we're focusing on a series of services that can replace manual work with a series of integrations both with device management software (Jamf, Kaseya) and with various SaaS APIs. There’s no shortage of work to be done within SRE! On the tech front, this year we are looking to migrate from Ruby on Rails (Heroku) to Python on Lambda (AWS), improve the architecture of our serverless cloud infrastructure, and improve the reliability and scaling capacity of our MDM-as-a-service offering (which is expected to grow by about 10x over the next two years). To do this, we are employing infrastructure-as-code tools such as Terraform and Serverless Framework to manage Heroku and AWS resources (Lambda, RDS, SQS, and EC2), and developing new technical solutions for de-coupling infrastructure and resource management from the development chain. Perhaps even more important than the technical stuff, a continuing focus for our team will be practicing SRE at the cultural level. While tooling is certainly important, what separates SRE from “DevOps” is a certain mindset that everything can (and should) be measured, and those measurements should be used to give continuous feedback on service reliability to everyone in the company. With our brand-new SRE team, we are helping to encourage this mindset within engineering at every level of our stack and the infrastructure it runs on. This will require significant effort in building and improving observability, monitoring, alerting, and incident management processes, along with all the technical bells and whistles that come along with it. The Data Team is responsible for laying the foundation for a data-driven product culture at Electric. In 2020, a big emphasis for us is partnering with the product and design teams to improve the way we capture and structure data in our product, so that we're set up to pursue machine learning opportunities in the future. We also play a role in each feature development cycle, ensuring clearly-defined metrics are available for everything we build, and that the insights we need to make decisions are at our fingertips. To support all of the above, we rely on a modern data stack, including Redshift, dbt, Airflow, Segment, Stitch Data, and Periscope. Our most pressing data engineering challenges involve making sure we can deliver timely and accurate insights despite the complexities of our distributed microservice architecture.
Because we understand the value of your time, we keep our hiring process simple. Our focus is on understanding how you think and collaborate, as well as how your past experience might contribute to the future success of our team. A typical hiring process takes about three weeks.
We start with a 30 minute HR phone screen to understand your background and interests, and answer your questions. From there, we move on to a technical phone screen, followed by a 4-hour on-site where you’ll get to know the team, and collaborate on some software design and coding problems. Expect to spend some time at a whiteboard, but no need to cram on algorithms and data structures beforehand.
We have ~30 people with a lot of openings. We are aiming to have a team of 50 people split between NYC and Argentina by the end of 2020. We currently have ~15 people in NYC and ~20 in Argentina. We want our engineers to advance without having to go into a management track and for that we have tech leads. Tech leads focus on advancing their skillset and leading the team from a technical standpoint. Their compensation is the same as our manager track. Yes. We want engineers to have access to professional development and to the latest and greatest that's happening in their technical field. We ask that engineers have a goal before they go, and be willing to share learnings when they're back. And then we do our best to approve conference requests - we've done so with great success as of late. We work out of a WeWork building in NY. We have an entire floor with an open office design and meeting rooms all around. We ask the candidate for their language of preference and in that language we ask them to solve a question on an online code pairing tool. We usually use repl.it or codesandbox.io. We look for candidate’s abilities to parse the problem, communicate their approach and solution clearly and their ability to break down into smaller pieces, testability and extensibility of their solution. No, we want to learn how you think and talk about how you approached a real world problem. We do not expect you to memorize anything or whip out perfect code. Awareness: Someone who cares about the context and wants to answer questions like: "why am I working on this?", "who is this for?", "why is it important?", and "how far should I go with this? Ownership: Someone who owns the roadmap, cares for our commitment, plays a role in slicing MVPs, and thinks about what value we can deliver and how fast. Curiosity: Someone who stays in touch with their profession and helps us experiment and innovate based on the latest and greatest. Empathy: Someone who deeply cares for their teammates, our customers, and the company. And, someone who can see things from others' points of view and can make balanced decisions.
A totally anonymous way to ask questions before you apply.