Code-to-Career: Grounding AI Learning Roadmaps in Real Job Postings, Then Deploying on NitroCloud

Code-to-Career is a student learning platform that searches live LinkedIn job postings before generating a roadmap, then gives its AI mentor a resource-backed view of each student's actual progress. The whole stack ships on NitroCloud.

What this enables

• Searches live LinkedIn postings for a skill before generating its roadmap
• Serves each student's roadmap and completed steps as an MCP resource
• Auto-detects interview skills from the student's own saved roadmaps
• Keeps the mentor's context lookup separate from the main Next.js API
• Runs on NitroCloud instead of a hand-built deployment pipeline

A learning platform built around one complaint

Code-to-Career, built by developer Vishal Deep under the team name The Coders Revolution for a hackathon submission, tackles a familiar student problem: months of tutorials that don't match what employers are actually hiring for. The app bundles a roadmap generator, a chat-based AI mentor, a mock-interview engine, an in-browser code reviewer, a job board, a tech-news feed, and a peer community into one Next.js app backed by MongoDB and Google Gemini. The two most interesting design decisions sit under the roadmap generator and the AI mentor, where the team chose to ground the AI in outside data instead of letting it improvise.

Why "ask the model" isn't enough

Ask an LLM what someone should learn to get good at Python, and it answers fluently but generically: a model's training data doesn't track which frameworks a given employer is screening for this month. Job requirements drift with the market; the model's latent knowledge doesn't.

The mentor has a related problem. Once a student has a saved roadmap (steps completed, topics flagged as weak), a chat window that starts every session from zero context can only give generic advice. It doesn't know the student already finished the Django steps and is stuck on async views. Piping that state into the mentor without hard-coding a database query into every AI route, and without one student's context leaking into another's session, is an access-control problem as much as a UX one.

Why MCP fits here

MCP gives the team a clean answer to both problems without building a bespoke API for each. For the roadmap, job-market lookup becomes a discrete agent step that runs before generation, rather than something folded into the prompt. For the mentor, a resource fits better than a tool: the mentor doesn't need to call an action with parameters, it needs to read a student's current state before answering. Exposing that state at resource://mentor/user_context/{userId} keeps the read path declarative and separate from the mentor's own chat API. In principle, any MCP-aware client could read the same context without going through the Next.js app at all.

Two agents, one saved state

The roadmap path runs as a two-step agent rather than a single prompt call:

1. A student submits a skill, experience level, and learning preference.
2. The backend searches the LinkedIn Jobs API for that skill and pulls back current listings.
3. Those listings are passed into the Gemini prompt as grounding context alongside the student's preferences.
4. Gemini returns a structured roadmap, ordered steps and resources, saved to a Roadmap collection in MongoDB.
5. As steps are completed, a PATCH /api/roadmaps call flips a completedSteps flag, and later scans of that same collection infer which topics the student is weak on.

The mentor reuses that saved state. Before /api/mentor sends a message to Gemini, it reads the student's roadmaps from MongoDB and prepends a context block (target roles, full step list, inferred weak areas) to the prompt. If that lookup fails, the code falls back to a plain prompt rather than blocking the chat, a small reliability choice for a build that has to survive live judging.

Separately, the repository includes a standalone MCP server, mcp-servers/mentor-context, an Express process on port 3001 that exposes the same student context as a resource, resource://mentor/user_context/{userId}, scoped strictly to the authenticated user's ID. The README marks it optional: production chat reads MongoDB directly and doesn't need it running. Its purpose is letting an external MCP client reach the same context through a standard resource URI instead of the app's internal database queries.

Authentication runs through NextAuth with Google, GitHub, and email/password providers. The interview engine pulls its skill list from the student's own saved roadmaps, falling back to a static list of popular skills when none exist yet.

Where NitroStack fits

NitroStack's role here is narrower than in the platform's core learning features, and that's a reasonable division of effort. The production app is live at a NitroCloud-issued domain (code-to-carrer-*.app.nitrocloud.ai), meaning the team shipped a multi-service build (a Next.js frontend, API routes, a separate MCP resource server, MongoDB Atlas, three OAuth providers) without also standing up its own container pipeline for the demo.

That matters more for a small team than it sounds. Code-to-Career already juggles six external integrations (Gemini, LinkedIn Jobs, NewsAPI, MongoDB Atlas, Google OAuth, GitHub OAuth), so deployment is one place the team could use a managed path instead of building one. Worth being precise here: the mentor-context server itself is plain Express, not built on the NitroStack SDK, and the README treats it as an optional, separate integration point rather than the app's load-bearing backend. NitroCloud's contribution is getting the app in front of judges, not shaping the MCP resource itself.

The design choice that matters

The detail worth noticing isn't the chat window. Every hackathon project has one of those. It's treating student progress as something readable rather than re-derived each time. Many "personalized AI mentor" demos either stuff full conversation history into every prompt or keep no memory at all. Code-to-Career instead treats the roadmap collection as the single source of truth and reads from it twice: inline, in the main API, and again through a standalone resource server for any consumer that isn't the app's own frontend. State lives in one place; two different readers use the same resource instead of maintaining two copies of "what this student knows."

What the build demonstrates

There's no production usage data here, and the README doesn't claim any. This is a hackathon build, judged on technical quality, innovation, real-world impact, and completeness, not a customer rollout. What it demonstrates is a full loop: a roadmap grounded in live job postings, a mentor that reads that roadmap before replying, an interview generator pulled from the same data, and a deployed instance anyone can open. The two-step roadmap agent and the resource-scoped mentor context are the parts of the implementation that go past "call an LLM and format the response." The rest of the platform (code reviewer, job board, news feed, community board) runs on more conventional CRUD-plus-Gemini patterns, a reasonable place to spend less engineering effort in a time-boxed build.

Reusable takeaway

The reusable pattern isn't "add an AI mentor." It's keeping a single, queryable record of user state and exposing read access to it as a resource, rather than baking context-fetching logic into every place an AI feature needs it. Once that resource exists, a chat feature, an interview generator, or an external MCP client can all read the same ground truth instead of drifting into slightly different versions of "what this user has done."

Code-to-Career's source, including the mentor-context MCP server, is on GitHub. Teams shipping a similar Next.js-plus-MCP stack can see NitroCloud's deployment path in the docs.