Hiring Without Whiteboards

What it is

Hiring Without Whiteboards is a curated list of companies and teams that do not build interviews around whiteboard tasks and CS trivia.

The project appeared as a reaction to hiring practices where candidates get puzzles, rare algorithm questions, and tasks weakly connected to daily work.

The list’s main task is to show alternatives: discussion of a real problem, pairing, take-home exercise, or another format closer to engineering practice.

What is inside the repository

The repository contains a tl;dr, company list, Duds section, discussions, extra reading, and recommendations for better interviews.

The project is useful not only to candidates, but also to hiring teams: it shows that a technical interview can test work rather than trick guessing.

How people usually use it

A normal scenario is for a candidate to find a company, inspect the interview format, and follow sources to check whether the information is current.

For companies, appearing in the list is a way to signal more humane and practical hiring, but the entry still needs to stay up to date.

## Example Company

- Interview style: practical pair task
- Remote: yes
- Notes: focuses on day-to-day engineering work

What it feels like in practice

The project’s strength is social value. It changes the hiring conversation from abstract difficulty to resemblance to real work.

Another advantage is the open format: people can propose changes and corrections when company processes change.

Limits and careful spots

The limitation is that the list ages quickly. Hiring processes change, teams inside one company differ, and information needs verification.

“Without whiteboards” also does not mean “easy”. A practical task can be difficult, but it better reflects future work.

Who it fits

Hiring Without Whiteboards best fits candidates who choose companies by interview culture and teams rethinking hiring.

In the catalog, the project matters as an open repository that improves engineering culture through transparent collective information rather than code.

In long-term work with a project like this, installation is not the only concern: the team needs a clear boundary of responsibility, an update routine, and an owner for usage rules.

In practice, this means running a minimal example before adoption, checking configuration, reviewing updates, and understanding which data or processes are touched. That short pass quickly shows where the project helps immediately and where the team still needs its own decisions.

If the project becomes part of a public site, product, or internal platform, it should be recorded in team documentation: source link, version, owner, and update rhythm. Then the open code remains a managed dependency rather than a random fragment of infrastructure.