Recruiting plugin

[sumboid]

Description

Recruiting plugin is a set of applications related to automation and making simpler typical recruiting tasks. This document is high-level description of design and features that we may want to implement.
In general recruiter should have next base features:

1. Operate on candidates: CRUD, apply candidate to specific vacancy, enhanced filtering, having all info related to candidate including historical data. By historical data I mean everything that happened with candidate after he/she was added to pool.
2. Manipulate vacancies within company, define or edit recruiting flow that makes sense for specific vacancy

Model

There are multiple base abstractions that recruiter would work with: Candidate, Vacancy and internal/external platform user able to rate candidate and make a decision about making offer.

Hiring process can be formed as a flow that recruiter may follow and such flow is mostly depend on specific vacancy and company. Currently we call it FSM but can call it something else because this flow can be implemented as fully unrestricted thing with states: from recruiter point of view it should be something that helps to understand what is happening on vacancy and with candidate. So to resume, we should have FSM linked with Vacancy to track applied Candidate progress. FSM and Actions documents will describe more about this.

And the last one is Action, something that user should invoke when Candidate is in specific state. It is not only about restrictions and simplifying but also about a way to gather info about candidate and keep history consistent: ideally anyone who dives into candidate history should get in context as good as recruiter that worked with candidate. Below we will take a look at what it could be.

Use cases

We will omit some trivial cases like recruiter can add candidate, vacancy or edit something.

Application flow

When candidate is in pool it can be applied to some vacancy or not, we may interpret is as candidate has some state within FSM linked with Vacancy or not. When we has finished with candidate on some vacancy we can simply get rid of state properties or make them undefined.

Vacancy setup

As mentioned above vacancy recruiting flow may vary and it depends on vacancy and company. That means recruiter should be able to set up states, actions, transitions to match expected flow.

Possible actions

1. Add some info
   Recruiter usually asks for resume/cv. Of course we can use existing resume, but there are reasons to share another version to describe related experience in details.
   When candidate is working on test task the result would be link to repo or source code. What is more interesting recruiter may ask why task is not ready yet, this is also could be tracked the same way.
2. Planning interview
   Recruiter plans interview on some of the steps, from Platform perspective it's a calendar event so at least we need to be able to create specific doc and external plugin will take care about it. More interesting is to determine event actually happened (at least all participants has accepted suggested time and end time has elapsed) and we can gather feedback from participants but it is more about action dependencies.
3. Gathering feedback
   Recruiter may want to get external feedback and some decision from people responsible for technical interview, test task review or anything else.
4. Send message/file/invitation to candidate
   This could be anything, most notable examples are: test task description, offer, feedback as explanation why candidate is rejected, calendar event details.
5. QA
   It may be useful to have an action to propagate questions from candidate and save them with corresponding answers. For example questions related to test task.

Software Engineer Vacancy example

1. Applied
   Required action is attaching/filling actual resume/cv (1)
2. HR interview
   Required action is interview and getting recruiter feedback. Optionally recruiter can send invitation. (2, 3, 4)
3. Test task
   Required action is to plan review: share source code, assign reviewers, wait for review feedback. (1, 3, 5)
4. Technical interview
   Required action is interview. The action result would be interviewers feedback. Optionally recruiter can send invitation. (2, 3, 4)
5. Offer
   Required action is to discuss with candidate and get feedback, optionally recruiter may send offer via Platform (1, 4)
6. Contract
   Required action is just approve that contract is signed (1)
7. Rejected
   Optional action could be send explanation to candidate or just save reason why candidate decided to reject (4)

[haiodo]

https://kissflow.com/workflow/bpm/business-process/ May be we should start with a bit more high level stuff?

https://kissflow.com/workflow/bpm/business-process-modeling/