supremum

Enterprise datasets are like Tolstoy's unhappy families – each is ugly in its own way. Whereas most people want to make this someone else's problem, you are that someone else: you seek to create order from chaos, and you kinda understand what they're doing in Severance. We work with enterprise data, and we need to make enterprise data work with our models. Typically, that involves writing pipeline code (mainly in SQL), staring at line 1437 of the raw data, and calling someone on another continent to ask about line 1437. You will of course do these things, but you will also build agents that do these things, and your job will eventually become ensuring that these agents do these things correctly every time.

We train models, and we build tools to help people use our models at work. Your job is to make the user experience seamless: hard questions return useful answers, reliably and in seconds. You'll need to do a lot of core ML engineering—maintaining a cloud inference service, defining APIs, optimizing data pipelines and KV caching—but really this job is about puzzle-solving. Our models are designed to answer counterfactual questions of the sort, what if the business did X? Would that be a good idea in the long-run? Often, users want to know what X, among infinitely many possible X's, they should choose. Your job is to tell them, reliably and in seconds.

We have some interesting problems. For instance, we train on proprietary data from our clients. Some data are richer than others. How can we quantify data richness and use it as a weight in training? Or, querying the model out of distribution is a bad idea, but our action space is typically too large to implement conventional penalties like in CQL. What should we do instead? These are hard problems, and your role is to find good solutions, and to publish what you discover. You need to be intellectually curious, but you need to be driven to improve our models even in ways that are not publishable. If you suspect that restructuring the data could improve model performance, you write some SQL to find out. If your architectural change breaks training, you fix it. Being a good engineer is a prerequisite for being a good researcher.