Senior Software Engineer (Backend)

Introductory paragraph

As a Senior Backend Engineer at Community, you will have a deep impact on our platform and engineering culture as a whole. You will influence technology choices, support leadership in decision making, solve complex problems, and contribute to the future architecture of our platform.

About us

My name: Joe Merriweather-Webb
My position: Senior Software Engineer / Dev Lead
Company name: Community
Country: USA
Company info and history:

Community is a first-of-its-kind conversation platform — enabling direct, meaningful and instant communication at a massive scale, all through text messaging.

  • Our backend is largely asynchronous, written in Elixir, running in Docker containers, on a distributed, scheduled platform on AWS. We work w/ PostgreSQL, Cassandra, Redis, and RabbitMQ among others.
  • The front-ends are in React, React Native, iOS, and Javascript.

About the job

Job title:

Senior Software Engineer (Backend)

Job description:

  • Architect, design, write, review, and test code in a collaborative environment
  • Work closely with product managers, data scientists, front-end engineers, systems engineers, and the rest of the backend team to deliver a product that scales to millions of users globally
  • Build, test, and maintain scalable APIs, services, and systems within the platform
  • Ensure standards for engineering excellence, scalability, reliability, and reusability

Salary range:

$140k – $180k

Position on remote work:

Our backend team is remote-first and we do hire people outside of the US. This particular position is for a Pacific time based team, so a good overlap with that timezone will be needed. If you are in the Los Angeles area, you can feel free to work from the office in Santa Monica.

Qualifications or experience required:

  • 5+ years of production experience, preferably at scale, in backend development
  • A driving interest in TDD and testing, intentional design, and building quality software
  • Strong knowledge of databases, algorithms and data structures
    Initiative to explore alternative technologies and approaches to solving problems
  • Excellent communication skills, high EQ, and the ability to thrive in a fast-paced, agile environment
  • Ideal candidates will have experience with Elixir and/or Erlang, or a strong desire to learn

What the successful job applicant will be working on:

Coming up, our team will be working on core product features, load testing, and billing.

About the interview process

  • Phone call with our Talent Acquisition Manager
  • 1 or 2 Video calls with engineers
  • Take home code challenge in some cases (when engineer is more junior)

Further info

Please apply through this link to AngelList: and mention that you found it through elixirforum if you don’t mind, so that we know if this post is helpful. :slight_smile:


Community sounds really interesting!! Can’t wait to hear more about it :smiley:

1 Like

I’m not looking, but I just wanted to say that I see a LOT of job descriptions, and yours is really good. (Good technology, reasonable general qualifications, good responsibilities and interview process, recognition that remote is now very feasible…)


I’m looking for a new job. Yours is really appealing.

1 Like

You should really try Elm. Nobody talks about it but it’s such a good technology. We tried React but it was so heavy and cumbersome, so we decided to use VueJS, which was fine but it can get quite complicated and chaotic with bigger projects (Vuex just adds another layer of complexity and doesnt really make the code simplier) then we tried Svelte, which felt like a summer breeze, we really liked it (it was so good that VueJS team used the whole idea for Vue3). We’ve been using VueJS for many years now but I realized we are dealing with the same problem, over and over again: uncertainty coming from a change in code

No matter what I said to my guys they were from time to time too brave and too self confident about the changes they made in Vue or Svelte applications and they didn’t test the change properly or they didn’t think it through. OR they just felt like the code is too complex and they ought to make it more effective, understand broken, not tested, not covering all cases.

And then I stumbled over Elm.

First of all, both React and Vue are based on Elm the same way Java and .Net are trying to be Erlang but they are not and never will be because they added too many layers of complexity. So what is the point of using something that pretends and like to be simple but it’s not and never will be.

Secondly, Elm comes as a whole package. It replaces npm, webassembly, typescript, and so on. Compilation of our projects(nothing big but still) takes approximatelly 2seconds on very average SSD.

Thirdly, you as a programmer really have to cover all corners of your code and for me as a business owner that was really beautiful to see because in Vue you didn’t have to do that and so now I started to see new warnings displayed to users instead of just wondering what happened and looking into dev console hoping there will be something useful: but of course, “undefined property”

Another awesome thing is that the code is always the same for all applications, all programmers, all levels of programming experience, a “skilled” junior can make a mess in any programming language but here at least it has to be compilable. You have four main blocks of code and that’s it, everything else is just a helper function.

It’s really fast! Sometimes it’s so fast it feels to me like it was render on server. And it’s small. I remember way back when I started with React that React’s HelloWorld application had, after npm i, 480MBs [UPDATE: now it’s only 170MBs] of downloaded packages. The whole application had only TWO files the rest was the framework itself. (?!?!!???!!).

HelloWorld in Elm has 540kb, I’ve just tested it. So it’s the same range but different magnitude. :-)))

It’s pluggable into React applications. So if you are stucked with React you can still use Elm.

And lastly, it has very stable code base. Every once in a while there is a new version of Elm but all packages have time to grow with it and then it’s stable for another year or so.

Sorry for the of topic but whenever I see React I have to ask WHY?


Those are some great insights! I really appreciate the thought that went into this. I’ve been meaning to check out Elm for some time.