← back to amine el moumen

AMSAhub — Candidate–Recruiter Matching Platform

React.jsNode.jsMongoDBREST API

A full-stack web platform connecting job candidates and recruiters: profiles on both sides, job postings, a matching mechanism, in-platform messaging, and a dashboard for recruiters to manage postings and applicants.

The problem & constraints

A job-matching platform has two very different users (candidates and recruiters) who need different views of mostly the same underlying data (profiles, postings, applications), plus real-time-feeling messaging without over-engineering a chat system for what is fundamentally a request/response workflow.

Approach

  • React.js frontend consuming a Node.js/REST API backend, with MongoDB as the document store — a natural fit for profile and posting data that varies in shape between candidates and recruiters.
  • Matching logic implemented as its own layer between postings and candidate profiles, rather than baked into the UI, so the matching rules can evolve independently of how results are displayed.
  • Separate dashboard views for candidates (browse/apply) and recruiters (manage postings, review applicants, message candidates) built on the same underlying API rather than two disconnected apps.

Trade-offs made

  • MongoDB over a relational database: candidate and recruiter profiles have different, evolving shapes (skills, experience, company info); a document store avoided a lot of schema migration overhead a relational design would have required for the same flexibility.
  • A shared REST API for both user types over separate backends: kept the system simpler to reason about and deploy, at the cost of more conditional logic in the API layer to serve two different audiences.

Results

A working platform covering the full loop: profile creation, posting jobs, matching candidates to postings, messaging, and a recruiter-facing dashboard to manage the process end to end.

What I'd do differently

Introduce a proper indexing/search strategy on MongoDB earlier (rather than naive queries) once posting volume grows — matching and search are the features most sensitive to data volume in this kind of platform.