Hey, I’m Michael Bilow, Head of Data Science at tvScientific. I’m hiring a Senior ML Engineer working in Zig and Python. We’re a Series A startup building a low-latency ML inference engine (and much more) as part of our Connected TV ad-buying platform. We’re looking for Senior and Staff level Machine Learning Engineers with experience in Zig and Python to join our growing team!
What you’ll do:
Write production code in Zig, Python, and C
Design and implement new ML products to deliver clear performance from connected TV advertising
Serve as a technical lead and mentor to the team
Ideal candidate:
Ability to write & review production-level code in Zig and Python
Excellent writing skills
Strong statistics and ML fundamentals
Desire to work at a fast-growing Series A startup–working under uncertainty, owning and scaling new products, and an experimental and iterative development process
Why join us?
An engineering culture optimized for async work and learning; remote-first, flexible, and humane.
Competitive salary and equity options.
An enormous diversity of high-leverage problems, from the CPU/GPU core level, through distributed systems, and up to the ML training stack and the experimentation around it. You can work at whatever level you think is interesting and leverages your skills the best.
We already got a couple of really strong applicants! Which should not deter people from continuing to apply, it helps me make the case for investing further here.
You could probably just write like a Zig binding for LibTorch, then from there you could either just use that or derive a pure Zig implementation. This would not totally replace a PyTorch/Jupyter model, but you could write some specialized code to offload some of the work and from there scale it using something like a Zig implementation of coroutines.
The complicated part of our work at tvScientific today is writing a really high performance web server to serve a simple ML algorithm at sub-millisecond latency via C bindings (zig excels here) rather than writing a custom ML algorithm or writing “easier CUDA,” which it looks like Mojo excels. We are purposefully not cutting edge in our choice of ML algorithms today.
Depth and time-to-value; Hans Musgrave (hmusgrave (Hans Musgrave) · GitHub) who’s skilled in zig, joined us in January, and wrote a POC service in zig in April that blew our previous Python implementation out of the water. Everyone in the team is pretty good at Python, but no one is experienced with Mojo’s unique benefits, so it feels too speculative for us to pursue—no one is the expert who can teach the rest of us.
The whole mojo/MAX thing doesn’t seem great either.
I’m excited to report that after talking with @michaelbilow and the awesome team at TVScientific, I have finished the interview process and accepted the offer to join the team! I’m thrilled to be working in Zig as the main language for my job - I genuinely didn’t see that coming.
There’s probably more of a need for “practical” ML/Data Science (i.e. Python), Data Visualization (Python/??), Data Engineering (Scala), and DevOps (AWS/Terraform) in the remaining open roles and they’re leveled junior/mid-level/senior versus senior/staff. If you’re interested in Zig and have a strong machine learning and stats background, please apply! I will definitely be able to give you some Zig work, and you’ll have some exceptionally strong coworkers.
Also I have a Head of Insights (Staff Tech Lead Manager) role available. TLM roles are some of the most challenging out there, but if you have a great technical vision and are interested in trying management, I’m open to candidates who haven’t managed people before. The Venn Diagram of people who love systems programming and love being the human face of Data Science reporting might be two disjoint rings, but if someone wants to prove me wrong, please send me an email.
I would consider applying (no idea if I have enough zig chops for it though), but I am soured by anything related to machine learning, pretty much in the spirit of this article. Good luck with the search!
Yep, I hear you; and I wouldn’t defend the current state of the AI/ML industry, especially given what investors/lazy journalists/salespeople/laser-eyed LinkedIn “personalities” say about it. However, I’ll say a few things that differ between my team and my impression of who that article is going after.
We’re a probabilistic ML shop, not a generative AI shop. My academic background is in computational stats and I use that regularly in my work; we’re not building another chatbot.
Our ML use case is on the critical path for how the company delivers value. One of the frustrations that article mentions is that people are “doing” AI or “doing” ML because it’s so hot right now. You can get a fawning article in the trades, MSNBC coverage, a juiced stock price, etc. by announcing that you’ve “adopted AI.” But, it’s not on the critical path to value for most big companies. For us, the game is a lot simpler (and a lot harder, since we have a clear dollar-valued metric). Buying ads less badly using cheap & fast ML increases our customers’ returns, which increases their willingness to spend money with us, which makes the business more money. This also means the stats are harder to juke in a good way. If we train a new ML model and the cost per outcome rises, we roll it back and try to figure out why.
It’s been a truism since the 1970s, that a problem with Artificial Intelligence is that, as soon as it solves some problem, that problem stops being Artificial Intelligence and is now just “programming”.
Let’s not forget that our phones, and for some of us, our watches, can transcribe what we say into text. I’ll stick with that one example, but there are many success cases for ML, and the field shouldn’t be conflated with LLMs at all, let alone the hype surrounding them.
I happen to like chatbots, although I’m always baffled when intelligent people insist that they can think or reason, since they’re manifestly incapable of either of these things. But they’re neither the be-all nor the end-all of “programming via the crunching of large matrices”.