In this role you will...
- Own Fig's Autocomplete App. You will be in charge of the app's UI and usability. You will maintain Fig's custom bash parser. You will also maintain Fig's autocomplete engine which takes what a user has typed + a completion spec and generates suggestions accordingly.
- Own Fig's autocomplete standard. You will maintain Fig's open source, declarative completion spec standard. You'll make sure it caters to every CLI tool. You'll work with the community on adding new functionality while making sure it stays simple and accessible to new developers.
- Own Fig's integrations with CLI tools. There are thousands of CLI tools. Fig has the seemingly impossible task of integrating with all of them. You will work with developers and sometimes companies (like Docker, AWS, or Heroku) to make sure publicly contributed specs follow the standard you have defined. You will also support contributors in our withfig/autocomplete repo.
- Ideate on new autocomplete experiences. Fig's autocomplete shouldn't just be limited to suggesting subcommands, options, and arguments. Fig can put anything in that tiny autocomplete box. You'll work on new additions to autocomplete like history and shortcuts and even build new products on top of this (for instance, shared history across teams).
- Wear many hats. We are a fast growing startup. We all have to be generalists. You will be working users, companies, and Fig developers for autocomplete. But you may also find yourself doing support, scaling infrastructure, or even
You will be a great fit if...
- You are product minded. You put our users first. You have a sense for creating magical user experiences. You will put in the extra work to make sure the user doesn't have to.
- You move quickly. We prototype things very quickly. We push updates to autocomplete every few days. No coding challenge is impossible. You will find a way to get something working.
- You've built developer tools before. You understand the many many usability issues at play when building a developer tool. You establish sane defaults but give users the option to fully customise things if they want to.
- You are good at systems design. While you are building autocomplete for users, you are building the autocomplete standard for developers. You can encapsulate complex ideas in simple language.
- You are mission driven. You are working at Fig because you want to re-imagine the terminal. You are building Fig to make your own life easier as well as the millions of other developers who use the terminal every day.
- Swift/Objective-C/C for our macOS app. Our pseudoterminal, window management, CLI, and our menu are written in combinations of these languages. We also make heavy use of macOS accessibility APIs.
- A lot of shell, CLIs, and systems We wrote integrations with bash, zsh, and fish in their respective languages. Our autocomplete app has to integrate with just about every CLI tool... We also go deep into signals, processes, and file descriptors.
- Modern work tools. Linear for issue tracking, GitHub for source control and open source, Sentry for error reporting, Segment and Amplitude for analytics, Discord for community management and internal communication, Notion as knowledge base. A few others.
Some of the engineering challenges we've faced
- Defined a declarative standard for building autocomplete for CLIs
- Wrote a left-to-right bash parser from scratch
- Used zsh's ZLE module to accurately get your current buffer and cursor position when typing in zsh
- Used the macOS accessibility API to get your cursor position in an application we don't own
- Used UNIX sockets and Docker’s dockerd API to get a container’s current process and working directory
- Injected a custom API into a WKWebview that gives web apps the ability to run local shell commands