In this role you will...
- Be the main point of contact for all of Fig's users. Your job is to make sure every Fig user has a fantastic experience and that the app works as expected. You will engage our users across many channels (email, Discord, Twitter, GitHub, meetups, video calls...)
- Play a key role in prioritising Fig's roadmap. The best companies talk to their users. You are the bridge between Fig and its users. You will have the best insight into the things the users want the most. The company will rely on the pain points you identify to build our next product.
- Create a scalable self-serve support system. No matter how big Fig is, we want our support to be world class. Having a robust system that can scale with the number of users and the number of products is crucial.
- Contribute to Fig's autocomplete repo. A lot of user problems are specific to Fig's autocomplete specs. This means you need to be able to go deep on just about any CLI tool in order to make the changes in the relevant completion spec.
You'll be great if...
- You put users first. No matter what the issue, big or small, you are willing to go above and beyond to help. Our users should not just rave about our support, but should rave about you.
- You can communicate well with developers. You can also communicate complex ideas simply. The difference between a 50 word answer and a 150 word answer is actually quite profound.
- You have a good working knowledge of the terminal, shell, and a wide array of CLI tools. We often debug user's terminal issues that aren't even related to Fig (we do this to go above and beyond). You should be comfortable with things like dotfiles, SSH configs, and some of the differences between each shell.
- You are enthusiastic. You love talking with people, learning more about them. You make every user feel special.
- 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