Maker Team at BuildingConnected

We’re here to connect every business and professional in the $2 trillion AEC Industry. Businesses in Architecture, Engineering, and Construction have struggled to keep pace with technology and desperately need more efficient means of communicating. Clunky, ugly, and slow tools have become an unfortunate standard. We believe this underserved industry deserves better, beautiful, modern, and user-friendly software.

Job Openings at BuildingConnected

Top Engineering Values

Each team is asked to select, explain, and rank their top 8 values in order of importance.
  • Customer Comes First

    Commercial construction is a relationship-based industry.

    My co-founder Dustin was a general contractor for 7 years and learned early on that commercial construction is built on relationships. Despite being the most collaborative industry in the world, commercial construction lacks structured communication tools (like GitHub for developers) and has been slow to adopt new technologies due to a lack of trust. At BuildingConnected, we prioritize the relationships we have with our customers and almost take on a nature of servitude. We don’t outsource our customer service (we’re in New York and San Francisco) and we return customer service requests within 5 minutes. At all times, we have 2 engineers who are on escalation as our first line of defense, if anything is escalated from support to engineering. They don’t work on feature development those days because they are focused to helping our customers, and we rotate every couple of days. We develop strong relationships with our customers and are here to serve them.

  • Creative + Innovative

    We’re going into an industry that has resisted using software tools and setting the bar for what construction technology should look and feel like.

    The construction of the new Warriors Stadium in Mission Bay requires a thousand different companies to come together. Imagine coordinating and managing that type of project on email! Luckily, they no longer have to. Our platform allows general contractors (GCs) and subcontractors to find and share documents securely, provides analytics, and eliminates the need for people to manually update a contact database. BuildingConnected is defining what these tools should look like and how building owners, GCs, and subcontractors will use them.

    We also consider ourselves to be innovative in how we run our company. There is a playbook for starting companies in Silicon Valley and we refuse to adhere to them. For example, the accepted model for customer support is to use email, farm it out, and scale scale scale. We are thoughtful in how we grow our business based on our particular industry and as a result, are constantly innovating ways to manage, grow, and structure our company.

  • Open Communication

    When we interview engineers, we look first for strong communication skills.

    Can you clearly articulate a difficult problem? When pushed, how do you respond? Are you abrasive and defensive? Do you take a step back, reflect, and consider whether you are right or wrong? Clear and open communication is such an important part of our team’s culture that even the most talented engineers will not get an offer from us.

    While our Head of Product, CEO, and I (Jesse) dictate the product roadmap, everything after that is dictated bottoms up. People tell me what they need and it is my job to put it into place. We believe in open communication across all members of the company and my CEO and I are 24/7 and always available.

  • Safe Environment to Fail

    We’re human. We’re going to make mistakes.

    In terms of engineering, our high priority is reliability. Our platform is responsible for more than 2 billion dollars in construction bidding across North America every day. We can’t mess that up. The best way to be reliable is to practice dealing with post mortem because mistakes are going to happen, there’s no way around it. To give you a concrete example, not too long ago, we had an issue where we were inadvertently sending emails to our customers that we should not have (we were exposing sensitive information). This was a serious problem and we handled it by meeting as a whole team, identifying the problem, discussing what we needed to do to immediately fix it, and then making the necessary steps to ensure that this doesn’t happen again in the future. The important thing wasn’t figuring out “whose fault it was” because it doesn’t really matter whose fault it was. Mistakes are going to be made. It’s acknowledging this fact and focusing our effort into eliminating the possibility of the same mistake happening a second time. We put in patterns and tests to make sure that another developer won’t be tripped up on the same things in the future.

  • Light Meetings

    When was the last time you wrote a great piece of code in 20 minutes?

    I am a big believer in protecting Maker Time. As a manager, I live 30 minutes at a time and that is my schedule, but a Maker’s schedule is completely different. We only have two regular meetings on the calendar: a sprint-planning every other Friday and an All Hands once a month. That’s it. Of course, there are time when meetings are appropriate and necessary which is why we have a rule that all meetings have to be right before, during, or right after lunch so that we can protect those blocks of hours in the morning and afternoon for making. We also have asynchronous daily standups through Slack. We have a bot that asks everyone the standup question so that people can read it on their own time.

  • High Quality Code Base

    Code readability is one of the things we look for most when we interview engineers.

    As engineers, we spend far more time reading code than we do writing code. Do you write code so that other engineers can easily understand it? This sets a precedent and contributes to our ability to maintain a high quality code base. If you write in Java, there’s really only one way to do it. In JavaScript land though, there are 1000 ways to do anything which. This creates a number of possible rabbit holes an engineer can go down as your team and technology scales. This is why we hire people who care about code readability and clear documentation. We are the type of people who care about writing good, readable code and as a result, we feel comfortable calling each other out about it when we see ways to improve.

  • Continuous Delivery

    We deploy to production 2-12 times a day.

    We are organized into three teams: two feature teams that are on alternating 2-week sprints and one platform team that focuses on scalability and reliability. (Our feature teams are more on the frontlines, working closer to customers and our platform team sometimes solves more complex computer science problems.) Our Maker Teams are constantly deploying. When you open a pull request, at least one other engineer needs to give the thumbs up and this person does not need to be your team lead. Usually, ever pull request gets 2 reviews though. We make a point to merge to production continuously while maintaining thorough code reviews.

  • Heavily Team Oriented

    Internally, we call ourselves the Maker Team.

    At BuildingConnected, there isn’t much attention on the “engineering team” because we’re organized into Maker Teams. Each Maker Team has 4-5 engineers, 2-3 designers, and one product manager. We love making shit. We love building products. Everyone work very closely with the other people on their Maker Team and stays on their team for about a quarter. A couple of weeks before we change teams, we give people an idea of the upcoming projects and send out a survey to let people decide what they want to work on. Beyond our Makers, we also have one of the best relationships I have personally witness between engineering and sales teams. If you’re looking for a strong sense of teamwork and camaraderie, you’ll find it at BuildingConnected.


  • Customer Comes First
  • Creative + Innovative
  • Open Communication
  • Safe Environment to Fail
  • Light Meetings
  • High Quality Code Base
  • Continuous Delivery
  • Heavily Team Oriented

Company Properties

  • B2B
  • Technical Founder(s)

Team Members

  • 2 Data Analysts
  • 15 Designers
  • 34 Full-Stack Engineers
  • 9 Product Managers

Vacation Policy

We don’t have one and we don’t keep track of PTO. We are considering mandating that everyone take a certain number of days off to ensure that everyone has 2-4 weeks off each year.

Tech Stack

React/Redux. Node. MongoDB. Elasticsearch. Redis.

Interview Process

We try and simulate what real work is like at BuildingConnected. All of the problems we give you are highly related to what we do. We don’t believe in theoretical whiteboarding questions. We’re extremely transparent and are responsive. We respond within 24 hours and never leave candidates waiting. We’ll start with a 30-minute phone call or coffee (we prefer to meet in person) followed by a take home challenge (~1-3 hours). You’ll then come onsite to review your code with us (~75 minutes) and meet the team. The final stop is a full-day onsite and we’ll give you prep material ahead of time. Morning is more of a whiteboarding session where you’ll talk through a proposed solution with a few engineers. Then, in the afternoon you’ll have a few hours to code up your solution. At the end of the day, we’ll either make you an offer or let you know that things won’t work out. We focus on practicality, rather than the theoretical, during our interview process.