Hiring is a process, and processes can be open
Free software communities learned long ago that code improves when many people can read it, question it, and propose changes. The same insight applies to something far less technical: how we decide who joins a team. In many organisations the hiring process is a black box. Candidates do not know what is being assessed, interviewers improvise their questions, and the final decision rests on a vague sense of "fit." That opacity is not neutral. It quietly rewards people who resemble the interviewers and penalises people who do not.
Structured interviewing is the closest thing hiring has to an open standard. It means every candidate for a role is asked the same core questions, in roughly the same order, and their answers are scored against a rubric that was written down before the first interview began. Decades of industrial-organisational research have found structured interviews to be among the more predictive and more consistent selection methods, while unstructured conversations tend to be noisy and vulnerable to bias.
The four freedoms, translated for interview rubrics
The free software movement describes four freedoms: to run, study, modify, and share a program. They map surprisingly well onto a healthy interview process.
- Freedom to use. Any interviewer on the panel should be able to pick up the rubric and run a fair interview without needing tribal knowledge.
- Freedom to study. The criteria should be written plainly enough that a new team member, or even the candidate, can understand what "strong" looks like for each question.
- Freedom to modify. Rubrics should be versioned. When a question proves confusing or fails to predict job performance, the team revises it and records why.
- Freedom to share. Good question banks and scoring guides can be published, so other teams — especially small nonprofits and community projects with no HR department — can reuse and adapt them.
Writing a rubric like you would write documentation
Start from the work, not from a wishlist of traits. List the three to five things a person in the role actually has to do well in their first six months. For each, write one behavioural question ("Tell us about a time you had to…") or one practical task, and then describe what a weak, adequate, and excellent answer contains. Use concrete anchors. "Communicates well" is not an anchor; "explains a trade-off and names who would be affected by it" is.
Keep the rubric in a plain-text file in the same repository where you keep your team's other documents. Changes go through review just as code does. This sounds bureaucratic, but it is mostly a matter of habit, and it gives you an audit trail that is genuinely useful when someone asks, months later, why a candidate was or was not advanced.
Reducing bias without pretending it disappears
No process removes human bias completely, and it is worth being honest about that. What structure does is shrink the space in which bias operates. A few practices help:
- Score each answer independently, immediately after the interview, before talking to other panelists.
- Separate the evaluation of skills from conversations about salary, background, or personal circumstances.
- Review aggregate outcomes periodically. If one question consistently scores certain groups lower without predicting later performance, that question deserves scrutiny.
- Tell candidates in advance what the stages are and what each one measures. Transparency is a form of accessibility.
Where software fits — and where it should not
Tools can make structure easier to maintain at scale. A spreadsheet works fine for a five-person project. Larger teams often adopt software that stores question banks, collects scores, and keeps every candidate on the same track. Some newer tools use AI to run first-round screening conversations with consistent questions. For example, Talynce is an AI recruiting platform built around this idea, and its AI recruiter runs structured screening interviews so that every applicant gets the same opportunity to answer the same questions before a human reviews the results.
Whatever tool you use, the free-culture principle still applies: the criteria must remain visible and contestable. Ask any vendor, proprietary or not, what is being measured, how scores are produced, and how a candidate can request human review. An automated system that cannot explain itself recreates the black box we were trying to open. Software should carry out a rubric your team understands, not replace that understanding.
Sharing back
Open-source projects thrive because people contribute improvements upstream. Hiring teams can do the same. Publish a sanitised version of a rubric that worked well. Write a short post about a question you retired and why. Share your interview stage descriptions so that other organisations can borrow them. Each contribution lowers the barrier for the next team that wants to hire fairly but does not know where to start.
Hiring will always involve judgment. The goal is not to remove people from the process but to make their judgment legible — something that can be read, checked, and improved together. That is, in the end, what free culture has always asked of us.