A Double Diamond case study on designing Foundry, a hands-on coding platform built around one gap: computer science graduates can ace an exam and still freeze in front of a real, messy codebase — because nothing in a four-year degree ever put one in front of them.
Try the flow yourself ↓40 graduating CS seniors, self-reported confidence vs. an unmoderated debugging task with no clear error message
The gap wasn't intelligence — it was exposure. None of the failing students had ever debugged code they hadn't written themselves.
Foundry is a web platform that drops computer science students into real, intentionally messy codebases with real tickets — ambiguous requirements, legacy code, failing tests with no clear message — instead of clean, isolated practice problems. Students file a "PR," get review feedback modeled on real senior-engineer critique, and build a visible skill record employers can actually trust.
It's not that computer science curricula skip practical skills entirely — most include a capstone project or two. It's that the other 90% of a degree is lecture-and-exam based, and the practice problems that do exist are almost always clean, isolated, and already correctly scaffolded. Real engineering work is none of those things: the code is someone else's, the bug report is vague, and the tests were written by a person who has since left the company.
Give students hundreds of small, low-stakes reps at the actual skill hiring managers say new grads lack — reading unfamiliar code, debugging without a clear error, and responding to real review feedback — before their first day on the job, not during it.
Two different open questions sat on top of each other here: first, why strong students still arrive underprepared when practice tools already exist (a discovery problem), and only once that was answered, what a genuinely realistic practice environment would need to include without becoming overwhelming (a design problem). Double Diamond's two diverge‑then‑converge cycles kept those separate, instead of jumping straight from "students need practice" to "here's another algorithm-drill app."
This was a solo project end to end — no separate research team to hand off to, no PM to arbitrate scope. Every trade-off documented below (what got cut, what got kept, what got argued with a hiring manager) is one I made myself, moving between roles as the work needed:
That's a scope statement, not a boast — a real team changes this. The codebase-sanitization pipeline and grading-rubric calibration below are exactly the kind of calls I'd bring in a senior engineer and a curriculum designer for, rather than resolve alone; I've flagged those seams throughout instead of pretending they aren't there.
of hiring managers surveyed said new-grad hires couldn't debug unfamiliar code without heavy guidance
of graduating seniors could fix a real, unfamiliar bug unaided in a timed technical task
average time a new hire takes to become independently productive, per surveyed engineering managers
Fig. 1 — The double diamond, mapped to this project
Question why capable, well-taught students still arrive unprepared, without assuming the fix yet.
Narrow to one insight and one problem statement worth solving.
Sketch multiple, genuinely different ways to simulate real engineering conditions.
Build, test, and refine the direction the evidence actually supported.
Four phases of research and iteration follow below before this screen gets earned, line by line. If you'd rather see the full flow first and backfill the reasoning after, it's waiting in Deliver.
Jump to the full walkthrough ↓Before designing anything, the goal was to understand why this problem persists despite plenty of existing "learn to code" tools, without assuming the fix yet.
Practice tools already exist in abundance. The question was why none of them close the gap hiring managers actually describe. Six tools (and one real-but-scarce alternative) were audited.
| Product | What it does | Where it falls short |
|---|---|---|
| LeetCode / HackerRank | Algorithm-puzzle practice, widely used for interview prep. | Isolated, pre-scaffolded problems with one correct function signature — nothing like reading someone else's codebase. |
| Codecademy / freeCodeCamp | Guided, structured lessons for learning to code from scratch. | Great for syntax and fundamentals, but every exercise is clean, small, and already set up to succeed. |
| University capstone project | One larger, more open-ended project near the end of a degree. | Usually one shot, late in the timeline, and built from scratch — never inherited, legacy, or someone else's mess. |
| Internships | The real thing: real codebases, real tickets, real review. | Scarce, competitive, and often the first exposure a student gets — which is exactly the problem. |
| Open-source contribution | Real codebases, real maintainers, real review culture. | Genuinely valuable, but unstructured and intimidating for a beginner with no on-ramp. |
| Coding bootcamps | Project-based weeks mixed into an intensive curriculum. | Still mostly greenfield, guided projects — rarely inherited or intentionally messy codebases. |
Every practice tool audited optimizes for a student succeeding quickly and cleanly. None of them simulate the actual conditions of professional engineering work — unfamiliar code, ambiguous tickets, and real critique — which is precisely the skill hiring managers say is missing.
180-student survey, graduating CS & bootcamp seniors.
32 engineering managers surveyed.
A 180-student survey and 16 moderated interviews (12 graduating seniors, 4 engineering managers) ran in parallel with the secondary research.
"I had a 3.9 GPA and I couldn't find a bug in my own team's code for two days. Nobody ever taught me how to even start."
"We stopped asking for GPA years ago. I need to know if someone can survive their first sprint, and I can't tell that from a transcript."
"LeetCode got me the interview. It did not prepare me for a 40,000-line Rails app with no comments."
Discovery surfaced a lot — confidence gaps, review anxiety, scarce internships. Define was about resisting the urge to solve all of it at once.
Students weren't lacking knowledge — they were lacking reps at applying it under realistic conditions. Every practice tool they'd used optimized away the exact discomfort (unfamiliar code, ambiguity, critique) that professional engineering actually runs on. The fix wasn't more content. It was safe, repeated exposure to mess.
So the first time a student meets undocumented, inherited code isn't also their first day of paid work.
Pass/fail tells a student whether the code works. It doesn't teach them how a reviewer would actually respond to it.
So Marcus can see evidence of debugging and review behavior, not just another certificate.
Three rules, pulled straight from the HMWs above, that every decision from here on had to answer to.
Codebases are real and imperfect, but every ticket has a findable resolution — frustration with a floor, not a bottomless pit.
Every review comment explains the "why," the way a good senior engineer would, not just pass or fail.
A skill record has to be scannable by a hiring manager in under a minute, or it won't get used as a signal.
Students who complete a track can debug unfamiliar code noticeably better than before starting.
Students revise based on review comments, not just resubmit until tests pass.
The skill record changes how a hiring manager would evaluate a candidate, not just how they feel about the résumé.
The insight was narrow. The solution space still wasn't — three structurally different ways to act on it were sketched and concept-tested with 6 CS seniors before committing engineering time to any of them.
Extend the LeetCode model with more advanced, closer-to-real-world coding challenges.
Match students with real company codebases for a semester-long capstone-style engagement.
Real, sanitized codebases with a queue of realistic tickets and review-style feedback on every submission.
A concept project skips real employer partnerships and licensing — it doesn't skip the constraints they'd create. These shaped decisions throughout, not just at the end.
Company code carries IP and security concerns Foundry can't absorb. The design assumes a sanitization pipeline — stripped secrets, scrubbed proprietary logic, licensed or donated legacy codebases — run by engineers, not something a solo designer resolves alone.
Realism that turns into hopeless frustration teaches nothing. Every ticket is calibrated to have a findable resolution within the codebase provided, even when the path there isn't obvious.
Freemium for students — the ticket queue and skill record are always free to build. Revenue comes from a B2B tier: companies and bootcamps sponsoring tracks, or paying to source directly from verified skill records. That distinction shaped the design, not just the business plan: a student's practice history can never be paywalled after the fact.
Before the screens, the reasoning behind them — the calls that shaped everything downstream, and what each one cost.
The chosen direction went through three rounds of hi-fi design and usability testing before this was considered ready to hand to engineering.
01 — Tickets carry real signals: bug vs. feature, and how messy the surrounding code is.
02 — A real file tree, a failing test, and no comment explaining why the old code did what it did.
03 — Ambiguous by design — asking a clarifying question is part of the ticket, not a shortcut around it.
04 — Feedback explains the reasoning, the way a real senior engineer's review would.
05 — A skill record built from behavior across real tickets, not a single test score.
06 — Edge case: when a ticket has no clean answer, a scoped hint keeps frustration from becoming the point.
The embedded editor supports standard IDE keybindings (not a custom scheme), and every action reachable by mouse is reachable by keyboard, since debugging is naturally a keyboard-heavy task.
The workspace runs against a remote sandbox, not a local install, so it was tested and tuned on a throttled connection to stay usable on campus wifi, not just fast home broadband.
A simplified click-through of the same flow. Pick a ticket, see the reasoning, get review feedback.
↑ Click through it
Every ticket shows how messy and how clear the surrounding code and requirements are.
Clarify the ambiguous parts before writing code — same as a real ticket thread.
Feedback explains the reasoning, not just pass or fail, and updates the skill record.
9 participants (6 graduating CS seniors, 3 recent bootcamp grads), testing three tasks: triaging a ticket queue, debugging an unfamiliar failing test, and responding to review feedback.
5 of 9 participants opened the failing test first, then bounced between files with no clear strategy.
Added a "start here" pointer on each ticket, pointing to the one file most relevant to the reported symptom — a hint, not the answer.Testers hesitated to ask questions, assuming it signaled they couldn't figure it out alone.
Reframed the prompt explicitly: "Real engineers ask this. Asking is part of the ticket, not a shortcut around it."Participants trusted multi-comment reviews far more than single-verdict ones, even when the verdict was positive.
Every review now includes at least one comment on something done well, not only what needs to change.Code editor contrast, checked against WCAG AA
Every syntax-highlight color was checked against the dark editor background, not just the page's own light/dark theme.
Color
Brand deep
#2B3550
Brand
#4C5C7A
Accent
#C4602E
Bug tag
#0C9A4C
Messy tag
#B9791E
Blocking
#C43A3A
Ticket tags
Elevation
Type scale
| Style | Family / weight | Size / line |
|---|---|---|
| Display | Newsreader, italic 500 | 32–72px / 1.0 |
| H2 / H3 | Newsreader, 560 | 20–40px / 1.2 |
| Body | Inter, 400 | 14–18px / 1.65 |
| Label | IBM Plex Mono, 600–700 | 10–12px / 1.3 |
| Code | IBM Plex Mono, 400–500 | 8.5–11px / 1.7 |
expected 42, got 44 (line 3)
Icons
Validated through iterative usability testing ahead of a planned engineering handoff.
Realism mattered less as difficulty and more as trust. Students didn't disengage because the code was hard — they disengaged when a "messy" scenario felt fabricated. The moment testers recognized the mess as genuinely real (an actual old comment, an actual abandoned TODO), their patience for struggling through it went up, not down.
Next steps include piloting the sanitization pipeline with a real engineering team to validate it holds up outside a solo-designer mockup, testing whether hiring managers actually change shortlisting decisions when shown a skill record versus a resume, and extending tracks beyond backend Ruby/Rails into frontend and data engineering codebases.