Problem Discovery

Producing a working codebase does not necessarily mean understanding how it works. Developers may struggle to explain the files, functions, architectural decisions, and trade-offs within repositories they have built or contributed to.

This creates a gap between producing code and demonstrating ownership of that code, particularly when developers need to explain their work in interviews, code reviews, or technical discussions.

SlopTeacher addresses this gap by assessing a developer's understanding of a public GitHub repository and providing a repository-grounded diagnostic.

• Code production and code ownership are different. Producing a codebase does not automatically mean a developer can explain or modify every important part of it.
• Technical confidence needs evidence. Developers need ways to demonstrate their understanding through concrete explanations of files, functions, dependencies, and trade-offs.
• Interview preparation lacks personal context. Generic coding questions may not adequately prepare developers to explain the implementation details and decisions within their own repositories.
• Knowledge gaps are difficult to identify independently. Developers may not know which parts of their code they understand well, where their understanding is incomplete, or which questions could expose those gaps.

SlopTeacher's product premise is that developers should be able to pressure-test their understanding of a real repository and receive feedback grounded in its actual code.

Hypotheses to validate. No formal validation documented yet.

These assumptions inform SlopTeacher's initial product direction. They represent beliefs about potential users, not established research findings.

A1. Developers may overestimate their understanding of their repositories.

Developers may have difficulty explaining implementation details, dependencies, or architectural decisions when questioned about code they have built or contributed to.

Underlying belief: There may be a gap between perceived and demonstrated understanding.

A2. Developers do not know which questions could expose gaps in their understanding.

Developers preparing for technical interviews may struggle to anticipate questions about their own repositories, including implementation choices, function behaviour, edge cases, and trade-offs.

Underlying belief: Repository-specific assessments may provide more relevant preparation than generic interview questions alone.

A3. Developers need objective evidence of their repository understanding.

Self-assessment may not be sufficient for developers who want to establish whether they can explain and reason about their own code.

Underlying belief: Questions grounded in actual files, functions, and implementation details can provide a more credible assessment than self-reported confidence alone.

A4. Understanding a codebase requires more than knowing what its code does.

Developers may be able to describe a function's purpose without understanding its dependencies, limitations, failure cases, or design trade-offs.

Underlying belief: A meaningful assessment should evaluate reasoning and comprehension, not just the ability to repeat code descriptions.

A5. Actionable feedback is more valuable than a simple pass or fail.

Developers may benefit more from identifying specific knowledge gaps and understanding why their answers are insufficient than from receiving a single overall score.

Underlying belief: Feedback tied to repository evidence can help users identify what they understand, what they need to revisit, and where they should improve.

Validation Plan

These assumptions should be investigated through developer interviews, competitor analysis, and prototype testing.

The objective is to establish whether these problems exist, which user segments experience them most acutely, and whether repository-specific assessments provide meaningful value.