Inspiration

Everyone tells beginners to “talk to people in the field,” but very few explain who to contact, why that person is relevant, or what to ask. Existing mentor platforms often leave students searching through long lists of profiles and guessing which connection might actually help them. This problem is especially difficult for students and career switchers who do not already have a professional network. We wanted to make career guidance more accessible by answering two important questions: Who should I talk to, and how can I make a short conversation count? That question inspired us to create MentorMatch—a platform that connects beginners with relevant, opt-in mentors and gives them a personalized plan for having a meaningful conversation.

What it does

Intake (about a minute): field, career stage (exploring, targeting a role, applying, interviewing), optional target role and company, the help they want, one-on-one or group, and one conversation or a recurring plan.
Top three mentors from a pool of people who opted in to help beginners. Every match comes with a plain-language reason and chips showing exactly which factors matched.
A personalized playbook: a goal for the conversation based on the student's stage, tailored questions drawn from that mentor's experience, what to avoid (like asking for a referral in a first chat), and a follow-up message the student edits and sends themselves. Recurring plans get a session-by-session plan, and group meetings get etiquette tips.
A mentor portal where mentors choose what they offer, set monthly session limits, handle requests, and pause or remove their profile at any time.

How we built it

We built MentorMatch as a working hackathon prototype with a user-facing website, a synthetic pool of 50 fictional mentors, a transparent matching system, fairness testing, and personalized conversation preparation. We organized the project code in GitHub, which helped our team manage files, track changes, collaborate, and maintain a clear version of the application as we developed new features. The website includes:

A landing page explaining the problem and solution
A six-question student intake form
Mentor recommendations limited to the top three matches
Plain-language explanations for each recommendation
A fairness page showing what information is and is not used
Mentor consent, availability, and monthly capacity rules
A personalized conversation playbook with goals, questions, advice, and a follow-up draft

At a high level, the application follows this process:

The student enters their field, career stage, target role, target company, background, and desired type of help.
The system filters mentors based on consent, availability, career-stage support, meeting type, and monthly capacity.
The matching logic scores mentors using job-relevant factors such as field, role, company, help fit, and career-path overlap.
The system returns the student’s top three mentors and explains why each person matched. The AI prepares a conversation playbook, while the student remains in control of the final message and decision.

We used IBM Bob throughout the development process. IBM Bob helped us create the executive summary, plan the system architecture, develop an architecture overview and diagram, identify findings and weaknesses, and create detailed recommendations with code examples. We also used it to compare alternative architecture approaches, create a prioritized action plan, and evaluate the overall strength of our solution.

One important design decision was separating the core matching logic from the AI features. The ranking and filtering run through consistent, testable code, while AI is used to write explanations and generate conversation playbooks. This allows MentorMatch to benefit from AI without making the recommendations dependent on an unexplained black-box decision.

We also added a fairness check that ranks the same sample student profile multiple times using different fictional names. Because names are not used in the matching process, the recommendations should remain the same. This allowed us to test one of our main responsible AI goals directly inside the product.

The result is a prototype that does more than display mentor profiles. It helps students understand who to contact, why the mentor is relevant, and how to prepare for a meaningful conversation.

Challenges we ran into

Deciding where AI belongs. We kept all ranking in plain code so we could test it and explain it, and used AI only for wording and preparation.
Making fairness testable, not just claimed. Matching never sees name, gender, ethnicity, age, or photos. We test it by running identical student profiles with different names and checking the results match.
Capacity with group and recurring meetings. Counting students didn't work, so we counted sessions: a group session is one session no matter how many attend, and a recurring plan reserves sessions each month.
Being honest about prototype limits. Bob's architecture review found a write-concurrency race in our file store, unauthenticated demo routes for mentor actions, no rate limiting on the AI routes, and a monthly counter that never resets. We list these as known limits and fixed next steps.

Accomplishments that we're proud of

We are proud that we built a working end-to-end prototype that turns a student’s career goals into relevant mentor recommendations and a personalized conversation plan. Our key accomplishments include:

Creating a functional website with a student intake process and mentor recommendation workflow
Building a synthetic pool of 50 fictional, opt-in mentor profiles
Developing transparent matching logic that explains why each mentor was recommended
Filtering mentors based on consent, availability, career stage, help type, and monthly capacity
Creating personalized conversation playbooks with goals, questions, advice, and follow-up drafts
Adding a fairness-check feature to test whether different names produce the same recommendations
Designing the system so AI explains and prepares, but does not rank, contact, or message anyone automatically
Documenting the architecture, weaknesses, recommendations, and action plan with IBM Bob
Using GitHub to organize our code, collaborate, and track project development

Most importantly, we are proud that MentorMatch addresses a real barrier for students without professional networks: not only finding someone to contact, but knowing why that person is relevant and how to make the conversation meaningful

What we learned

Explanations are easier to trust when they come from the same data as the scoring, so the chips and the sentence can't disagree.
Making AI optional at every call site made the product more reliable, not less.
An outside architecture review is worth doing even on a hackathon project, because it shows us where "works in the demo" is hiding real risks

What's next for MentorMatch

We'd like to partner with opt-in mentor programs like SJSU or ADPList and add MentorMatch as a matching and preparation layer on top of their real mentor networks, with real authentication and a proper database. Then we want to measure whether prepared students have more useful conversations and stronger follow-ups.