What do interviewers evaluate in Research ↔ Product questions?

Interviewers listen for signals like: Have you actually worked a seam between functions with legitimately different incentives - research/ML/data science and production engineering? Do you respect why the other side works the way it does, or does contempt leak ('researchers write terrible code')?

gitGood.dev

OpenAIAdvanced Premium

Research-Product Collaboration (OpenAI Culture)

OpenAI's products are research made deployable - engineers work daily with researchers whose goals, pace, and code norms differ from theirs. Interviewers test whether you can bridge that seam productively.

About this theme

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.

What interviewers are evaluating

→Have you actually worked a seam between functions with legitimately different incentives - research/ML/data science and production engineering?
→Do you respect why the other side works the way it does, or does contempt leak ('researchers write terrible code')?
→Can you translate both directions - capability claims into deployment criteria, and reliability needs into constraints researchers can design against?
→Did you build paved paths that made the other side faster, or gates that made them slower?
→When the two sides' goals genuinely conflicted (launch date vs. eval bar, iteration speed vs. reproducibility), how did you resolve it?
→Can you name something you learned from the other side's way of working?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Tell me about taking something from prototype or research code to production. How did you work with its authors?
?Describe collaborating closely with a team whose goals or working style conflicted with yours.
?Tell me about a time you had to push back on shipping something that wasn't production-ready, when its creators thought it was.
?How have you made a research or ML team faster rather than slower?
?Tell me about translating between technical audiences who talk past each other.
?Describe a conflict between iteration speed and engineering rigor. How did you land it?
?What have you learned from working with researchers or scientists that changed how you engineer?

Sample STAR answers

Both strong and weak examples, with notes on what makes each work (or fail). Read the weak examples carefully - the patterns they show up are the ones interviewers are trained to spot.

STRONG

Strong: productionizing the ranking model without breaking the researchers

Prompt: "Tell me about taking something from prototype or research code to production. How did you work with its authors?"

Situation: At a marketplace company, our two-person applied-research team had built a new search-ranking model that beat the production system by 8% on offline metrics. It lived as a research artifact: a notebook-driven training pipeline, handwritten feature extraction that only its authors fully understood, and no reproducibility guarantees - retraining from the same inputs produced slightly different models. I was the senior engineer assigned to get it into production, where it would serve every query on the site. The previous attempt at this handoff, a year earlier with a different engineer, had ended with the researchers feeling policed, the engineer feeling stonewalled, and the model unshipped.
Task: Ship the model to production reliability standards without turning the researchers into ticket-takers for my requirements - and without becoming the reason the next model takes a year to land. The relationship was the deliverable as much as the deployment.
Action: I started by paying the respect cost the previous attempt had skipped: I spent my first week working the way THEY worked - rerunning their notebooks, reading their experiment logs, asking why the pipeline was shaped the way it was. That week changed my plan, because most of what looked like sloppiness was rational under their incentives: the notebook pipeline existed because they retrained with new feature ideas several times a week, and any structure I imposed that slowed that loop would be routed around, deservedly. So instead of demanding they meet production standards, I drew a contract line: everything upstream of a trained model artifact remained theirs, structured however they liked; everything downstream - validation, canary, serving, rollback - was mine. The interface was the artifact plus a manifest (data snapshot, config, eval scores). Then I built the paved path that made the contract cheap: a one-command tool that took their artifact, ran the reproducibility check and eval suite, packaged it for serving, and generated the manifest. Reproducibility was the one fight worth having - unreproducible models are undebuggable incidents waiting to happen - and I made the case in their language, showing how run-to-run variance was also polluting their own A/B reads. We fixed seeding and data snapshotting together; their offline experiment variance dropped too, which converted them from compliant to convinced. When launch pressure arrived and leadership wanted to skip the canary because offline numbers were strong, the researchers and I pushed back together - the 8% offline gain deserved to be believed only after surviving real traffic.
Result: The model shipped seven weeks after I joined the effort, canaried, reproducible, with a 6.5% online improvement in search conversion - close enough to offline predictions that leadership's trust in the research team's numbers went up. The paved path became the interesting part: the researchers shipped four more model iterations over the next two quarters at roughly two weeks each, versus the year the previous model had languished - because handoff had become a command, not a negotiation. One of the researchers told my manager it was the first time production engineering had made them faster. The manifest-plus-artifact contract spread to the recommendations team the following year.

Why this works

What makes this strong: (1) respect runs in the load-bearing direction - the candidate learned why the research workflow was shaped as it was before changing anything, and preserved the other side's iteration speed as a hard constraint rather than collateral damage; (2) the seam is bridged with a contract and a paved path, not gates - and the one standard worth enforcing (reproducibility) was sold in the researchers' own terms until they were convinced, not just compliant; (3) the outcome is measured on both sides' scoreboards: online conversion for the company, iteration cadence for the researchers, and a relationship where the next four models shipped in weeks.

WEAK

Weak: the cleanup hero

Prompt: "Tell me about taking something from prototype or research code to production. How did you work with its authors?"

Situation: Our data-science team had built a churn-prediction model that the business wanted in production, but the code was, frankly, a disaster - a giant notebook, no tests, hardcoded paths everywhere. Classic data-science code.
Task: I was the engineer who had to make it production-grade, which basically meant rewriting it properly.
Action: I took their notebook and rewrote the whole thing as a real service - proper structure, tests, CI, typed interfaces. It took about six weeks. I didn't involve the data scientists much during the rewrite; honestly it was faster to just do it right myself than to explain software engineering practices to them. When I was done I presented the new service and told them that going forward, model changes needed to come as pull requests against my codebase, with tests, and pass review before deploying. They pushed back that this made their experimentation slower, but production standards exist for a reason - you can't just YOLO notebook code into prod.
Result: The service has been stable in production, which proves the approach. The data scientists mostly stopped iterating on that model though - I think there's been one update since, and they've been building their newer models in a separate system they control. But the thing I own runs clean.

Why this is weak

Why weak: (1) contempt is the operating system of this story - 'classic data-science code,' 'explain software engineering to them' - with zero curiosity about why the notebook workflow existed, which is the exact anti-signal for a research-adjacent role; (2) the candidate built a gate, not a path: PR-and-review requirements imposed on the other side made experimentation slower, and the predictable result is right there in the ending - the researchers routed around the system and the model went stale, meaning the collaboration failed even though the service 'runs clean'; (3) success is measured entirely on the candidate's own scoreboard (stability of the thing they own) while the shared outcome - a model that keeps improving - quietly died. The interviewer will notice even though the candidate didn't.

Common pitfalls

×Contempt leakage - 'researchers write terrible code' framing, even softened. It signals you'll recreate the war at a company that is mostly seam.
×Building gates instead of paved paths: review requirements and process imposed on the other side, making them slower and inviting workarounds.
×Measuring success only on your own scoreboard (my service is stable) while the shared outcome (models keep shipping) degrades.
×Being the pushover instead: shipping unreproducible or unsafe work to avoid a hard conversation with a researcher. Respect includes disagreement.
×Rewriting the other side's work without them - the cleanup hero move destroys the relationship the next handoff depends on.
×Having learned nothing from the other side. If collaboration only ever flowed teaching one direction, it wasn't collaboration.

Follow-up strategies

Interviewers will probe. Be ready for the follow-up questions that test the depth of your story.

→If asked 'why was their code like that?', the strong answer explains their incentives sympathetically - it's a test of whether you understood the other side.
→If asked 'where did you refuse to bend?', name the one standard that was genuinely load-bearing (reproducibility, a safety gate) and show you sold it in their terms.
→If asked 'how did they feel about it?', have evidence - the other side's own words or behavior (faster iteration, voluntary adoption), not your assumption.
→If asked 'what did you learn from them?', have a real answer: eval-driven thinking, comfort with uncertainty, hypothesis discipline. It proves the respect was genuine.
→If asked about a seam conflict that didn't resolve cleanly, own your half of the failure - seam war stories where the other side was simply wrong are a red flag.

Related behavioral themes

Influence

General

The senior+ signal. Can you drive cross-team work, mentor, and build consensus when nobody reports to you - or do you only execute when given a mandate?

One Microsoft

Microsoft

Nadella's 'One Microsoft' replaced internal rivalry with cross-org collaboration. Interviewers test whether you build across team boundaries instead of optimizing your own silo.

Velocity in Ambiguity

OpenAI

OpenAI ships at frontier pace into problems nobody has solved before - requirements shift weekly and the spec doesn't exist. Interviewers test whether you produce velocity or need certainty.

Companies that test this theme

OpenAI

Software Engineer

Practice these stories live

Reading STAR answers is the floor. The interview signal is in delivering them out loud, with follow-ups, under pressure. The AI mock interview probes your stories the way real interviewers do.

Start an AI mock interview →

OpenAIAdvanced Premium

Research-Product Collaboration (OpenAI Culture)

About this theme

What interviewers are evaluating

→Have you actually worked a seam between functions with legitimately different incentives - research/ML/data science and production engineering?
→Do you respect why the other side works the way it does, or does contempt leak ('researchers write terrible code')?
→Can you translate both directions - capability claims into deployment criteria, and reliability needs into constraints researchers can design against?
→Did you build paved paths that made the other side faster, or gates that made them slower?
→When the two sides' goals genuinely conflicted (launch date vs. eval bar, iteration speed vs. reproducibility), how did you resolve it?
→Can you name something you learned from the other side's way of working?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Tell me about taking something from prototype or research code to production. How did you work with its authors?
?Describe collaborating closely with a team whose goals or working style conflicted with yours.
?Tell me about a time you had to push back on shipping something that wasn't production-ready, when its creators thought it was.
?How have you made a research or ML team faster rather than slower?
?Tell me about translating between technical audiences who talk past each other.
?Describe a conflict between iteration speed and engineering rigor. How did you land it?
?What have you learned from working with researchers or scientists that changed how you engineer?

Sample STAR answers

Both strong and weak examples, with notes on what makes each work (or fail). Read the weak examples carefully - the patterns they show up are the ones interviewers are trained to spot.

STRONG

Strong: productionizing the ranking model without breaking the researchers

Prompt: "Tell me about taking something from prototype or research code to production. How did you work with its authors?"

Situation: At a marketplace company, our two-person applied-research team had built a new search-ranking model that beat the production system by 8% on offline metrics. It lived as a research artifact: a notebook-driven training pipeline, handwritten feature extraction that only its authors fully understood, and no reproducibility guarantees - retraining from the same inputs produced slightly different models. I was the senior engineer assigned to get it into production, where it would serve every query on the site. The previous attempt at this handoff, a year earlier with a different engineer, had ended with the researchers feeling policed, the engineer feeling stonewalled, and the model unshipped.
Task: Ship the model to production reliability standards without turning the researchers into ticket-takers for my requirements - and without becoming the reason the next model takes a year to land. The relationship was the deliverable as much as the deployment.
Action: I started by paying the respect cost the previous attempt had skipped: I spent my first week working the way THEY worked - rerunning their notebooks, reading their experiment logs, asking why the pipeline was shaped the way it was. That week changed my plan, because most of what looked like sloppiness was rational under their incentives: the notebook pipeline existed because they retrained with new feature ideas several times a week, and any structure I imposed that slowed that loop would be routed around, deservedly. So instead of demanding they meet production standards, I drew a contract line: everything upstream of a trained model artifact remained theirs, structured however they liked; everything downstream - validation, canary, serving, rollback - was mine. The interface was the artifact plus a manifest (data snapshot, config, eval scores). Then I built the paved path that made the contract cheap: a one-command tool that took their artifact, ran the reproducibility check and eval suite, packaged it for serving, and generated the manifest. Reproducibility was the one fight worth having - unreproducible models are undebuggable incidents waiting to happen - and I made the case in their language, showing how run-to-run variance was also polluting their own A/B reads. We fixed seeding and data snapshotting together; their offline experiment variance dropped too, which converted them from compliant to convinced. When launch pressure arrived and leadership wanted to skip the canary because offline numbers were strong, the researchers and I pushed back together - the 8% offline gain deserved to be believed only after surviving real traffic.
Result: The model shipped seven weeks after I joined the effort, canaried, reproducible, with a 6.5% online improvement in search conversion - close enough to offline predictions that leadership's trust in the research team's numbers went up. The paved path became the interesting part: the researchers shipped four more model iterations over the next two quarters at roughly two weeks each, versus the year the previous model had languished - because handoff had become a command, not a negotiation. One of the researchers told my manager it was the first time production engineering had made them faster. The manifest-plus-artifact contract spread to the recommendations team the following year.

Why this works

WEAK

Weak: the cleanup hero

Prompt: "Tell me about taking something from prototype or research code to production. How did you work with its authors?"

Situation: Our data-science team had built a churn-prediction model that the business wanted in production, but the code was, frankly, a disaster - a giant notebook, no tests, hardcoded paths everywhere. Classic data-science code.
Task: I was the engineer who had to make it production-grade, which basically meant rewriting it properly.
Action: I took their notebook and rewrote the whole thing as a real service - proper structure, tests, CI, typed interfaces. It took about six weeks. I didn't involve the data scientists much during the rewrite; honestly it was faster to just do it right myself than to explain software engineering practices to them. When I was done I presented the new service and told them that going forward, model changes needed to come as pull requests against my codebase, with tests, and pass review before deploying. They pushed back that this made their experimentation slower, but production standards exist for a reason - you can't just YOLO notebook code into prod.
Result: The service has been stable in production, which proves the approach. The data scientists mostly stopped iterating on that model though - I think there's been one update since, and they've been building their newer models in a separate system they control. But the thing I own runs clean.

Why this is weak

Common pitfalls

×Contempt leakage - 'researchers write terrible code' framing, even softened. It signals you'll recreate the war at a company that is mostly seam.
×Building gates instead of paved paths: review requirements and process imposed on the other side, making them slower and inviting workarounds.
×Measuring success only on your own scoreboard (my service is stable) while the shared outcome (models keep shipping) degrades.
×Being the pushover instead: shipping unreproducible or unsafe work to avoid a hard conversation with a researcher. Respect includes disagreement.
×Rewriting the other side's work without them - the cleanup hero move destroys the relationship the next handoff depends on.
×Having learned nothing from the other side. If collaboration only ever flowed teaching one direction, it wasn't collaboration.

Follow-up strategies

Interviewers will probe. Be ready for the follow-up questions that test the depth of your story.

→If asked 'why was their code like that?', the strong answer explains their incentives sympathetically - it's a test of whether you understood the other side.
→If asked 'where did you refuse to bend?', name the one standard that was genuinely load-bearing (reproducibility, a safety gate) and show you sold it in their terms.
→If asked 'how did they feel about it?', have evidence - the other side's own words or behavior (faster iteration, voluntary adoption), not your assumption.
→If asked 'what did you learn from them?', have a real answer: eval-driven thinking, comfort with uncertainty, hypothesis discipline. It proves the respect was genuine.
→If asked about a seam conflict that didn't resolve cleanly, own your half of the failure - seam war stories where the other side was simply wrong are a red flag.

Related behavioral themes

Influence

General

The senior+ signal. Can you drive cross-team work, mentor, and build consensus when nobody reports to you - or do you only execute when given a mandate?

One Microsoft

Microsoft

Nadella's 'One Microsoft' replaced internal rivalry with cross-org collaboration. Interviewers test whether you build across team boundaries instead of optimizing your own silo.

Velocity in Ambiguity

OpenAI

OpenAI ships at frontier pace into problems nobody has solved before - requirements shift weekly and the spec doesn't exist. Interviewers test whether you produce velocity or need certainty.

Companies that test this theme

OpenAI

Software Engineer

Practice these stories live

Reading STAR answers is the floor. The interview signal is in delivering them out loud, with follow-ups, under pressure. The AI mock interview probes your stories the way real interviewers do.

Start an AI mock interview →