Research-Product Collaboration (OpenAI Culture)

OpenAI's defining structural bet is that frontier research and mass-market product live in one company, on one model lineage, often on one hallway. That makes the research-product seam the place where much of the engineering actually happens: productionizing a training-team artifact into an API that millions depend on, building evaluation and serving infrastructure that researchers iterate on daily, or feeding deployment observations back into research priorities. The seam is genuinely hard because the two sides optimize differently by design - research needs freedom to explore, tolerates messy code as the cost of iteration speed, and measures progress in capability; product needs stability, tolerates capability lag as the cost of reliability, and measures progress in what users can depend on. Neither side is wrong, which is what makes naive collaboration fail. Interviewers probe for candidates who have worked a seam like this - with researchers, data scientists, ML teams, or any function whose incentives and norms legitimately differ - and who bridged it with respect running in both directions. The strong signals: you translated between the dialects (turning 'the eval numbers look better' into deployment criteria, and 'we need reliability' into constraints a researcher can design against), you built paved paths that made the other side faster rather than gates that made them slower, and you can name something you learned from the other side's way of working. The anti-signals are contempt in either direction - the engineer who 'cleaned up' researcher code condescendingly, treats research as an upstream vendor, or polices standards without understanding why the mess was rational - and the pushover who shipped unreproducible work rather than have a hard conversation.