What are the stages of a hiring process?

A hiring stage is a stop that says where the candidate stands in the process and who does what there. A stage ends when the record changes, not when the meeting ends. If the status was not updated, then as far as the system is concerned the stage never happened, however much was discussed.

Guides on the subject usually describe the process with a fixed number: seven stages, thirteen steps. That number does not come out of anyone company. In one company a technical assignment is a stage of its own, in another it sits inside the interview; one runs reference checks, the next one does not. What is fixed is not the number, it is the order.

On the GoTeam side that order maps to a fixed set of statuses. An application status takes eight values in the schema; five of them describe the road up to the hiring decision: Pending, Reviewing, Interview, Accepted, Hired. The other three are Rejected and what comes after the hire. You build your own stages on top of that set; you do not change the set, you fill it.

• The output of a stage is not a document, it is a status change. An output that was not recorded does not open the next stage.
• A person makes the move. AI produces suggestions and never changes the status of an application on its own.
• The only automatic status change in the process sits in the last step: when the candidate submits the information form, the application becomes Hired.

The process starts with the definition of the role, not with the posting. In the panel the job title and the department are records of their own, separate from the posting: Internal Position (title, department, level, active flag) and Department. Pick an internal position on the posting form and the department fills itself in; you can also create a new position or department without leaving the form. A published job posting and an internal job title are separate concepts in the code, and confusing the two is what later attaches an employee record to the wrong title.

The posting form handles four jobs on one screen: the basics, the posting text, weighted requirements and responsibilities, scoring bands, and the application questions specific to that posting. The posting cannot be saved until the requirement weights add up to exactly 100. The rule is applied on both sides: the save button stays closed on the client, and the server validates it again with the schema at write time. The reason shows up in step three, where the same list is also the source of the evaluation.

When you publish, the active posting allowance of your plan is checked; if the allowance is used up, publishing is refused, and on unlimited plans the check is skipped. For the posting to reach search results two gates have to be open at once: the posting has to be active, and the description, the requirements and the responsibilities together have to pass 300 characters. That threshold was set by measurement, not by guesswork: across the 13 active postings in production the shortest body was 310 characters and the median was 489.

• The output of this stage: a live posting, a requirement list weighted to 100, and an application form bound to that posting.
• Decision bands are set per posting. The defaults are 55 for strong, 35 for review and 20 for weak, and they have to stay in descending order.
• An active posting whose application deadline has passed is closed by the system, and the address of a closed posting returns 404.

Applications are collected on the career page of the company. The address starts with /c/, the posting detail opens on its own address, and the application form sits under the posting. On the candidate side the CV upload accepts PDF only, with a 5 MB file limit. A Word document gets in through the Drive import on the Enterprise plan alone, never through a candidate application.

The moment an application is saved, two jobs start in the background: a confirmation email goes to the candidate and the CV analysis pipeline enters the queue. The applicant does nothing for this, and nobody presses a button in the panel either. The record is born in the Pending status and waits for the first human action, the review.

This is the point to place the idea of status correctly, because the rest of the process rests on it. A status is not a label, it is the key to the next stage. When you schedule an interview, the automatic status advance only works on applications in Pending or Reviewing; a document request only opens on applications in Accepted or Hired. In a process that moves on without the status being updated, the button for the next stage never appears at all.

In the evaluation stage the application list is ordered by fit score, and every row carries a decision band badge: strong match, under review, weak match, outside the criteria. Band thresholds are set per posting, so the word strong does not stand for the same number on every posting. On a first read the thing to look at is not the ranking itself, it is whether the band agrees with the criteria of that posting.

How the score came about decides how far it can be trusted. The model gives no score: for each criterion it answers whether it is evidenced in this document and leaves a verbatim quote, and the arithmetic happens in code. A criterion with no evidence is not counted as half a point, it leaves the denominator; the absence of evidence is not a shortcoming of the candidate. When a criterion marked as mandatory is not met, the candidate does not drop off the list, a cap is placed on the score; the default cap is 54, just under the strong band.

The year arithmetic behind mandatory criteria is never asked of the model, it happens in code; it made the right call on 12 out of 12 difficult edge cases and produced no false elimination. The system does not learn from past hiring outcomes either: who was invited to an interview or hired never enters scoring. The output of this stage is not a score, it is a status change. The candidates you continue with move to Reviewing, the rest move to Rejected.

In the Schedule Interview dialog you pick the candidate, the date, the duration and the interview type. The option to move the application into the Interview status sits apart in that dialog; tick it and the status advances by itself. But only if the application is in Pending or Reviewing. In any other status the transition is skipped silently and the scheduling still succeeds. That is a deliberate decision, so that scheduling never fails because of a status. The consequence is this: the interview can sit on the calendar while the application stays where it was.

An online interview cannot be scheduled while Google Workspace is not connected, because the meeting link is produced there. An onsite interview can be scheduled without Workspace, only no calendar event is created. A second interview cannot be booked for the same candidate at a clashing hour; the clash check runs on the candidate email, the time and the duration, and it can be overridden by hand when you need to.

The biggest surprise in this stage is email. Letting the candidate know when the stage changes is a choice, not an automation: when you change a status the panel offers two buttons, Update Only and Send Email. If email sending is switched off for the company, only the update button is left and the dialog says so. A templated notification exists for three statuses only: Accepted, Rejected and Reviewing.

In this process the acceptance decision is not an ending, it is the act of opening a gate. Document and information requests only open on applications in the Accepted or Hired status; sending a request to an application in any other status is refused at the service level. On the request screen you set a deadline, pick from the ready made document sets, and review the delivered files on the same screen.

Going back from Accepted or Hired is not free. If that application has an open document or information request, the system raises a warning and asks you to write a reason before the transition continues; the reason is stored as a separate audit field. People often read this as an error and give up, but the gate is deliberate: quietly pulling a candidate back while a request is open closes a process the candidate is still uploading documents into.

The last step is the only automatic status change in the process. When the candidate submits the information form, three things happen in the same operation: the employee record is created, the employment period starts and the application moves to Hired. The three are one database transaction, so if one of them fails none of them happens. If the same person has worked here before, no second employee record is opened; the existing record is refreshed, the old employment period is closed, a new one is opened and the corporate email is reused.

Setting a process up on paper is easy; what makes it run is the link between the stages. In GoTeam that link is not loose: if the output of a stage was not recorded, the tool for the next stage does not open. So stages are worth reading not as "who does what" but as "what does it produce and what does that production open".

The table below shows it row by row. The right hand column says what the user meets in the panel while that output is missing. No error message appears; the button simply never shows up, or the operation is skipped in silence.

Two companies on the same product do not see the same number of stages. The reason is not only that their processes differ: which screen opens for whom is decided by three separate gates, and those gates are independent of each other. A screen appears only when all three are open.

The sentence "we have no document stage" is usually not about the process, it is about a closed gate. Redesign the process without knowing which gate is closed and you land in the same place again.

What follows are not process design mistakes, they are operating mistakes: the process is set up correctly and the link between the stages is broken by hand. All four come from the same place, from not recording the output of a stage.

• Leaving the status until last. Saying "I will move them all later" instead of recording the moment a stage ends keeps every gate in between closed. The interview gets scheduled but the automatic advance never runs, the acceptance is given but the document request does not open.
• Mistaking a suggestion from the AI for a decision. It ranks and marks; the operation that carries a candidate into the next stage is always the approval of a user, and it goes on record under that user name.
• Marking the Hired status by hand. The employee record and the employment period are created only when the candidate submits the information form; an application marked by hand leaves the process half done.
• Assuming the candidate is notified when you change a stage. Sending the email is a separate choice in the dialog, and there are three statuses only with a template: Accepted, Rejected and Reviewing.