Design a centralized research repository for discoverable, actionable insights

WHAT THIS TESTS: This question evaluates your ability to design an internal knowledge system that makes unstructured qualitative data discoverable and actionable at scale. The interviewer cares about taxonomy design, separation of concerns between raw artifacts and synthesized insights, search architecture, and integration with engineering workflows. They want to see that you understand a repository is not just storage but a living system that prevents duplicated research and connects evidence to product decisions.

A GOOD ANSWER COVERS: First, an ingestion layer that normalizes diverse inputs. NN Group survey data shows most teams store five core asset types: reports, insights, notes, transcripts, and recordings. The pipeline should also accept third-party data like support tickets. Second, a clear data model that distinguishes between studies, reports, and atomic insights. Insights should be first-class entities with their own metadata rather than buried inside PDFs. Third, a metadata schema that includes dimensions like product area, methodology, participant segment, date, confidence level, and custom tags. Fourth, a storage architecture using object storage for media, a document database for insights and reports, and a search index such as Elasticsearch or OpenSearch to power faceted and full-text discovery. Fifth, an actionability layer exposing APIs, webhooks, or embeddable widgets that push relevant insights into tools engineers already use like Jira, Linear, Slack, or documentation portals.

COMMON WRONG ANSWERS: Treating the repository as a shared drive or Confluence wiki with folders and pages but no structured metadata or search index. Conflating reports with insights so findings remain locked in long documents rather than addressable units. Proposing heavy ML or LLM features before basic search, tagging, and linking are solved. Ignoring data privacy and access control for participant recordings and PII. Building without workflow integrations so engineers must manually visit another tool to act on research.

LIKELY FOLLOW-UPS: How would you handle versioning when insights evolve across multiple studies? How do you prevent tag sprawl and maintain taxonomy consistency across teams? What privacy controls are needed for raw session recordings versus synthesized insights? How would you measure whether engineers are actually discovering and acting on research? How do you scale this from ten to ten thousand studies without degrading search relevance?

ONE CONCRETE EXAMPLE: Imagine an engineer is building a checkout flow. They search the repository for checkout and see a faceted result set: three usability studies, five atomic insights, and two support-ticket themes. One insight from six months ago is tagged checkout, high-confidence, mobile, and blocker. The engineer clicks through to a thirty-second video clip, reads the recommendation, and sees a linked Jira ticket already filed by the research team. This only works because the system stores insights as addressable records with rich metadata and bi-directional links to execution tools.

Source: nngroup.com