4 ms·
Smarkets | Full Time | ONSITE (London, UK; also Downtown LA, California) We're a modern betting exchange, going technology first to enable proper price competi
by bostik 7y ago
Smarkets | Full Time | ONSITE (London, UK; also Downtown LA, California)
We're a modern betting exchange, going technology first to enable proper price competition in a field of fat commissions. Join a small, agile, and fast-growing team, in our beautiful office in St. Katharine Docks. If our US location tickles your fancy, you get to help setting up a brand new office too.
Smarkets develops a reliable, low-latency, highly concurrent betting exchange based on trading exchange designs. We're also building a fast, modern web interface to allow for a smoother experience. Servicing our users is top priority.
The Smarkets platform is written predominantly in Python, C++ (replacing still present Erlang) and Javascript for React, relying heavily on asynchronous programming techniques. The tech stack sports Kafka, Postgres and increasingly Kubernetes. We use REST where we can. Life at Smarkets circles around people, version control, configuration management and automation. We can - and do - deploy to production several times a day.
Our entire production is in AWS. In fact, Smarkets was the first gambling operator under the Maltese regulator to get permission to run everything in the cloud. We push the envelope where needed and educate auditors when necessary.
We are looking for engineering talent all across the board: frontend, infrastructure, trading engine, security - and of course generalists, those yet to find their calling.
If you like the idea of flat structure and practical engineering approach, see our jobs at https://smarkets.com/careers https://smarkets.com/careers .
- mc_ 7y agoAny explanation on why you're moving away from Erlang to C++? Curious about the tradeoffs you're making with that decision.
- bostik 7y agoRight, twice in three months... Our exchange team have promised to do a writeup on the technical and design tradeoffs with regards to the language transition. I'll prod them a bit, and maybe we shall have a properly exhaustive post on this in near future. The TL;DR is fairly simple, though: * availability of talent * memory model suitability As far as I have been let to understand, Erlang's shared-nothing model works quite well for a trading client. (As long as cross-market/cross-contract correlations are within reasonable limits.) In our case, it doesn't do as well as a trading exchange runtime. When you have more than 100k limit-order books across tens of thousands of contract groups (or "markets"), rapid updates to a lot of them become quite expensive. You probably could design a robust sharding strategy to handle that, but then again, that takes a very specific kind of talent. Considering the first point above...
- dang 7y agoThat post would probably be of interest to a lot of HN readers. If they want, we can look over a draft if someone sends it to hn@ycombinator.com. Just be aware that we can't always reply right away—our worst-case latency sucks. Same offer goes for anyone else who's putting a lot of work into a post they hope will interest HN.
- mc_ 7y agoInteresting, thanks for the teaser :) I'll look for the writeup as well!