**Inspiration When it came to solving interview and LeetCode problems, all of us struggled to digest the problem, figure out how to approach it, and follow through to a complete solution. We brainstormed several ideas for programs that could help make this process easier. We realized that the problem was not always a lack of information. Often, the problem was how that information was presented. A solution can be correct, but if a learner does not understand why it works, they are still going to struggle with the next problem. This inspired us to create ThinkPad, a tool that coaches users through programming problems instead of immediately giving them the answer. **What it does ThinkPad provides several methods of coaching users through different programming and data structure problems. Rather than relying on one type of explanation, ThinkPad can adapt the way it teaches based on what the learner needs. Some of the methods include: Visual examples of data structures and algorithms Links to YouTube videos for additional explanations Turning abstract programming concepts into real-world examples Asking questions that encourage the learner to think through the problem Providing hints without immediately revealing the solution Using diagrams based on the user's actual problem inputs The goal is to help users understand how to think through a problem, rather than simply giving them the answer. **How we built it Sidenote is a Chrome extension (Manifest V3) that opens in the browser side panel next to LeetCode, backed by a Gemini function on Vercel. We split the work by interface boundary rather than by feature, so four people never edited the same file. One folder each — Chrome plumbing, panel UI, coaching brain, visuals — and a single frozen contracts.ts holding every type that crosses between them. Fixtures landed in the first hour, so the UI and visuals could be built with the backend deleted. The coaching loop is two Gemini calls per turn with our own code in between. First Gemini diagnoses which of seven misconceptions the learner has. Then our code decides how hard to push — hint level, and whether to answer with a question, an analogy, a diagram, or a video — and passes that to the second call as a constraint. The model writes the words; it never decides the pedagogy. The escalation rules are pure functions with unit tests, not prompt instructions. Same for the diagram: we simulate the algorithm on the learner's own nums and target scraped from the page, so the visual shows their numbers, not canned ones. **Challenges we ran into One of our biggest challenges was dealing with the gap between what we expected to work and what actually worked during development. We had to test different models, deployment configurations, and ways of interacting with the live LeetCode page before finding reliable solutions. For example, our first model choice was far too slow for an interactive coaching experience. We also spent multiple deployment cycles debugging an endpoint that appeared to be a runtime or bundling issue, when the actual problem was how the Vercel function was handling the request and response. We also discovered that we could not simply assume that information on the LeetCode page would be structured the way we expected. Some of our initial selectors did not work against the live page, and Monaco's editor, the code editor used by LeetCode to display and edit programming solutions, dynamically changes its DOM (the structure of elements on the webpage) as users type. This made reading code directly from the page more difficult than expected. Another major challenge was making sure the AI followed the educational rules we wanted. We found that important behaviors could not be reliably enforced through prompts alone. This led us to move critical decisions into our own code, where we could test and enforce them consistently.
**Accomplishments that we're proud of We are proud that we built a coaching system that focuses on teaching instead of simply providing solutions. ThinkPad can identify misconceptions, determine how much assistance a learner should receive, and provide different types of guidance without immediately giving away the answer. We are especially proud of making the coaching behavior deterministic where it matters. The system tracks the types of help a learner has already received, preventing it from repeatedly giving the same type of response. When the system reaches the end of its available coaching methods, it does not endlessly repeat itself. We also tested our coaching system using ten manually written incorrect explanations. The system correctly diagnosed all ten, while ensuring that the first hints ended with questions and did not leak the solution. This evaluation also helped us identify bugs before they reached our final demo. Finally, we are proud that the visualizations use the learner's actual problem inputs rather than canned examples. If the input changes, the visualization changes with it. **What we learned One of the biggest things we learned was how important it is to adapt as a team. We ran into technical issues where one of our devices couldn't properly run the terminal, which forced us to change our original approach and reallocate responsibilities during the build. Technically, we learned that anything important to the product cannot depend entirely on a prompt. Rules such as not repeating explanations, not immediately giving the answer, and not incorrectly approving a brute-force approach were not reliable when they were left entirely to the AI. Moving those rules into code and testing them made the behavior much more consistent. We also learned the importance of testing the actual artifact we were going to deploy. Several of our deployment problems could have been discovered much earlier by testing the built application locally before deploying it. This changed the way we approached debugging for the rest of the project. **What's next for ThinkPad We see opportunities to scale ThinkPad both technically and financially. On the technical side, we could build a server capable of caching commonly encountered user errors, questions, and explanations. If multiple users encounter the same problem, ThinkPad could reuse existing data instead of making a new AI call every time. This could reduce unnecessary computing and AI costs while also making responses faster as the number of users grows. The collected data could also help us better understand which concepts learners struggle with most and improve the coaching system around those areas. Financially, we could introduce a premium version of ThinkPad that provides access to stronger AI-assisted responses, additional coaching methods, and more advanced learning features. The free version could remain accessible to students while the premium version helps support the infrastructure and AI costs required to scale the platform. Ultimately, we want ThinkPad to become a learning platform that helps people approach programming problems with less frustration and teaches them how to think through problems independently.
Log in or sign up for Devpost to join the conversation.