Hiring & the ATS

Hiring is the first step in Interwise’s core value loop: hire, onboard, run payroll, pay out — repeat every period. This page goes deep on the first two steps. The Hiring module is a small, focused applicant-tracking system (ATS) built directly into Interwise: job posts, a public careers page candidates apply through, and a pipeline that a hiring manager runs through to an offer. What makes it different from a standalone ATS is the last step — a hired applicant converts directly into an employee record, ready for its first payroll run, without anyone re-typing a single field into a second system.

Job Posts

A job post starts as a DRAFT and is only visible to the company’s own admins. Publishing it (PUBLISHED) is what makes it appear on the public careers page — closing it (CLOSED) removes it from that page without deleting its history or its applicants. Creating and publishing a job requires COMPANY_ADMIN (or higher); every job post has a unique, URL-safe slug within its tenant, generated from the title if one isn’t given.

A job post carries the basics a candidate needs to decide whether to apply: title, department, location, employment type (full-time, part-time, contract, internship), and a description written in markdown.

The Public Careers Page — Interwise’s Only Public Surface

The careers page is deliberately the one part of Interwise reachable without a login. Every other page in the product sits behind a session; the careers page and its apply flow are the exception, served from a completely separate, unauthenticated route that resolves the tenant from a slug in the URL and reads only what’s already PUBLISHED.

Because it’s the one thing an outside candidate — or a competitor, or the company’s own client — ever sees of Interwise directly, it carries outsized weight: it speaks for the company. It has to load fast, look clean, and feel trustworthy on a phone in one hand, because that’s how most candidates in Indonesia actually apply. There’s no excuse for a clunky public form when the entire rest of the product is behind a login and never seen by anyone outside the company.

The apply form is deliberately minimal: full name and email are required; phone, a CV (upload a PDF/DOC/DOCX up to 5MB, or paste a link instead), a cover letter, and an expected start date are optional. That’s the whole form — no NIK, no bank details, no date of birth, no dependents, no address. Those are Indonesia-specific payroll and compliance fields, and Interwise deliberately doesn’t collect them on a public, unauthenticated form; asking a candidate for a national ID or bank account number before they’re even hired is a privacy and professionalism problem, not a convenience. That data is collected once — during onboarding, after the candidate is hired, by HR inside the product.

The Applicant Pipeline

Once an application comes in, it moves through a fixed set of stages, shown to the hiring manager as a stage board — one column per stage, cards moving left to right as a candidate progresses.

New — the application just came in, untouched.
Reviewing — a hiring manager is looking at it.
Interview — the candidate is being interviewed.
Offer — an offer is out.
Hired — the candidate accepted, and the application is ready to convert.
Rejected — a candidate can be moved here from any of the first four stages; it’s a dead end, not a stage in the forward sequence.

A hiring manager (COMPANY_ADMIN) drags or advances a candidate stage by stage, and can attach an interview score (0–100) as they go. That score is scoped entirely to hiring — what it feeds into, and what it deliberately does not feed into, matters enough to get its own section below.

Convert to Employee — Zero Re-Keying

The point of running hiring inside Interwise rather than beside it: converting a Hired applicant into an employee is one action, and it reuses the exact same employee-creation path a manually-added employee goes through — so an ATS-sourced hire is never a special case for tax, BPJS, or employment-period logic.

What carries over automatically: full name (split into first/last), email, and phone from the application, the job title from the post they applied to, and a start date (the candidate’s expected start date if they gave one, otherwise today). That’s everything the apply form collects — NIK, bank name and account number, address, and PTKP/dependents were never on the application, so the new employee record starts with those fields blank.

That’s by design, not a gap: a public, unauthenticated form should never be the place BPJS or tax filings depend on being exactly right. HR completes NIK, the PTKP code, and bank details once, during onboarding, through the normal employee-verification flow — the same step any employee added outside the ATS goes through, and the point where those fields belong.

Conversion is idempotent and collision-safe: converting the same applicant twice returns the same employee rather than creating a duplicate, and if another employee already has that email, the conversion is rejected with a clear conflict instead of silently producing a broken duplicate.

The Safety Guard: Recruiting Score Is Not Payroll Points

The interview score a hiring manager sets while an applicant moves through the pipeline (0–100) and an employee’s points field are unrelated numbers that must never be confused — points distributes real money, weighting how a company’s monthly service-charge pool is split across employees. Mapping a recruiting score onto it during conversion would silently corrupt that distribution with a number that was never meant to represent it. Interwise keeps them apart by construction: score stays on the application, full stop. points is left for HR to set afterward through the normal employee flow, the same way it’s set for anyone hired outside the ATS. It’s a small rule, but it’s exactly the kind of place where hiring data and payroll money need a hard line between them — not a decimal-point mapping.

Why Interwise’s ATS Beats a Standalone Tool

Standalone applicant-tracking systems — SmartRecruiters, Greenhouse, Lever — are built to get a company to an offer, and stop there. What happens next is someone’s manual job: export the hire’s details, re-type them into a separate HRIS or payroll system, chase down the tax and bank fields the ATS never asked for in the first place. Interwise’s ATS is deliberately smaller in scope, but it closes that gap completely:

Hiring→payroll continuity. Applicant, to Hired, to employee record, to a first payslip — one system, one data model, zero re-entry. No standalone ATS can do this, because none of them run payroll.
Indonesia-native compliance, completed at the right moment. NIK, PTKP, and bank details — the exact fields PPh 21, BPJS, and disbursement need — are filled in once HR onboards a hire, inside the same product that runs payroll, instead of a generic Western ATS form that has no concept of any of them and no route into a payroll system at all.
A pipeline a generalist can run. Job posts, a stage board, and a convert-to-employee button — no dedicated recruiter or a second subscription to learn, configure, and keep in sync with the HR system of record.
A public careers page that reflects well on the company, because it’s built into the same product that already has to be fast, clean, and mobile-first for every other user.

This is a deliberately honest comparison, not a feature checklist: Interwise’s ATS doesn’t do interview scheduling automation, video screening, or sourcing — it does the part that matters most for a company that already runs its HR and payroll in Interwise, which is the handoff a standalone tool can’t make.

Where to Go Next

Overview — the full core value loop this module feeds into, from hiring through payroll to a payslip.
Roles & Access — who can post a job, review a pipeline, and convert an applicant (COMPANY_ADMIN and above).
User Journeys — the Hiring Manager’s day-to-day walkthrough of posting a job and running a pipeline to an offer.

More guides — covering the Payroll Engine in depth — are on the way.