Jobsin.co - International Job Platform for Technical Specialists

#Content with an expiry date

Most content on a website ages slowly. A job posting does not. It expires on a scheduled day, and after that day it is actively harmful: a candidate applying to a role that no longer exists wastes their time, and the site loses credibility faster than it would from any technical fault. That single property, content that dies on a date, shapes more of this platform than any feature on the list below.

Three decisions follow from it. The status of a posting is a field with a closed set of values and a lifecycle of its own, independent of the text. Expiry does not delete the record, it changes its state, because the application history has to outlive the posting it refers to. And an expired posting has to stop being visible to search engines, which is separate work rather than a side effect: a page that has been indexed lives in results for weeks afterwards and keeps sending traffic to a vacancy that is gone.

Structured data for job postings is not decoration in this category, it is the main distribution channel, because search engines surface vacancies in a dedicated module. The markup therefore has to agree with the state of the record to the day rather than with the prose on the page, and that is the only reason the expiry date lives in data and not in a paragraph written by a recruiter.

#What Jobsin.co is

Jobsin.co is a job board for qualified technical specialists in construction, mechanical engineering and related industrial sectors, connecting professionals with employers across several national markets. The project came to us in 2019 and the implementation took around six weeks. The layout came from the client, so the time that usually goes into design iterations went into the two parts that decide whether a job board holds up: the skills taxonomy and the pipeline that moves an application between states.

Technical sectors differ from the rest of the labour market in ways that reach into the architecture. Specialists are in short supply, so the candidate has the upper hand and will not fill in a twenty-field form. A large share of the roles assume relocation abroad, which brings visas, recognition of qualifications and differences in employment law into scope. Requirements are narrow, and a significant proportion of the work is contract-based and time-limited, which changes the entire logic of notifications: a vacancy open for three weeks has to reach the right person in the first few days, because by the third week it is stale.

#The taxonomy is the product

On a general job board, keyword search is enough, because candidate and employer use the same words. Someone looks for work as an accountant, the posting has the word accountant in the title, and matching is trivial. In technical recruitment that mechanism fails immediately, because the same competence has a dozen names: some of them a manufacturer’s trade name, some an industry abbreviation, and some dependent on the country and on whoever wrote the advert.

A welder certified for a particular method, an operator of a particular manufacturer’s machine and an engineer working to a standard that applies in one country are three cases where text search returns either nothing or several hundred unrelated results. The foundation of this platform is therefore not a search engine but an ordered vocabulary of competences: a hierarchy in which a skill has a parent category, links to related skills, an indication of prerequisites and a proficiency level from basic to expert.

Building that vocabulary is subject-matter work rather than programming, and it is the most consistently underestimated part of projects in this category. Matching code written over a vocabulary that is still moving has to be rewritten every time a category is renamed. The order of work here was therefore the reverse of the usual one: the vocabulary first, then search and alerts on top of it. The practical consequence is that adding a sector after launch is a data exercise and not a code change.

#Search, matching, and what matching does not claim

Search runs on that vocabulary and on closed attributes: location split into country, region and city, sector, experience level, contract type, salary range and currency, and remote options. Matching weighs skill overlap, the importance of location preference, experience level and pay expectations.

It is worth stating plainly what such a mechanism does not do. It does not assess a candidate and it does not predict whether they will succeed in a role. It orders a list by agreement between what both sides have written about themselves, and no more than that. Platforms in this class are often described in language implying more, and the difference matters, because it decides whether a recruiter treats the result as a suggestion or as a verdict. A percentage next to a vacancy is legible to a candidate and is simultaneously the riskiest element in the interface, because a number looks like a measurement while being a sum of weights somebody set by hand.

Technically, search runs through Elasticsearch rather than through MySQL queries. The reason is mundane: filtering on a dozen attributes at once across tens of thousands of records is, in a relational database, a query with many joins that returns instantly on an empty install and takes seconds against a full archive. MySQL remains the source of truth, because the search index is a derived structure and must be rebuildable from scratch.

#Alerts, or traffic you generate against yourself

Notifications about new vacancies are the return mechanism of a job board and simultaneously the easiest way to destroy your own sender reputation. A site that emails every matching candidate on every new posting lands in spam folders within a month and then stops reaching even the people who asked for the alerts.

The answer has three layers. Delivery runs through a queue, so publishing a posting creates jobs processed at a rate the mail provider accepts rather than hundreds of messages in one instant. The candidate chooses the frequency, immediate, daily or weekly, with the daily digest as the default, because in technical recruitment a vacancy rarely demands a reaction within the hour. Grouping happens by relevance rather than by date, so that one message carries a few vacancies worth opening instead of twenty arbitrary ones.

The queue does something else that is rarely mentioned: it detaches heavy operations from the user’s request. Publishing a posting, recalculating the search index and sending notifications are three separate jobs, and only the first has to finish before the recruiter sees a confirmation.

#An application is a state, not a submitted form

On most websites a form ends when a message is sent, and that is its entire lifecycle. On a job board an application is an object that lives for weeks and moves through states: submitted, reviewed, invited to interview, rejected, closed along with the posting. Treating it as an email looks like a simplification and causes two problems at once.

The first is silence on the candidate’s side. Someone who has sent ten applications and does not know what happened to any of them stops using the site faster than someone who receives rejections. A status view and a notification on each change cost almost nothing and decide whether the candidate comes back. The second is the recruiter’s own work: without states there is no way to say how many applications are waiting, and no report that is not manual counting in an inbox.

States also matter for data retention. An application contains personal data and has to be deleted or anonymised after the period the candidate consented to. Without an explicit state and date that cannot be automated, and doing it by hand means that within a year nobody is doing it at all.

#The candidate, their data, and control over it

A candidate profile in technical recruitment is substantial: competences from the vocabulary, certificates and licences with expiry dates, employment history with project descriptions, languages, location preferences including willingness to relocate, and pay expectations in a chosen currency. A CV is generated from that data, several versions can be kept, and applying from a completed profile is a single action.

The most important part of this area is not a feature but a default. An employed candidate looking for work does not want their current employer to see the profile. Profile visibility, anonymous applications and the question of exactly what a company sees before contact are therefore under the user’s control, and the defaults are conservative. A site that shows everything to everyone by default collects more profiles at launch and loses precisely the candidates who are most in demand, because they have the most to lose.

Data protection here is consequently not only compliance understood as a policy page and a consent checkbox. It is part of the product: consent management, portability, erasure and storage inside the European Union are the requirements that decide whether a candidate creates an account in the first place.

#The employer side and the honesty of postings

A recruiter gets a posting editor with a structured requirements list, support for multiple locations, salary ranges, deadlines and a template library, and on the candidate side an application tracker, profile comparison, interview scheduling and message templates. Team access means several people work on one vacancy, so a status change has to be attributed to a person rather than to the company account.

Trust is a separate matter. On international markets a fraudulent posting is a real danger to a candidate, because it involves work abroad, relocation costs and sometimes fees demanded up front. Employer verification is therefore multi-stage, postings are moderated, and user reports go to manual review. Automated detection of patterns typical of fraud is an aid rather than a decision: the last step is taken by a person, because the cost of a mistake in one direction falls on the candidate and in the other on an honest employer whose vacancy has been held.

#Compliance without the fiction of one policy

A platform operating in several countries faces different employment law, different data requirements and different rules on publishing salary ranges. The worst available answer is a single policy written for the most permissive jurisdiction, because it looks like order and is in fact a transfer of risk to the user.

Instead the compliance layer is modular: terms and clauses are attached to a country, data is routed to the right location, and the differences are described as configuration rather than as code. Adding another market then means completing a set of rules and obtaining a legal review for that jurisdiction, not auditing the whole application.

#Performance and the stack

The platform runs on WordPress with a custom job board theme, a heavily adapted posting engine, a set of in-house plugins and Advanced Custom Fields Pro. The data layer is MySQL with replication, Redis for session and object caching, Elasticsearch for search and a separate store for analytics. Around that sit distribution and structured data integrations, payment gateways and email providers, with cloud hosting, a CDN, load balancing, queue workers and monitoring underneath.

Performance work concentrates on the listing views, because they carry most of the traffic and are the most expensive to compute. Cache holds results for the most common filter combinations, static assets come from the CDN, and database queries were reviewed for the ones that grow linearly with the number of postings.

#How the work ran

Delivery ran about six weeks from scope analysis to launch. The order of work described above followed from one observation: the two expensive mistakes in this category, an unfinished vocabulary and notification delivery without a queue, only reveal themselves at volume, so they have to be settled before launch rather than after the first month.

Load testing runs against a copy of the live data, not an empty install, because a query that returns instantly against a demo dataset behaves differently against a full listing archive with years of applications attached to it. After launch the project moved into maintenance: backups, security updates, periodic performance review and load testing before the periods when hiring volume rises. Maintenance also covers posting quality control and moderation, which on a job board is not editorial work but direct protection of the site’s credibility.

#Conclusion

Jobsin.co shows that a job board in technical recruitment is not a list of vacancies with a search box. It is a vocabulary of competences, a notification mechanism, a compliance layer for several markets and an employer verification process, with the interface as the last layer over all of it. Every technical decision above follows from that order: the vocabulary before matching, the search index separate from the source of truth, the queue in front of delivery, conservative privacy defaults, and a person in the final moderation step.

What carries over to the next implementation is the way of working. The vocabulary and the integrations do not carry over, because they were built for one market and one client’s data. The next project starts with a scope analysis, and the quote follows it.