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 few people can actually access it as a creative medium. Airtable enables everyone to experience the power of creating, not just using, software.
- airtable.com
- Blog
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 a 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. Our Interface Designer even allows our users to define customized interfaces to the programs they construct. By scaling these dimensions – further enriching data, tools, and interfaces – 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 opportunities and challenges embodied in these problems inspire 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, employee directory, 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 also 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 and automated 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 set in stone; we’re always discussing how to do better, and ideas can be raised by anyone from our newest hire to our 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 feature behind a flag 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.
Product delivery at Airtable is deeply cross-functional and collaborative. Software engineers work with product managers, designers, UX researchers, customer-facing teams, data insights partners, and quality engineers to understand user needs, propose and implement solutions, and evaluate outcomes. Engineers can be as involved with all aspects of this process as their skills and interests allow.
Here are a few things that our engineers can do as part of product delivery (collaborating with our partners in other roles):
- Analyze user behavior both qualitatively and quantitatively
- Conduct interviews with users
- Write specs and designs for new features
- Conduct “spikes” (timeboxed investigations to explore potential designs)
- Create UI mockups and prototypes
- Engage in detailed design and final production implementation
- Create an automated and manual testing and quality assurance strategy
- Define, implement, and analyze experiments and metrics that measure success
- Conduct blameless retrospectives on process and launch learnings
For a product like Airtable – a horizontal toolkit for software creation – every product decision has nontrivial, combinatorial implications for other related features. Having a hybrid product and engineering mindset is critical to designing building blocks that are simple and usable, yet powerful and flexible. Our ideal product engineer develops an intimate understanding of both the underlying technical architecture and the ideal user experience.
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 sometimes simmer on problems for a period of time before we start building. This preempts problems that may come up in the future and informs the sequencing of new features in a complementary fashion.
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 #diversity-equity-inclusion chat channel and other forums. To reduce bias in engineering hiring specifically, we’ve introduced standardized rubrics and assessment metrics for our interview process. We’re continually investigating methods for improving the diversity of our candidate pool. Our executive team leadership 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. We believe that companies should mold themselves to accommodate their employees’ work styles. Most of our communication is asynchronously accessible (see Flexible Work Arrangements below). 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.
Progress: We want all employees to create the biggest impact possible. We’ve instituted a program of training managers in coaching skills to maximize every report’s chance of success. Majority-identifying as well as minority-identifying engineering leaders lead our DEI working groups. We support both formal communities (ERGs) and organic communities (such as our Women in Eng group) which have developed within our organization – ask us about these!
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.
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 chats for fear of missing out on important conversations. Of course, there are plenty of times when real-time chats or meetings really are the best way to communicate, and we embrace those situations. But we try to deploy these communication modes thoughtfully.)
Flexible Work Arrangements
The past two+ years have brought a major shift in how we define our work environment.
We learned to operate in a virtual-first world and reflected on what matters most both professionally and personally. Some of us have thrived remotely, while others have been eager to connect and collaborate in person. With this in mind, we recognize there is no one-size-fits-all approach as our offices come back online (pun intended). We support each individual in determining the optimal work environment for their role while offering opportunities to stay connected regardless of where a person is physically located. We are learning and gathering feedback to make improvements as we go – we’re committed to applying a growth mindset to our approach, so we can ensure it’s working well and supports our growth as we scale. After all, we’ve never been through a global pandemic before nor pushed the limits of what’s possible in a distributed, hybrid work environment.
Our approach puts each individual’s needs first. Airtablets in Engineering can choose where they work best and can fluctuate between more days virtual and more days in office (i.e. one week you could choose to be in the office 3x/week, and the next week you may work from home exclusively). Here are some ways we support both work environments:
- Prefer to Work from Home. We understand many people prefer the flexibility that comes from working from home. Those who wish to work in a virtual environment are welcome to do so. While we won’t require employees to come into our offices on specific days of the week, people should anticipate getting together in person with their team at least 3 days per month for planning sessions, brainstorming, offsites, socials, and other collaborative events. Our goal is for teams to utilize in person time for activities that are best suited to live discussions and to help create meaningful connections. Meanwhile our leaders will continue to emphasize the importance of inclusive meeting practices, asynchronous communications, and documentation to ensure we’re aligned as a distributed community.
- Prefer to Work in the Office. For those who thrive in an office environment, we will provide an office experience that supports both independent focused work and collaboration. Our Workplaces team is developing “neighborhoods” in our larger offices with a mix of dedicated desks, cubbies, soft seating, and places to add some flair to represent what makes being part of Engineering so incredible. Teams may also have optional “suggested days” in the office each week to maximize opportunities for ad hoc conversations, collaboration, and social time.
Values
- Bonded by Love for Product
- High Quality Code Base
- Start-to-Finish Ownership
- Actively Practices Inclusion
- Open Communication
- Flexible Work Arrangements
Company Properties
- B2B
- B2C
- Technical Founder(s)
Team Members
- 220 Engineers (with hard-to-pigeonhole skill sets)
- 900 Full-Time Staff
Vacation Policy
Flexible vacation time; accrued sick time; parental leave for birthing and non-birthing parents; paid holidays; paid volunteer days; winter break; recharge 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. Mobile apps are currently native and use JavaScript in webviews where appropriate. Our data infrastructure, which drives our data science and business intelligence efforts, is primarily in Python. We periodically evaluate adding other languages into our codebase for ecosystem or performance reasons; philosophically, we try hard to standardize on a few languages and toolchains so that investments in tooling can be leveraged across larger fractions of our engineering effort. Our production infrastructure runs on a variety of AWS services, principally using Terraform for deployment; for logging, aggregation, monitoring, and alerting, we use a mixture of ELK and some carefully selected third-party services.
Interview Process
To start the interview process, you’ll connect with a member of our recruiting team to learn about open opportunities as well as to share your interests and aspirations. Next, you’ll complete a Technical Evaluation, where you’ll select between a technical phone screen or a take-home programming assignment. This is followed by a (virtual) onsite interview which may include 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.