Have you designed, built, and operated distributed systems? Have you monitored and administered JVMs, databases, and other infrastructure? Are your Elixir and functional programming skills second to none? If so, then you should consider joining us at Shoreline Software.
At Shoreline, we believe operators shouldn’t wake up when servers go down, systems should be fault tolerant & self healing, and stability comes from automatic adjustments rather than operator alarms. A control plane built on adaptive feedback control will enable this. Operators can then focus on automating issue resolution instead of watching dashboards and manually grinding ticket queues.
We are building a distributed control plane designed for scalability, fault tolerance, and portability. We are creating an ops language that is concise, fluent, and distributed. We are a small, but well funded, team looking for Elixir engineers from all over the world to deliver this system. We pay competitively. While this position can be remote, you may be asked from time to time to travel to and work from the main office located in Redwood City, CA.
Learn more: https://shorelinesoftware.com
My name: Charles Cary
My position: Founding Engineer
Company name: Shoreline Software, Inc.
Company info and history (how you’re using Elixir etc) :
About the job
Job title: Elixir Engineer
Job description: See above.
Salary range: Competitive
Position on remote work:
While this position can be remote, you may be asked from time to time to travel to and work from the main office located in Redwood City, CA.
Qualifications or experience required:
We need people with strong Elixir skills and experience with at least one of the following: distributed systems, DevOps (AWS, GCP, Azure or on-prem), machine learning, or language design & implementation. Written English competency, confidence & ability to work in a remote team, git skills, and competency writing tests are required. Open source contributions, experience operating systems at scale, and commercial experience with Erlang/Elixir are all pluses.
What the successful job applicant will be working on: See above.
About the interview process
If interested, please design and implement a solution to the following problem. Email the solution (attach or include link to repo/gist) and a resume to email@example.com.
Imagine you are building a system to assign unique numbers to each host that you manage. You want the ids to be guaranteed unique i.e. no UUIDs. Since these ids are globally unique, each id can only be given out at most once. The ids are 64 bits long.
Your service is composed of a set of nodes, each running one process serving ids. A caller will connect to one of the nodes and ask it for a globally unique id. There are a fixed number of nodes in the system, up to 1024. Each node has a numeric id, 0 <= id <= 1023. Each node knows its id at startup and that id never changes for the node.
When a caller requests a new id, the node it connects to calls its internal get_id function to get a new, globally unique id. The last_id that the node gave out is passed as a parameter to get_id.
Your task is to implement get_id (interface below). You are given helper functions for getting the node id and the current timestamp. There is no need to implement these functions.
defmodule GlobalId do @moduledoc """ GlobalId module contains an implementation of a guaranteed globally unique id system. """ @doc """ Please implement the following function. 64 bit non negative integer output """ @spec get_id(non_neg_integer) :: non_neg_integer def get_id(last_id) do end # # You are given the following helper functions # Presume they are implemented - there is no need to implement them. # @doc """ Returns your node id as an integer. It will be greater than or equal to 0 and less than or equal to 1024. It is guaranteed to be globally unique. """ @spec node_id() :: non_neg_integer def node_id @doc """ Returns timestamp since the epoch in milliseconds. """ @spec timestamp() :: non_neg_integer def timestamp end
You may add other functions to the implementation in order to complete your solution. If you must modify the interface to get_id to complete your solution, please provide an explanation as to why this change is necessary.
Assume that any node will not receive more than 100,000 requests per second.
Please choose a structure for your global id and describe it. For each part of your structure, please explain why it is necessary and include any defining information such as size (in bits). If applicable, explain how the size of the section is related to the maximal request rate per node.
We will evaluate your solution for correctness, simplicity, clarity, and robustness. Providing tests is a huge plus.
If you have any clarifying questions, please email: firstname.lastname@example.org
- Submit your solution and resume to email@example.com
- Informational phone screen where we can get to know each other, ask/answer any questions, and evaluate fit (1hr).
- Technical phone screen with live coding (1hr).
- Final round of technical interviews with the team, live coding and other questions (~4hrs).
We will get back to you quickly after each step in the process.