It is relatively simple to define values for a company, but translating them into concrete behaviors in everyday situations is a much more complex task. Often, this is because these values remain too abstract, too theoretical. As a result, we expect overly predictable behaviors, as if our biases or lack of imagination prevent us from seeing things differently. These examples are sometimes too general, sometimes too specific.

For example, when we think of resilience, we often imagine a patient lying in a hospital bed, fighting for his life — this is an example that’s too general. Applied to a developer, it translates to the image of someone who doesn’t get discouraged by a compilation error or a bug in an open-source library — this is an example that’s too specific. These are clichés, yet we still look for them during interviews. Sometimes, we even dedicate an entire interview to values, which can lead to equally clichéd questions (“Tell me about the last time you faced something hard”). The risk is that candidates trained in storytelling will ace your interview, while those who are more introverted or shy, or who have different life experiences, struggle to express their own interpretation of these values.

So, how can we embody these values more authentically? In my opinion, it starts with visualizing them in everyday situations. What does it really mean to be resilient? Don’t give me the example of the developer overcoming a critical bug, because that’s still a cliché and something that is hard to perceive in daily work. Moreover, some values are harder to visualize for certain roles, especially when they fall outside your area of expertise.

At Tandem, as at MadKudu before, we place a lot of importance on being a “doer”. But again, what does it really mean to be a doer? Everyone claims to be a “doer” nowadays, especially since the tech sector’s recession has pushed companies to rediscover this original hacker spirit, whether real or imagined. And everyone considers themselves a doer. A developer might consider themselves a “doer” for having once taken the initiative to install a new NPM library. A marketer might think the same for having set up a Zapier flow to automate a process. Once again, the examples are countless and so varied that it can be difficult to form a clear and embodied idea of what a “doer” is, and even more so to evaluate this value in a candidate or employee.

In response to this, I looked for a simple and universal test, applicable to all positions, and concrete enough to become trivial, almost insignificant, yet still revealing: if the office coffee machine broke down, how would the candidate react? Would they try to fix it, or would they wait for the office manager or the founder to do it instead? This test has the advantage of being adaptable to all organizations, from a startup that has clogged its Nespresso machine with cheap capsules to a scale-up with an expensive percolator that no one understands how to use. It transcends roles and cultures: it’s not about expecting the person to know how to fix it, but about seeing if they take the initiative to do so.

When I reflect on some of the hiring mistakes I’ve made in the past, I realize I could have avoided them by asking myself this simple question, rather than looking for theoretical evidence of a “doer” mindset in past experiences. This is not a foolproof test, but the people I have in mind, albeit great engineers, would never have lifted a finger to repair our tiny but cherished Nespresso machine.

In short, your values must be represented in a tangible way, visualized in concrete situations. Keep it simple. Embrace the trivial. Avoid corporate clichés, and you may find better ways to evaluate your candidates. Why not start by observing how they would react to a broken coffee machine?