Smarkets | Full Time | ONSITE [REMOTE during the plague] (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 and agile team in our beautiful office in St. Katharine Docks. If our US location tickles your fancy, you get to help setting up a sunny satellite office too. For the time being, thanks to Covid, we are in fully remote mode.
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 & React-Native, relying heavily on asynchronous programming techniques. The tech stack sports Kafka, Postgres and Kubernetes. We use REST where we can, and gRPC where we can't. Life at Smarkets circles around people, version control, configuration management and automation. We can - and do - deploy to production several times a day.
Production environment 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 and mobile, 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 .
---
ß: to pre-empt questions on why C++ or why not Erlang - our exchange team have promised to put together a proper write-up on the tradeoffs, design constraints, performance needs, etc. In fullness of time, that is, when the most painful (and probably interesting) migrations are behind them.
Curious how the Erlang->C++ progress is going? I asked a bit over a year about it (which I think prompted the pre-emptive note :) ); obviously not owed an explanation but perhaps you can get a quick update on whether the migrations are more painful than expected, or the scope of changes in-/decreased, etc?
Oh hi! It's going on - and indeed, your question prompted the note.
As one might expect, the original scope was ... insufficient. The exchange team have taken over the responsibility for new customer-facing stream API. The current one is starting to bump into a number of edges that were not obvious two years back.
I can however happily say that the first major migration is complete: the team moved settlements from the old Erlang-based system to C++. (The final remnants of the old component were removed from our tree less than a month ago.) This doesn't necessarily sound like much, but it required a lot of walltime due to multi-month shadow deployment. Since the last time we visited the topic, they have also migrated the market state updates from their old "teed off" feed to a dedicated subsystem with higher throughput and better reliability - though not without hitches.
A kafka client library bug caused them (and our customers) quite a lot of grief. The postmortem for that was rather uninteresting, even if the visible impact was bad enough. When the solution to a problem is "downgrade client library, wait until upstream fixes are in place, avoid local delta", the technical aspect scores quite high on boring.
Another component, a customer-facing "recent orders cache" subsystem written in C++ now augments its Erlang predecessor. A service designed to run in a K8S cluster from inception is obviously an easier deployment and maintenance target.
The two really big ones left are the actual exchange core ("matching engine") and market maker trading API. Both under active development. It'll probably be some months still before the new trading API can take over. And it will be a long road to validation, but the matching engine has also recently graduated to an early shadow mode, feeding off of the the order flow spigot.
Adding more information since yesterday. The location requirement can be relaxed, although we're currently doing this on a case-by-case basis. (We're still figuring out how to adapt longer term to a potentially plague-ridden world.)
Our hiring team is aware of the context. You should contact them directly at hiring@smarkets.com - and they'll take it from there.
It is, yes. But considering how the situation with the plague has progressed, and how physical location means slightly less than it used to, I'll check with the team tomorrow.
We're a modern betting exchange, going technology first to enable proper price competition in a field of fat commissions. Join a small and agile team in our beautiful office in St. Katharine Docks. If our US location tickles your fancy, you get to help setting up a sunny satellite office too. For the time being, thanks to Covid, we are in fully remote mode.
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 & React-Native, relying heavily on asynchronous programming techniques. The tech stack sports Kafka, Postgres and Kubernetes. We use REST where we can, and gRPC where we can't. Life at Smarkets circles around people, version control, configuration management and automation. We can - and do - deploy to production several times a day.
Production environment 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 and mobile, 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 .
---
ß: to pre-empt questions on why C++ or why not Erlang - our exchange team have promised to put together a proper write-up on the tradeoffs, design constraints, performance needs, etc. In fullness of time, that is, when the most painful (and probably interesting) migrations are behind them.