We are already an international team (Swiss, Italian, German, UK) and are open to EU/EEA candidates. All project language is English. While German is an advantage, we care more about your attitude and sharing our passion for mountains, nature and freestyle.
Python engineer is a little broader, but it’s generally production systems and infrastructure development for things that aren’t required to be c++. algo software engineers support algo devs (quants) in their research questions.
VKontakte, the Russian Facebook, has another ID system entirely: each namespace kinda gets its own ID sequence. Pavel Durov is unsurprisingly ID 1. Group 1 is the group for app developers, but no idea what it was initially. Other objects are identified by a (type, owner ID, object ID) triplet, the object ID is unique within the type and the particular database server that's chosen based on the owner ID. Really simple to work with once you get into it. Does Facebook use a single global ID namespace for everything?
> Facebook engineers know that VK engineers are serious as a heart attack.
Lmao. To be honest, it's surprising VK works as well as it does. Especially with all those custom, written-from-scratch databases aka "KittenDB". Oh and did you know that all strings are stored internally in the Windows-1251 encoding? And because it's an 8-bit Cyrillic encoding, characters that can't be represented in it, are stored as HTML entities. The API used to spit strings out exactly as they were stored, except converted to UTF-8, and it has caused me a lot of pain as an app developer. Their removal was a big thing: https://vk.com/wall85635407_3133 (btw here you can see the ID structure: "wall" is the type, wall post, 85635407 is the owner, 3133 is the post ID).
Some ancient version of KittenDB is open source: https://github.com/vk-com/kphp-kdb, I managed to set it up on my server, but tbh you'll be better off using just about any other sufficiently popular database out there. This thing uses a binlog, keeps as much data as possible in-memory, and the schema is very fixed. It's basically a *-engine per every possible purpose.
I second your opinion (interned @ Athena, not Quartz) - compared to my current BigN experience everything was worse by a magnitude: the IDE, the source control, the review mechanism, the job scheduler and so on.
I'd expect with so many devs working on this the DevX will be ironed out
I assume you are open to hiring EU/EEA candidates too, correct? (ones who will need Aufenthaltsbewilligung)