How to hire for a high-documentation, low-meeting work culture

By Kapil Kale|5 min read|Updated Feb 9, 2023

There are talented engineers who feel like their brain is covered in Saran Wrap when they’re trying to solve problems on a whiteboard in front of other people. And there are plenty of less talented candidates who know how to work a room.

If your company is fully-remote, asking candidates to perform before an audience is especially useless. And these exercises are often several abstractions removed from anything engineers do in their day-to-day.

So founders who want a productive distributed team should probably build a hiring process that actually assesses applicable skills.

Four bars: One says "intentionality", one says "autonomy", one says "rationality", one says "writing aptitude", and one says "practical performance."

At Tremendous, we’ve created a hiring process that spotlights the qualities needed to thrive in a remote environment.

It involves a lot more writing and way fewer questions than most candidates are used to.

Importantly, this hiring process ignores the qualities that, while impressive, have little to do with real-world performance. Consciously disregarding compelling but irrelevant skills is equally as important as zeroing in on predictive skills.

There are three main indicators we look for in a candidate at Tremendous:

Practical performance
Writing aptitude
Rationality

Here’s how we do it.

Note: I’m going to focus on our engineering interviews for the sake of concision. But we apply this hiring philosophy to every role across the company.

Ground engineering exercises within the scope of the job
Include a writing assignment in every interview
Identify whether candidates are driven by reason or ego

The standard technical interview consists of solving abstract puzzles on a whiteboard as a way to gauge raw engineering ability. We initially used this process as well.

But some of the people who did well on this portion of the interview ended up really struggling to do the job. This is largely because candidates can learn a few tricks online and fake their way through these exercises.

Eventually, we hit on a new interview process that assesses how a candidate would perform on the job with a bit more acuity.

Six steps for a practical sample project. The first step is to give a sample project to the candidate. The second step is to give them the codebase in advance. The third step is to allow them to access all the tools they would normally use. The fourth step is to invite them to a dedicated Slack channel to discuss the work problem. The fifth step is to allow them to use the internet however they want. And the final step is to allow them to do their work without someone watching.

We encourage the engineering hiring manager to give candidates a relatively mundane sample project. We’re trying to see if they can complete their daily tasks quickly and comfortably.

A sample project where candidates are free to ask as many questions as they like reveals who can plow through projects largely autonomously, and who needs a little hand holding.

We have a high-documentation, low-meeting work culture at Tremendous. We communicate clearly on an asynchronous basis, almost exclusively through comms channels like Slack, Github, and Notion.

People who can’t express themselves clearly through the written word flounder in a high-documentation culture. Same goes for those whose reflex is to ask around for help rather than finding the information that’s already out there.

On the left side, below a large blue checkmark, is the word "Do." Below the word do is a list, reading: "be resourceful, take initiative, and write thorough briefs." On the right side is a red "X". Below the "X" is the word "Don't." Then, a list reads: "Schedule meetings injudiciously, wait for approval for small projects/changes, or skimp on details."

Teaching developers (or salespeople, or recruiters, or marketers) how to write effectively is not a good use of resources. So we make sure everyone writes something as part of the interview process.

For engineers, it’s a technical brief. We often ask candidates to write a migration doc as if they’re trying to persuade their manager to adopt a new technology.

We look for two things when assessing these writing assignments:

Did they go into the correct level of detail?
This doesn’t just mean ‘Did they write enough?’ It also means: Did they ask the right questions? Did they flesh out pertinent ideas? Or did they hand-wave over crucial details and only explain low-hanging fruit?
Did they write way too much?
Being concise is important. Did they bury the answers in a wall of content? Other people are going to have to actually read this brief. Being cognizant of other people’s time and attention is equally as crucial as providing sufficient detail.

Even if they’re highly capable engineers who brilliantly tackle practical problems, they won’t succeed in our environment if they can’t write well. So, as a rule, we only hire good writers.

(Note: we don’t require perfection, but rather clarity of communication. The occasional grammatical mistake, especially from those who didn’t grow up speaking English, doesn’t bother us.)

Our interviews are short and focused. We don’t ask candidates to drone on about past projects, or spout off KPI’s they’ve hit at previous companies. It’s easy to blur details on that stuff.

The interview process essentially comprises three parts:

A sample project presentation. The candidate discusses their thinking when approaching the sample project with the hiring manager. We’re trying to see if they took the simplest, most rational approach to solving the problem. For example, if they’re writing multi-tenant applications in Rails, there’s several approaches they could take. They can create multiple databases. This is an insane approach. Or they can go with multiple schema. Also inefficient. Finally, they can leverage scoped access. That’s what we’re looking for. It’s the obvious practical solution.
A sample project discussion. The hiring manager asks the candidate pointed questions about the exercise.
A founder fit session. Nick Baum (my cofounder) or I ask the candidate a short series of behavioral questions.

I want to zero in on one specific question, because it’s proven to be the most predictive of a candidate’s internal logic:

Tell me about a time when you changed your perspective on something important to you.

This one personal question addresses two meaningful and often static realities about a candidate’s approach to solving problems:

Are they capable of admitting they’re wrong, and, in the face of data and other evidence, making the rational choice to change their mind?
When making decisions, is their priority to support their own beliefs, or is it to identify the best solution?

We want the person who’s interested in getting the right answer, rather than proving that their first impulse is right.

Building a company of people who approach their work with the ethos of a scientist isn’t just easier. It’s also more enjoyable. It creates a culture where people willingly and patiently work through arguments and uncertainty with a curious mind, rather than a defensive attitude.

On the left is a blue checkmark. Below is the word "reason." On the right is a red 'X'. Below is the word "ego."

Focusing only on the important stuff has helped Tremendous make fewer hiring mistakes and attract incredible talent.

If you want to know more about how we run Tremendous, you can check out our employee handbook. And if our way of working sounds good to you, we’re hiring .