Engineering Team at Airtable

Airtable’s mission is to democratize software creation. We believe that software stands to be the single most impactful way anyone can bring their ideas to life, yet that few people can actually access it as a creative medium. Airtable enables everyone to experience the power of creating, not just using, software.

Job Openings at Airtable

Top Engineering Values

Each team is asked to select, explain, and rank their top 8 values in order of importance.
  • Bonded by Love for Product

    Our mission is to democratize software creation.

    We believe software is the most important innovation of the past century, but that its potency as a medium for economic value creation and creative expression remains inaccessible to most. (People typically experience a finished software product, rather than software as a medium.) As engineers, we know how empowering it can be to create software, and we intend to bring this power to everyone.


    Instead of designing features for narrow use cases, we create fundamental building blocks that can be assembled to model any workflow. For example, rather than building a “kanban board” product, we allow users to organize any data in Airtable as stacks of cards; and rather than building an “organization chart” product, we allow users to visualize any data hierarchically. At the same time, we strive to make this complexity as accessible as possible, sweating the details of our user interface and creating the best possible experience even when it means more work up front.


    This combination of flexibility and accessibility has enabled people from all walks of life - from magazine editors and TV producers to architects and cattle ranchers - to find value in Airtable. Our users love what we’ve built; they praise us on social media and publish amazing templates on Airtable Universe. It's motivating to work on a product that has such wide, deep, and positive impact.


    As ambitious as our current product is, we know our mission demands far more. In Niklaus Wirth's classic formulation, Algorithms + Data Structures = Programs; Airtable starts users with a rich, highly accessible canvas to describe their data, and then layers powerful tools to add functionality (algorithms) over that data. By scaling both of these dimensions — further enriching the data and layering progressively more powerful tools — we have a unique opportunity to gradually teach users to build fully-realized applications.


    Building that general-purpose toolkit comes with a unique set of hard engineering and design problems. Whether it's finding the right level of complexity and expressiveness for a new feature, or thinking through how it might intersect with the existing dimensions and building blocks of the product, the opportunity and challenge embodied in these problems inspires us to do our best work.


    Finally, we're enthusiastic users of Airtable ourselves! Many of our internal processes run on Airtable, including our issue tracker, recruiting process, team gallery, and product roadmap. And if you're ever at a loss for a conversation topic with one of us, ask about our personal bases for our travel plans, parenting responsibilities, or books we're reading. This shared passion for our own product unifies our team and ensures that we're all invested in continually improving it.


  • High Quality Code Base

    Airtable takes a long-term view.

    We intend to build a company that will last decades. Our product, funding, and market position make a long-term orientation for our engineering team not only possible, but necessary. For one thing, our product has enough fundamental complexity that adding incidental complexity by taking on too much technical debt would cripple our velocity much sooner than a company with a more straightforward, boilerplate product.


    Additionally, we have a product that stands in a well-differentiated category of its own. This gives us breathing room to build durable competitive advantage by innovating, rather than constantly racing to eke out a razor-thin marginal advantage over similar competitor products. Our focus on code quality grows from deep roots in the nature of our business; it’s not just a pet preoccupation of some engineers on our team.


    To this end, we embrace the usual repertoire of quality software development practices: code review, linting and static type checking, unit and integration testing, continuous integration, manual QA, deployment automation, issue tracking, and a thorough style guide that focuses on practices that improve code clarity without too much bikeshedding. These practices aren't engraved on stone tablets; we're always discussing how to do better, and ideas can be raised by anyone from our newest hire to our cofounder CTO.


    At a higher level, we have a culture of circulating ideas in design documents well in advance of implementing them. When done right, a design review process does not slow down development. Good teams are perpetually bursting with ideas. If people are encouraged to share those ideas early, then features or changes can be proposed, discussed, and refined long before the team has bandwidth to implement them. Reflecting on design or implementation approaches as a team leads to greater simplicity and clarity. Building the simpler, clearer thing nearly always leads to greater development velocity, even in the relatively short term.


    That said, we recognize that there are times when fast turnaround is imperative. Sometimes a defect that affects users must be fixed urgently, and the fix is clear, and in such cases we prioritize appropriately. And sometimes the best way to deliver quality in the long term is to put early iterations of a feature in contact with users so we can learn from their feedback. In these cases, we strategically deploy well-contained technical debt. (One tactic for containing debt in these situations is to ensure that decisions made in this mode are highly reversible. For example, exposing a limited beta of an Airtable block to a small audience constrains future development much less than a public UI or API in the core product.)

  • Start-to-Finish Ownership

    At Airtable, engineers are involved in the entire product development process, including ideation, implementation, instrumentation, and iteration.

    Working closely with our customer-facing teams to understand user needs, engineers write specs for new features, conduct “spikes” (timeboxed investigations to explore potential designs), and create UI mockups or prototypes. For a product like Airtable – a horizontal toolkit for software creation – having this hybrid product and engineering mindset is critical to designing building blocks that are simple and usable, yet powerful and flexible.


    One way we foster this mindset is through a philosophy of thinking from first principles. Rather than creating narrowly-scoped single-purpose features, we constantly try to solve higher-order meta problems that span multiple use cases and industries. For each new feature we build, we consider how it composes with the existing surface area of the product, thinking through newly introduced edge cases or emergent ways to unlock customer value. To this end, we often simmer on problems for weeks or even months before we build it, in order to preempt problems that may come up in the future or inform the sequencing of new features in a complementary fashion.


    For each new product feature, the engineering lead is typically paired with a product specialist lead responsible for tasks like analyzing the competitive landscape, writing internal documentation, and conducting user studies and the beta feedback process. Engineers also work with QA to write up a comprehensive test plan, and with our go-to-market teams to develop launch strategies and growth experiments around the feature.


    As our engineering team grows, we are putting more structure in place. We’re dividing the organization into subteams, each having their own tech lead and responsibility for setting team goals. Teams that work on directly user-facing product surfaces also have a product architect, who focuses on defining the product roadmap for the team’s areas of responsibility. Both the tech lead and product architect roles are filled by engineers, who must have an intimate understanding of both the underlying technical architecture and the ideal user experience of their respective domains. By design, Airtable's product development methodology is highly collaborative, with engineers deeply involved in and owning key elements of this entire process from start to finish.

  • Actively Practices Inclusion

    We think of diversity and inclusion in terms of 3 P's: Presence, Participation, and Progress.

    Presence: The first step to inclusion is simply including a diverse set of people in your company. We actively discuss how to improve and diversify the culture in our #diversityandinclusion chat channel and other forums. To reduce bias in engineering hiring specifically, we obfuscate the names of candidates when evaluating our take-home coding assignment, which plays a major role in our process. We've also introduced standardized rubrics and assessment metrics for our interview process to help eliminate implicit bias. And despite our relatively small size, we're continually investigating methods for improving our candidate pool's diversity. Our CEO Howie unambiguously supports devoting significant resources to this end.


    Participation: Once you get people in the door, you must ensure that everyone is involved in meaningful decisions. Our employees come from all walks of life: some are parents to newborn children, some are empty nesters, while others are part of the younger workforce. Airtable believes it can mold itself to accommodate your work style. Most of our communication is asynchronously accessible (see section below on work arrangements). Company-wide celebrations happen at all hours of the day, not just after work, and include activities, food, and beverages compatible with a variety of lifestyles. Oh, also, we are pet friendly: well-behaved dogs are a frequent sight around the office, and we celebrate photos of cats, dogs, and all other critters on an equal footing in our #animals-and-robots chat channel!


    Progress: At Airtable, we want all employees to create the biggest impact possible. We're currently still building out our HR organization, but as table stakes, we offer weekly HR office hours to support employees. We've instituted a program of training managers in coaching skills to maximize every report's chance of success. There are also active discussions about how and when it would make sense to formalize employee resource groups for underrepresented minorities and other groups (our current thinking is that we're a bit small right now, but that we should nurture their organic formation as the company grows; we're open-minded on this score though, so feel free to talk to us about it!).

  • Open Communication

    The best decisions are made by proactively communicating with everyone who might thereby receive or add value.

    This nearly always means capturing it in written form, and Airtable is very much a written culture: project specs, meeting notes, retrospectives, market opportunity analyses, and other documents, including our CEO Howie's reports to our board of directors, are all duly written up and circulated widely, in most cases to all full-time staff. Engineers regularly write documents that receive direct feedback from sales or other customer-facing teams, and vice versa. For this reason, we ask for a writing sample on our online job application form (and we really do read it!).


    Furthermore, we strive to establish a social context in which people have the right expectations about authoring proposals or commenting on them. First, we encourage people to share as much information as possible: not only proposed actions and decisions, but also the context and motivations that prompted them. This allows readers, who do not already have that context, to engage more effectively. Second, we practice empathetic communication and discourage excessive pride of authorship. Ideas can only be shared early and often if people feel secure that their half-baked or highly speculative ideas will be welcomed as a starting point rather than attacked for their imperfections. On the other hand, the process of iterating and refining proposals can't work if people start out too attached to (or personally identified with) particular versions of an idea. Without these critical values, no software tool can create a culture of open communication.


    Like many other companies, we use Slack for real-time communication. However, we also recognize the many limits of chat-style communication and strongly bias toward capturing discussions wherever reasonable in documents, tickets, and other durable media (including, of course, Airtable bases). We believe the best decisions are often made with ample time, discussion, and thought, which are best supported by asynchronous collaboration.


    (A strongly written and asynchronous communication culture has other benefits, too. It's better for work done outside our main offices, or on time-shifted schedules. Also, it enables a greater proportion of focused “maker time” compared to a culture where everyone feels obligated to actively monitor chat for fear of missing out on important conversations. Of course, there are plenty of times when real-time chat or meetings really are the best way to communicate, and we embrace those situations. But we try to deploy these communication modes thoughtfully.)

  • Eats Lunch Together

    We have company-sponsored healthy lunches daily in our physical office locations, but we think several features of our lunchtime are unusual.

    First, our office culture (see below!) encourages a high proportion of quiet, focused work time, so lunchtime provides a compensating opportunity for social bonding and the informal, osmotic diffusion of knowledge and ideas. We embrace this break in the middle of the day as a valuable part of the way our business works. Our primary motivation for providing lunch in the office has nothing to do with time efficiency. In fact, we are experimenting with ways to layer more supported social interaction into our culture. (One experiment we're running is a cultural event series, where small groups attend outside events such as plays and concerts together.)


    Second, we consciously make an effort not to sit by team. Engineers, recruiters, salespeople, and other customer-facing staff all mix at our lunch tables every day. This leads to more diverse conversations as well as a team that is more attuned to the needs of customers and the company.


    Lastly, every Friday, we have “Show and Tell”, an all-hands meeting that overlaps with the second half of Pacific Time lunch. Scheduling our all-hands at lunchtime allows a larger proportion of people to attend, compared to an all-hands held at the end of the day, when parents are often running for the exits. (Of course, the presentations are also recorded, for anyone who isn’t available during that time.)


    At Show and Tell, anyone, regardless of seniority, is encouraged to sign up (in an Airtable base shared company-wide, of course) to present anything worth sharing with a broader audience. We often kick off the meeting with a brief slide of pet photos (Airtable <3 animals) and then launch into short presentations. The content varies widely, but often includes demos of features-in-progress, reports of customer conversations, and more formal company-wide announcements. Show and Tell is a crucial and ever-evolving part of our culture, and we wouldn't be the same company without it.

  • Flexible Work Arrangements

    Airtable employees work in-office, fully-remote, and everywhere in between, on a variety of schedules.

    To ensure everyone is informed and included regardless of their personal work situation, we favor written communication and asynchronous deliberation (see our section above on communication), and we both videoconference and record many of our meetings for remote or later viewing.


    We encourage asynchronous work and online collaboration whenever possible. That said, we also support employees’ preferences for where and when they do their individual and collaborative work.


    Many of our senior engineering staff, including our CTO Emmett and our lead architect Alex, have young children. We believe people should be able to spend time with their loved ones, whether that means leaving early every day to pick up a child from daycare, or working remotely for a while to spend time with extended family and friends. Some of our commuter employees simply WFH on a semi-regular cadence to avoid the hassle of commuting. We refuse to measure work by “hours in seat,” and we try hard to schedule meetings and other events at times that are compatible with the preferred schedules of all involved.


    Furthermore, at our physical spaces in San Francisco and New York, we've thoughtfully built an office culture that supports both focus and collaboration. We ensure desks are adequately sized and spaced; we have sound-isolated meeting rooms and booths for calls and conversation; and we default to quiet interaction in desk areas. Visitors to our SF office are often surprised at how peaceful our workspace is. And we give all employees, including remote ones, equal freedom to expense office equipment necessary to do their jobs. Offering flexibility doesn’t mean we skimp on the best physical infrastructure.

Values

  • Bonded by Love for Product
  • High Quality Code Base
  • Start-to-Finish Ownership
  • Actively Practices Inclusion
  • Open Communication
  • Eats Lunch Together
  • Flexible Work Arrangements

Company Properties

  • B2B
  • B2C
  • Technical Founder(s)

Team Members

  • 70 Full-Time Staff
  • 20 Software Engineers (with hard-to-pigeonhole skill sets)

Vacation Policy

Annually: 10 companywide holidays, 21 days PTO, 10 sick days.

Tech Stack

Airtable’s core stack is written using JavaScript, augmented with static type checking and other tools. We use Node.js on the backend, and mostly-React on the frontend, but our application requirements drive a substantial amount of custom software architecture; that is, Airtable is pretty far from a boilerplate “React + Express” application. We also periodically evaluate adding other languages into our codebase for ecosystem or performance reasons. Mobile apps are currently written in the standard platform language, mixed with JavaScript in webviews where appropriate. Our production infrastructure runs on a variety of AWS services, principally using Terraform for deployment; for data collection, aggregation, monitoring, and alerting, we use a mixture of ELK and some carefully selected third-party services.

Interview Process

We are actively experimenting with our process, but currently start with an informal introductory call with a senior engineer. This is followed by a technical phone screen, a 4-hour take-home programming assignment, and an onsite interview which includes a code review of the take-home. We strive to ask only technical questions that resemble problems we’ve encountered in our real work, rather than arbitrary brainteasers or blank-slate whiteboard algorithms, and we encourage the use of your full programming environment to solve them.