Job board software for universities and bootcamps
A careers board at an educational institution is judged on graduate outcomes rather than on revenue, and that single fact reshapes the requirements. Who is allowed to apply matters more than how many apply. Which employers are allowed on matters more than how many roles there are. The reporting matters more than either.
From $79/month · 14-day free trial · No setup feesIt is also a buying decision made inside an institution rather than by an individual, which means the questions asked are about data ownership, access control and continuity rather than about features.
A cost centre with two ways to stop being one
“How do we make sure only our students can apply?”
Through required fields and approval on the account rather than through an identity integration. Candidate signup can require an institutional email domain, a student number, a programme and a cohort, and accounts can be held for approval until a member of staff releases them.
What is not available is single sign-on against your institutional identity provider. There is no SAML or Shibboleth integration. A student creates an account on the board with their institutional email; they do not arrive already authenticated from the student portal.
For a bootcamp this is usually fine. For a university where SSO is a procurement requirement, it is likely to be disqualifying, and Handshake or a similar sector-specific platform will fit the requirement better.
Handshake
The incumbent in this sector, and the thing your careers service is probably already comparing against. It is worth being clear about what it is: a network, where the value is that employers and students from many institutions are already on it. An institution-owned board is the opposite trade. You give up the network and you get control of the employer relationships, the branding and the outcome data. Which of those matters more is the actual decision.The parts of Kardow that do this job
Required fields at signup, enforced server-side
Programme, cohort, graduation year, student number: whatever your reporting needs, collected at account creation and enforced on the server rather than in the form, so an account cannot exist without them.Approval on employers and on listings
Both accounts and postings can be held for review. An institution carries reputational risk from every employer on its board, and approval is what makes that manageable.Separate student and employer account types
Two distinct account types with different permissions, different signup fields and different pricing, which is what allows a student experience and an employer experience to coexist on one board.Documents held with access control
Resumes, transcripts and portfolio files attach to applications with per-file access rules, which matters when the files are student records rather than ordinary attachments.Your data, exportable
Applications, outcomes and employer records export as CSV on demand. Outcome data is what the institution is measured on, and it should not live somewhere you cannot get it out of.Where Kardow is the wrong answer here
What people ask before they build one.
- Can alumni use the board as well as current students?
- Yes, and it is usually worth designing for from the start rather than adding later. Alumni are both candidates and employers: they hire, and they are the employer relationships that are easiest to build. Account types can distinguish current students, alumni and employers, with different access and different signup requirements for each.
- What about placement and internship listings specifically?
- They are ordinary listings with your own fields on them. Placement year, credit-bearing, duration, start window and supervisor requirements are all configurable fields that become filters on the board, which is what students actually need in order to find the right one.
- Who owns the data if we stop using Kardow?
- You do, and you can take it with you. Jobs, applications, employer records and candidate accounts export on demand, and on Pro and above the board itself is a Next.js application you can download and host yourself. That answer is the one an institutional buyer is actually asking for, and it is a fair reason to prefer an owned board over a network platform.