Software Engineer - Elixir - Remote - US timezone

Introductory paragraph

Our mission is to protect homes, families and communities from wildfire disaster, which we’ve been doing successfully now for two years.

We just hired the second software engineer, you’d be the third full time software engineer, so this is a great opportunity to have a significant impact on a very interesting and meaningful product.

You have significant programming experience but might be relatively new to Elixir. You’re autodidactic and can adapt to a new team with existing practices, you know how to balance your work and personal life, are comfortable moving fast, pushing boundaries, and breaking things. You’re a straight talker who tells it like it is, and finds no shame in being wrong. You work well in a team, supporting people when they need it, and getting out of their way when they don’t.

About us

My name: Jason King
My position: Head of Software
Company name: Frontline Wildfire
Website: https://www.frontlinewildfire.com/
Country: USA

Company info and history (how you’re using Elixir etc):

The problem that we’re solving is protecting homes and helping people safely navigate a wildfire situation. To protect homes, our external fire sprinkler system defends against embers, the #1 cause of structure loss from wildfires. To help people navigate a wildfire situation, we’re providing better mapping and alert resources so that our customers can track wildfire activity near them and receive important emergency notifications from the best resources available.

There are five elements to our system:

1. Firmware on the sprinkler controllers at client sites
2. A broker that manages communications with the controllers
3. A mobile app that customers use to control their systems and/or get fire-related information/alerts
4. An API server for that mobile app
5. Our incident center dashboard
6. A web app for our install crews

Everything there except the mobile app will be in Elixir.

I’m in the middle of rewriting our prototype API server and dashboard in Elixir (Phoenix), and then we’ll be adding an MQTT broker which will probably be VerneMQ with a bunch of custom (Elixir) plugins we’ll need, and later this year we start working on the next version of the controller which we plan on writing the firmware for using Nerves.

About the job

Job title: Senior Software Engineer

Job description: The role is mostly dev, but there’ll be occasional ops and support until we grow enough to have a dedicated ops team. You need to be ok being one of three engineers sharing these duties.

Salary range: Pay is negotiable based on experience, but we’re looking to fill the role in the $80-110k range, or comparable hourly rate if that’s what you prefer. We have an unlimited vacation policy, assistance is available for setting up a home office if necessary, and we have a generous equity plan for all employees.

Position on remote work: With team members in Wyoming, California and Illinois, we’ve always been a fully remote and distributed team. We tend to operate on Pacific time, but software dev will generally be asynchronous.

Qualifications or experience required:

• Competent in Elixir and Phoenix, with strong experience in Websockets and API development
• Expert in some other similar framework (ideally Rails)
• Expert in the web stack: HTML, CSS & JS
• Expert in SQL DBs, especially Postgres
• Bonus if you’ve dealt with GIS and spatial queries in PostGIS

What the successful job applicant will be working on:

You’ll jump in immediately on the API/Dashboard rewrite work, eg. next two tickets are to handle the incoming messages from the broker, updating the DB, triggering alerts; and to handle the outgoing messages from the mobile apps, storing copies in the DB, restarting gracefully on failures, resending on timeouts, etc.

After that we have a ton of other push notifications based on spatial queries for customers within certain radii of incidents, including some smart automation for those both periodically, and based on moving event boundaries.

We then have a number of new enhancements for the API to support a new app for our installation teams to use, a heap of work to create a high value dashboard, and many more things after that.

About the interview process

I’ve accepted that it’s not possible (at least for me) to create an effective proxy that identifies people who actually work well in a given role in a given team. There are just too many variables, and any interview, test or trial process is fraught with both false positives and negatives. You have to settle into a team, into a role, learn the ropes, mesh with personalities, find your place, and all that stuff.

As such my main goal in an interview process is to tell you as much as I can about us: about the company, the role, the team and me. I tell the good and the bad. I find the number one issue when joining a new team is that you discover a bunch of crap about the company that you really don’t like, I try to mitigate that as much as possible.

My secondary goal is to see how well you use the sorts of communication channels we use. To this end, if you have examples of your participation in forums, or maybe open source tickets, including that in your CV or cover letter would be great.

1. In your application, please send: your CV, a cover letter, and a sample of your code that you’re proud of with an explanation of why you’re proud of it.
2. If I like your code and explanation then the next step is to connect with you in chat, we use chat a lot, and so it’s important for me to see that you’re adept at that channel of communication.
3. Finally, I like to connect on a video call, another medium we use a fair bit.
4. If you want to, I’ll set up an interview for you with anyone else in the company you’re interested in talking to.

At any stage, if I decide we’re not a good fit for each other, I’ll let you know and explain why.

You can email me at: jking@frontlinewildfire.com