A recruitment platform connecting people with eligible jobs in Japan.
In an existing team service, I implemented evidence-based recruitment classification, Spring Boot profile matching, and email delivery with consent and history controls.
ResultLive service · classification, matching, and delivery history implemented
Getting collected jobs to people who can apply
NARU brings jobs, companies, events, and mentoring together for Koreans seeking work in Japan. I joined the team's existing service and implemented recruitment classification, profile-based matching, email delivery, and operational screens.
Collecting jobs is only the first step. Ineligible or repeated recommendations make notifications less useful, so the path needed to connect source evidence, matching decisions, and delivery records.
Missing eligibility evidence stays unknown
Japanese job postings distinguish new graduates, recent graduates with early work experience (第二新卒), and experienced hires. I implemented a Python classifier that uses explicit source wording and retains the source field, matching phrase, and URL for each decision.
A phrase such as '28卒' explicitly identifies the 2028 graduate cohort; an April 2028 start date alone does not. A reference to people who have already graduated does not establish eligibility for the 第二新卒 category. Missing or conflicting evidence stays unknown or ambiguous, with tests for these boundaries.
Inspecting candidates before sending
In Spring Boot, I matched recruitment category, cohort year, and preferred roles against job data, then added a dry-run that exposes candidates and reasons before sending. Email uses the same matcher so its eligibility rules do not drift from the web flow.
The digest selects up to five newly published jobs and excludes jobs already recorded in prior emails. An empty selection produces no email, and previewing does not change the database or call the delivery provider.
A provider call is only one part of delivery
I kept topic-specific email consent separate from existing in-app notification preferences. A database uniqueness constraint prevents duplicate deliveries for the same campaign, member, and topic, alongside the provider's idempotency key.
Signature-verified webhooks record delivery, bounce, and complaint events and feed future suppression checks. The admin screen exposes sending controls, delivery history, and failed-delivery retries; both environment and database switches must allow real sending.
I implemented the feature code, tests for classification, matching, and sending conditions, and operational screens. The service is publicly accessible.
I learned to connect data collection with unknown eligibility, recipient consent, delivery history, and retry behavior.
Not yet verified
Automatic email rollout to all members, deliverability, and impact on applications remain unverified.
Next to verify
- Measure classification errors and unknown cases in operation
- Verify failures, suppression, and duplicate controls against operational records