That\u2019s why I switched from working on product to infrastructure: we\u2019ve all seen those outages first reported by a customer because there\u2019s no monitoring, those cute sadface graphics so you\u2019ll be less angry at the software when it inevitably crashes, those late nights your coworkers spend toiling away at failed releases, missing database rows, or misbehaving firewalls. I wanted to create fully-automated solutions to those reliability issues, and use software instead of processes<\/u><\/a> to make infrastructure updates, inter-team schema changes, or data access safe. This can work very well: the systems I built reduced yearly downtime to minutes, and some were even fun<\/u><\/a>. I believe training people starts with meeting them where they are<\/u><\/a>, and infrastructure engineers have empathy as a core skill.<\/p>\n\n\n\n As a Platform Engineer at Ashby, you\u2019ll do that and more. Every Product Engineer owns their projects and ships with minimal oversight. We, as SREs, approach this from a practical view. We don\u2019t put roadblocks to ensure security when common sense will do and we don\u2019t build processes like change management boards around the lowest common denominator. But with great power comes great responsibility: we handle personal and confidential data about some of the biggest decisions we ever make at work. As we grow, more and bigger customers rely on us to be reliable and secure and how we operate internally will need to evolve.<\/p>\n\n\n\n We\u2019re at an inflection point where our ability to scale and deliver a seamless experience has a make-or-break impact \u2013 we have some of the fastest growing companies using our platform every day to hire hundreds of people per month. We need someone like you to make good decisions, debug thorny issues, and build us a future-proof platform that can withstand this scale. Our small but mighty infrastructure team has set up a secure and simple environment (we don\u2019t believe in spinning up a new service unless necessary!) for our growing product team to build in. That\u2019s where you come in: you, too, will own projects end-to-end and have an impact on core parts of the Ashby developer and user experience. For instance, you could work on:<\/p>\n\n\n\n We\u2019re looking for someone who can build systems that an engineer would like to work with: mature and boring but open-minded and approachable. We have to balance reliability with flexibility. Software and its availability are now mission critical to almost every working professional. To be in an SRE in today\u2019s world, you have to be extremely comfortable evaluating risk, those you take and those others take.<\/p>\n\n\n\n You should apply if:<\/p>\n\n\n\n All that makes for a pretty specific kind of role, and the job isn\u2019t to everyone\u2019s tastes! You should not apply if:<\/p>\n\n\n\n I\u2019m sharing our tech stack with the caveat that we don\u2019t require previous experience in it: TypeScript (frontend & backend), Node.js, React, Apollo GraphQL, Postgres, Redis.<\/p>\n\n\n\n We use Datadog and Sentry on 100% cloud-based (AWS) infra. We take developer experience and reliability seriously: all engineers are on call in a follow-the-sun model, and everyone contributes to developer tooling.<\/p>\n\n\n\n Talent teams aspire to build a hiring process that identifies great candidates, moves them quickly through the interview process, and provides an excellent experience for the candidate. To accomplish this, recruiters perform thousands of daily tasks to coordinate and relay information between candidates, interviewers, and hiring managers. Teams struggle to keep up!<\/p>\n\n\n\n Scheduling a final round is an excellent example of our customers’ challenges. A recruiter needs to collect availability from the candidate, identify potential interviewers, perform \u201cCalendar Tetris\u201d to find who is available to interview the candidate, schedule on the earliest date possible, and perform any last-minute adjustments as availability changes. They must perform this while considering the interview load on each individual and whether interviewers need to be trained and shadowing others. \ud83e\udd75<\/p>\n\n\n\n Ashby provides talent teams with intelligent and powerful software that provides insights into where they\u2019re failing and automates or simplifies many of the tasks they\u2019re underwater with. We put a lot of effort into designing products that are approachable to beginners but mastered and extended by power users. In many ways, spreadsheets set the bar here.<\/p>\n\n\n\n We have many customers, great revenue growth, years of runway, and amazing investors like YCombinator, Elad Gil, and Lachy Groom. I\u2019ll share more once we meet.<\/p>\n\n\n\n Our engineering culture is motivated by Abhik<\/u><\/a> and Benji<\/u><\/a>\u2019s (our co-founders) belief that a small talented team, given the right environment, can build high-quality software fast (and work regular hours!).<\/p>\n\n\n\n Our engineering team (and the team at large) consists of lifelong learners who are humble and kind (meet them here<\/u><\/a>!). These attributes create an environment where collaboration happens naturally (we filter for it in interviews). We combine this with research, prototyping, and written proposals to see around corners and get feedback from the team across time zones. Focus time is something that we hold sacred, and, with thoughtful and deliberate communication, engineers can focus 36h out of a 40h work week (Abhik wrote about it here<\/u><\/a>). Even managers can rely on getting consistent time (and support to make, if necessary) to focus and do creative work without the demand of constant meetings.<\/p>\n\n\n\n We built Ashby with the quality, breadth, and depth that many customers would expect from much larger teams over larger time scales. We\u2019ve done this through investment in:<\/p>\n\n\n\n Here\u2019s an impromptu quote from Arjun in our company Slack of what it\u2019s like to build a feature at Ashby: <\/p>\n\n\n\n \u201cWorking on a generic framework for Surveys is really paying off! I was able to add the Automation Rules feature to EEOC Forms really quickly because I had some generic components and backend code. Took about 10 minutes and ~50 lines of code to do!\u201d<\/p>\n\n\n\n We, as engineers, find clever ways to solve problems, which amplifies when we deeply understand the problem. All of us in technical leadership did our best work as engineers when we had a deep understanding of the end-user and the business and ownership over the solution. Our engineering culture reflects this experience: engineers own projects end-to-end, from speaking with users to writing product specs to UX design. These are skills that we often don\u2019t get to practice as engineers, and, as a manager at Ashby, you\u2019ll provide mentorship and feedback to engineers to ensure they are successful when delivering projects.<\/p>\n\n\n\n\n
Why you should or shouldn\u2019t apply<\/h1>\n\n\n\n
\n
\n
Technology Stack<\/h1>\n\n\n\n
What We\u2019re Building<\/h1>\n\n\n\n
Engineering Culture<\/h1>\n\n\n\n
Collaboration is Natural, Communication is Deliberate<\/h2>\n\n\n\n
Increase Leverage, not Team Size<\/h2>\n\n\n\n
\n
![\"\"\/](\"https:\/\/app.ashbyhq.com\/api\/images\/user-content\/4ea5f68e-c33e-4ac9-831a-e732bee4a303\/8d94727a-46d8-42a2-9627-ddcd7f822f95\/arjun.png\")
<\/figure>\n\n\n\nGive Engineers Ownership & Autonomy<\/h2>\n\n\n\n
Put Effort into Diversity <\/h2>\n\n\n\n