📋 Treehouse Techdegree

The Treehouse Techdegree was a self-paced online bootcamp for people learning full-stack JavaScript. Around 1,000 students were enrolled at any given time — students came and went, but that was the consistent scale — each working through coursework and completing graded portfolio projects to earn their degree. My role covered curriculum design, program operations, and mentor development.

Portfolio Project and Rubric Design

The portfolio projects were the core assessment mechanism — the work students submitted to prove they'd learned the material and to build a real portfolio. I wrote the project briefs and the grading rubrics that governed how each submission was evaluated.

The rubrics used a three-tier structure: Needs Work, Meets Expectations, and Exceeds Expectations. Each tier had specific, testable criteria — not general impressions, but concrete things to check. For example, a mobile-first design rubric specified exactly how to verify breakpoint behavior in Chrome DevTools, which screen sizes to test, and what counted as passing versus falling short.

That specificity mattered for consistency. A rotating team of contractors was grading dozens of submissions against these rubrics, often without much context. Ambiguous criteria produce inconsistent grades; clear criteria produce fair ones.

Mentor Training

The mentors were contractors responsible for grading student projects, hosting one-on-one sessions via Zoom, and writing the feedback students would use to revise and resubmit their work. Keeping that quality consistent across a changing, rotating roster was one of the harder operational problems.

I wrote a full onboarding guide covering the program's philosophy, tool setup (Calendly, Zoom, Treehouse Admin), and a structured session format I designed: 15 minutes of preparation, 30 minutes with the student, 15 minutes of post-session notes. Each section had specific protocols — mentors were expected to review the student's previous session notes and project history in Admin before joining the call, and to document each session in a four-part format (student background, problem, solution, resources shared).

The pedagogical approach I embedded in the training was deliberate: guide, don't tell. Mentors were trained to use Socratic questioning to help students define their own problems rather than handing them answers. The guide included specific prompts for getting students unstuck, and emphasized pair programming with the student driving.

For written code reviews, I trained mentors on a three-part feedback structure: explain the problem, say why it matters, give a specific step to fix it. A comment like "your anchor links aren't working" doesn't help a student fix anything. A comment that shows the broken code, explains how anchor links actually work, and gives a corrected example does.

I also created tone guidance — specific phrases to use and avoid — because the difference between "you did okay" and "you're almost there" is significant to someone who is struggling and thinking about quitting.

Beyond the written guide, I built a training website to house all of this material and make onboarding self-serve. I also produced a video course for new mentors that walked through the full review process, grading philosophy, and common student errors before anyone touched a real submission.

Feedback Loops and Continuous Improvement

I gathered student feedback through surveys and the program's Slack community, tracking where students got stuck, where grades felt unfair, and where project briefs were unclear. That feedback fed directly into rubric revisions and project updates.

Re-submissions were also a signal. When a student submitted the same failing rubric multiple times without improvement, that was usually a sign that the original feedback hadn't communicated the problem clearly enough, or that the rubric criteria themselves were ambiguous. I used patterns like that to improve both the grading guides and the mentor training materials.

The aim was a 48-hour turnaround on project reviews — fast enough that students could stay in their learning momentum, consistent enough that they could trust the process.

Direct Student Support

Beyond program operations, I stayed involved at the student level. I did code review myself, held mentoring sessions over Zoom, and provided support and encouragement in Slack. That direct contact kept me close to the actual student experience — which is where most of the useful feedback about the program lived.