End-to-end HR platform for high-volume hiring
Responses from job platforms reach hiring without loss, and candidates see their status in one portal.
Project
The platform brings candidate sources, internal recruiting, and a candidate portal into one process, reducing the risk of losing a response between a platform and the team.
- Context
- A response from a platform has to be captured without loss, linked to a vacancy and a candidate, and taken through communication, interviews, and a decision — while different roles only see the data slice they are allowed to see.
- Business problem
- Connect external job platforms to the internal hiring process so a response is never lost or loses its status history during network failures or duplicate delivery.
Chosen solution boundary
A single workflow with protection against duplicate events, role-based access, and a separate portal — recruiters and candidates stay in one process but see different slices of data.
Contribution
From problem boundary to production
- 01 Candidate, vacancy, and hiring-stage data model design
- 02 Integration layer with external job platforms
- 03 Internal back office and candidate portal
- 04 Access control and personal-data lifecycle
Business problem and context
Problem
- A person may apply more than once or from different platforms and must still be recognized as one candidate.
- An external platform can redeliver the same event with a new identifier.
- Internal and platform statuses do not map one-to-one and must be synchronized in both directions.
- Different roles — recruiter, manager, security, candidate — must see different slices of the same data.
Users and context
- Recruiters and managers work with vacancies, responses, and candidate records, and schedule interviews and internships.
- Managers administer roles and reference data and see aggregated reports and background-job status.
- Security staff work with a separate, role-limited candidate verification view.
- Candidates sign in to a dedicated portal, confirm data-processing consent, message the hiring team, and receive status notifications.
Solution
- Intake and deduplication of responses from external platforms, preserving events that cannot be processed immediately so they can be retried later.
- A single candidate record with a status history covering interviews, internships, and the hiring decision.
- Durable status sync back to the external platform through a retry mechanism.
- Messenger and portal with notifications and live status updates.
- Role-based access and anonymization versioned consent for personal-data processing and automatic anonymization once the retention period expires.
How it works
- Intake & deduplication
The system accepts webhook events from external platforms and matches a response and a candidate against existing records by source and contact details.
- Assignment & communication
A response is assigned to an owner based on the candidate's identity on that platform; further communication happens through the internal messenger with live updates.
- Hiring stages
Interviews, internships, and the hiring decision are recorded with a status history and reasons for rejection.
- Sync & data lifecycle
A status change is reliably sent back to the platform with retries; personal data is anonymized automatically once the retention period expires.
Product surfaces
Architecture and reliability
A connector layer receives events from external platforms and hands them to background jobs that update the candidate and vacancy model; the back office and the candidate portal share the same data with different access rights, and live updates travel over a separate messaging channel.
- Connector layer for external job platforms
- Background intake and sync jobs
- Back office
- Candidate portal
- Live-update channel
Reliability and security
- Role-based access with a separate, restricted view for security staff.
- Versioned consent for personal-data processing with a date and source.
- Time limits on background jobs to guard against stuck network calls.
- A candidate can request deletion of their own data from the portal after re-confirming their password.
Engineering decisions
An unresolved event is stored in full and can be replayed later instead of being discarded.
Challenge An incoming event from an external platform sometimes cannot be processed immediately, for example before a vacancy is synced.
Why it matters A response is not lost because of a temporary data-sync gap.
Deduplication also checks for a matching candidate by contact details, not only the event identifier.
Challenge An external platform can redeliver the same event with a new identifier.
Why it matters The same candidate is not created twice in the system.
Outbound sync runs through a separate durable mechanism with state and retries.
Challenge A status change must be synced to the external platform reliably, not inside a single user HTTP request.
Why it matters A temporary platform outage does not lose a status update.
Identifying fields are anonymized automatically once the configured retention period expires.
Challenge Candidate personal data cannot be kept indefinitely after the process ends.
Why it matters The personal-data lifecycle is built into the product rather than left to a manual process.
An outgoing message sent by the system is "adopted" once the platform confirms it, instead of creating a duplicate record.
Challenge A candidate may message the chat more than once, and an outgoing operator message does not always get a platform identifier right away.
Why it matters The conversation is not duplicated even when platform confirmation is delayed.
Each outbound sync operation keeps its own state and is processed independently of the others.
Challenge Syncing a status change to the platform and sending the candidate an autoreply are different operations, and neither should depend on the outcome of the other.
Why it matters A failure in one operation does not block or roll back the other.
Technologies
- Python
- Django
- PostgreSQL
- Celery
- Redis
- Channels / WebSocket
- Docker Compose