3 ms·
Smarkets | Full Time | ONSITE (London, UK; now also Downtown LA, California) We're a modern betting exchange, going technology first to enable proper price com
by bostik 9y ago
Smarkets | Full Time | ONSITE (London, UK; now 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, Erlang (being replaced with C++) and Javascript for React, relying heavily on asynchronous programming techniques. 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 in the following roles:
* Front-end Software Engineer - React (London, LA)
* Senior Front-end Software Engineer - React (London, LA)
* Senior Security Engineer (London)
* Senior Infrastructure Engineer (London)
* Mobile Developer - React Native (London)
* Senior Mobile Developer (LA)
* Senior Backend Engineer, Erlang/C++/Python (London)
* Software Engineer (London, LA)
If you like the idea of flat structure and practical engineering approach, see our jobs at https://smarkets.com/careers/ https://smarkets.com/careers/ .
- zura 9y ago> Erlang (being replaced with C++) Interesting. Any back-story about this? Also, what libraries do you use as processes (and OTP) alternative (if any)?
- blah_blah 9y agocurious too
- bostik 9y agoI'll provide the short version, and will encourage the exchange team to do a proper write-up once they feel ready for it. But to provide proper context, keep in mind that everything below is considered with a trading exchange in mind. Distilled down to bullet point material, the change is driven by: - language ecosystem; support libraries for Erlang are, regrettably, not that well maintained - familiarity; the team maintaining and improving the exchange stack are not Erlang experts but know C++ pretty well - hiring pool; finding good engineers who know Erlang is impressively hard. Intersection with engineers who have been exposed to financial exchanges is ... well. - performance; as I've been explained to, the underlying data structures in Erlang are designed for maximum concurrency and share-nothing model (the Actor pattern in its pure form). These impose constraints that happen to hit the hot paths pretty hard. And related to that... - memory model properties; exchanges rely on data structures whose critical paths cannot avoid invasive operations. Routinely working around your runtime's central assumptions is not exactly a best practice, regardless of the language used. I will let our exchange team tell the complete back story, in their own style and with their view from the trenches. Known interest probably helps.
- zura 9y agoThanks! It seems Erlang was not a best choice in the first place, for your project. Yes, please share the complete story when it's written.
- ugh123 9y agoSuch a better posting than the other by 'smarketshiring'. Thanks for the detail
- bostik 9y agoYou're welcome.