Career Quest — Skills assessment → job recommendations

In short

Career Quest is the career-guidance platform I built during my internship at Guidya, as lead developer in a team of three with Aymane Bouras and Yassine Mchereg. The company brought the business requirements and the mentoring; we turned them into features.

A candidate takes assessments — cognitive, situational, technical — and gets an employability profile and job recommendations out of them. Our build took first place in EMSI's internship competition.

The problem

A CV says what someone has studied, not what they can do. The platform's job was to measure the second thing and make it actionable: which roles fit this person, and why.

That splits into two problems pulling in different directions. Scoring has to be defensible — the same raw results should not rank a future product manager the way they rank a future software engineer, and a candidate told they fit a role less well deserves a reason. Recommending has to work for someone who signed up five minutes ago with no history at all, as well as for someone the system knows well.

Architecture

A React front end over a Django REST API, with the test engine, the scoring and the recommendations as separate modules behind it.

Assessments. Six kinds of cognitive test — verbal, numerical, logical, abstract, spatial and diagrammatic reasoning — plus situational judgement and technical challenges, each run as a timed session by the test engine.
Scoring. Every question carries a difficulty coefficient, from 1.0× for easy to 2.5× for expert. Results are aggregated per dimension, weighted for the target profile and normalised to a 0–100 scale.
Recommendations combine content-based matching on skills and requirements, collaborative filtering once there is history to learn from, cosine similarity for the matching itself, and K-Means clustering to segment candidates.
The API is authenticated with JWT and described by an OpenAPI schema generated from the code. PostgreSQL holds everything durable, Redis backs Django's cache, and Celery runs the recommendation work that shouldn't block a request.

Decisions & trade-offs

Weights belong to the role, not the candidate

One global score would have been simpler, and wrong. The software-engineer profile weights technical results at 35% and communication at 5%; the product-manager profile nearly inverts that, with situational judgement first. The same results produce a different fit for each role — and because every weight is explicit and named, every score traces back to a dimension and a number. A score a candidate can ask about, and get a real answer to, is the only kind worth showing them.

A hybrid recommender, because of day one

Collaborative filtering is the powerful half — it finds roles that candidates like you went on to do well in — but it needs history, and a new candidate has none. Content-based matching needs nothing but the candidate's own results, so it answers on the first visit. Combining them means recommendations are useful immediately and get better as the platform learns, instead of being empty until they're good.

The API contract is generated, not written

With three developers, the contract between front end and back end is what lets people build in parallel. Generating the OpenAPI description from the Django code meant the documentation could not drift from the implementation — the front end built against what the API actually did, not what someone remembered it doing.

What was hard

Working on a real product with other people. Three developers on one codebase, against a company roadmap rather than a school brief, meant agreeing on interfaces before building behind them, reviewing each other's work, and deciding together what to drop. We did drop features, and shipped the rest.

It was also my first time leading other developers: splitting the work so three people could move in parallel without stepping on each other, and owning the parts that connected their pieces.

Outcome

First place in EMSI's internship competition, and a platform the host company could put in front of candidates: assessments across cognitive, situational and technical skills, a score that explains itself, and recommendations from the first visit.

What I'd do next

Consolidate the recommender. Iterating fast as a team left several generations of it side by side in the codebase — a base, an "enhanced" and an "advanced" service — and one version with an offline evaluation would beat three without. That evaluation is the real next step: hold out candidates whose eventual roles are known, and measure how often the recommendations would have found them.

The repository also still carries the original internship name and some committed environment files; cleaning that up is overdue.