Applied Operations Research Engineer

Job description

We are building the world's decision infrastructure: the strategic twin of every industrial organization for complex combinatorial problems. We unlocked what wasn't possible before: mapping reality with its levers and constraints into a computer, then running n-dimensional optimization on critical value-chain decisions. We help Europe stay strong and the German Mittelstand make good decisions between market shifts, orders, machines and people. Founded by Dana (CEO) and Erik (CTO) from RWTH research, backed by a €2.8M round led by Vorwerk Ventures, with customers live on our optimization models. We move fast. We care. No patience for problems left unsolved. Your mission Hi, I'm Erik, CTO of Circonomit. This ad is specific on purpose: you should be able to tell from it whether this is your job. We build decision infrastructure for industrial companies: our customers model their production, with its capacities, costs and constraints, and we compute the answer to "what should we do?" before the decision is made. Our engine turns that model into one artifact that both evaluates like a spreadsheet and optimizes like a solver. It sits between two worlds: the mathematics that makes the answer correct, and the product that has to make it usable by people who are not mathematicians. That bridge is your mission. You work with our math and OR team to translate real customer problems into models, and you develop the engine that runs them. We will not sugarcoat it: combinatorial search is unpredictable, customer data arrives messy, and some weeks a deadline sets the priority. What you'll own Customer models, end to end. Turn a planning problem, with its capacities, costs, lead times and shift plans, into a model whose answer a plant manager acts on. That includes the data it runs on: ERP and Excel exports, and catching the numbers that cannot be right before the customer does. The interface between software and mathematics. Our engineers, and eventually our customers, build and extend models without needing us in the room. That means deciding where the abstraction belongs and what the modeling vocabulary has to cover, then building it and keeping it standing. Answers people can act on. A planner watches the number improve, can defend it in a meeting weeks later, and still gets something usable when the honest answer is "impossible": which rules collide, and what it would…