Job Discovery
Internship Radar
A full-stack platform that aggregates placement and internship listings from multiple sources, scores them for relevance, and tracks every application from discovery through to offer.
Dashboard — three-panel view with fit scoring, real-time filtering, and role detail.
Overview
Internship Radar pulls placement and internship listings from multiple sources into one interface. Students filter by role type, location, and deadline — then see a relevance score from 0 to 100 on every listing so they can immediately focus on what's actually worth applying to.
Once applied, a separate tracking view takes over — showing total applications, those in review, and any active interviews as an aggregate snapshot alongside per-role status updates.
- —Aggregates placement and internship listings from multiple sources.
- —Scores each role 0–100 for relevance against a student profile.
- —Tracks applications through applied, interview, and offer statuses.
- —Separates discovery and tracking to reduce cognitive overhead.
The Problem
Finding a placement means checking multiple job boards separately, each with different formats, filter systems, and application processes. Students end up managing applications in spreadsheets with no way to compare opportunities across sources.
The bottleneck isn't finding roles — there are plenty of them. It's quickly deciding which ones are worth the effort and staying organised throughout a process that can run for months.
My Applications — aggregate statistics, activity feed, and status tracking per role.
Design Decisions
The three-panel layout — filters left, scored listings centre, detail right — keeps everything visible without navigating between pages. It mirrors how students already work across multiple browser tabs, just unified.
The Applied view is deliberately separate from the discovery view. Mixing the search mindset with the tracking mindset creates cognitive overhead, so each has its own dedicated interface.
Relevance scoring is visible on every card so the decision to apply requires less active consideration. The score isn't the whole picture, but it surfaces the right conversations immediately.
Implementation
The Node.js API handles aggregation from external sources — normalising each listing into a consistent internal schema before scoring and storage. Format differences across job boards make normalisation the most time-consuming part of the pipeline.
Fit scores are computed server-side using a weighted algorithm against the student's profile. PostgreSQL stores roles, users, saved listings, and full application history with each status transition recorded as an event.
Frontend
React · TypeScript
Three-panel layout with tab-based navigation between Dashboard, Saved, and Applied.
Backend
Node.js · REST API
Multi-source aggregation, schema normalisation, fit score computation, and state management.
Database
PostgreSQL
Roles, users, saved listings, application records, and status history.
Data Pipeline
Aggregation layer
External listings scraped and normalised into a consistent schema before scoring.
What I Learned
- —Normalising data across sources requires careful schema decisions from the start. The fields that seem minor early on become the hardest to retrofit later.
- —Scoring relevance meaningfully is harder than it looks. Keyword matching alone produces misleading rankings — weighting matters enormously.
- —Building for a problem I was actively experiencing made every design decision concrete. When something didn't help the actual workflow, it was easy to remove.