One key set of decisions made while building a company centers on hiring. Apart from the product, this is the most important part of building a successful company. In this essay, I explore some of the decisions we’ve made about our hiring strategy at Rhinestone, explain my thoughts on the interview process and decision making framework and end with the biggest learnings I’ve made to date.

experience

One core pillar of our hiring strategy is exclusively hiring experienced people. This allows team members to start contributing as soon as they join and use past experience to help guide future decisions. This further builds a foundation of trust that allows every team member to have a large amount of autonomy in their work.

Many startups I know hire young, inexperienced people for several reasons: cost, ease of finding them and the potential of upskilling them to become superstars. However, at this point in the company, we have decided to not take on the risk of bringing on unproven people despite these upsides. The main reason for that is startups are hard and any specific one is highly likely to fail. That means that founders need to stack all the odds they possibly can in their favour. If a candidate worsens the odds of success because their performance is uncertain (maybe they will be a superstar in 6 months, maybe they won’t) then this is a risk that needs to be carefully assessed. Further, when you start to grow you can’t micromanage everything (and even if it was possible you’d be restricting yourself to the ideas you have and decisions you can make). Therefore, you need team members to be autonomous and trust them to be able to make the right decisions in the vast majority of cases and the ability to make great decisions is highly correlated with relevant experience.

trials

The second pillar of our hiring strategy are paid trials. Popularised by Linear, the idea of trials is that instead of testing developers with take-home tasks or live-coding sessions, we get them to join the team for a short period of time. The benefits go both ways: we get to have a glimpse into how the candidate works, but also how they perform beyond their hard skills, such as their interest in the product, their contributions to brainstorms and their interactions with the team. The candidate gets to see what it’s really like to be part of the team and work on projects that we are actually working on.

The downsides of trials is that they are expensive and time consuming. We need to find the time where a candidate is free (ideally for 3 days), allocate time internally to actually handle the trial, figure out what the candidate will work on, spend time with them and review their work. Frequently, we have to run these trials partially on weekends and we don’t usually run trials at the same time, so if we have 4 candidates to put through trials that could take anywhere from 2-4 weeks.

Overall, the reception to trials has been really positive, from hires and candidates we rejected alike, and the value we’ve gotten out of them has proven substantive. My decisions feel a lot more thought-out and backed by substantial data, both on a candidate’s hard and soft skills. However, one learning is that having too many people go through trials but not get to the offer stage becomes expensive very quickly. As a result, we are focused on only going to trial with candidates that we are highly likely to make an offer to and not see them as just another filter like interviews.

testing intelligence

During an interview, one of the core things that I aim to assess is a candidate's intelligence. In my opinion, the best proxy for this is their reasoning abilities. Generally, this means asking candidates about problems they are somewhat familiar with and getting them to reach beyond their current knowledge or think outside the box. Hence, I need to tailor my interview questions to what I think the candidate’s level of knowledge is and see what happens if I push further.

good vs great

The second main question I aim to answer in an interview is if a candidate is good or great. The most important proxy for this is whether they deeply understand something or whether their knowledge is only surface level. If a candidate not only understands how something works, but why it works a certain way and what the tradeoffs are, then they are far more likely to make good architectural decisions and generally understand systems deeply. To figure this out, I usually push candidates to explain why things are the way they are or work the way they do and get them to guess at questions they don’t know the answer to.

assessment

My general attitude in an interview is that by default it’s a “no”. At any point during the interview, though, I ask myself what I would need to hear to start turning that into a “yes”. I think this mindset is beneficial because it gets me to continuously evaluate how a candidate is doing and dive deeper into their weaknesses. On top of that, it allows me to be confident that when I accept a candidate, they exceeded my expectations rather than just not being bad enough to be rejected.

decision making

Our decision making follows the idea of “hell yes or no”. This means that if there is not at least one champion of a candidate for whom they are a “hell yes”, we reject the candidate. It happens frequently that all interviewers are a lukewarm “yes”, in which case we don’t proceed with a candidate. This filters out people that we think are good but don’t surpass the bar and that we don’t think raise the bar of the team overall. Further, a candidate usually can only be a “hell yes” if I am excited to work with them not only on a professional but also a personal level, adding another important data point into the decision making framework.

hiring doesn’t stop at the offer

One of the most important learnings I’ve made over the last two years is that the hiring process doesn’t stop at the offer stage. Instead, it’s important to know that any decision process will make mistakes and probably quite a lot of them. So just because a candidate has passed the hiring process, doesn’t mean that they are actually a right fit for the company. Instead, probation should be seen just like another interview, during which the performance of a candidate is continually assessed and if they don’t meet expectations, then we will let them go.

intuition

Probably the most important learning I’ve made (which also pertains to decisions outside of the company) is to follow my intuition as quickly as I can. In the hiring process, this means that as soon as I think something is wrong I will act on it. Most commonly, I will feel like a candidate that has joined the team is not the right fit and as soon as that intuition arises I will work on assessing that further. Generally, this means giving feedback to the candidate and bringing it up with the team as a first step. We might give specific feedback to a candidate and see if they improve within a week or two. If they don’t improve, we will usually let them go after that week or two.

The hard thing about this is trusting your intuition even when the decision is made under a lot of uncertainty. Almost always, there is no right decision, but only tradeoffs and it is easy to imagine any possible course of action leading to a mistake. For example, when I see a candidate underperforming, I might think that they will improve if we give them a little more feedback and time. But I believe the hard and right thing to do is to take one’s intuition seriously and trust it to yield the best decision.

a- players

The final major learning I’ve made is that A- players can be far more destructive to a team than B or C players. The reason for this is that they are much harder to spot and can thus go undetected for longer, dragging down the team overall. The reason for this is that A- players (unlike B or C players) get their work done, they just require additional hand-holding, more time or create hidden problems. I’ve found that A players are usually quite good at picking up these signals and are quick to get discouraged by A- players. They will start to feel like they are not learning and progressing, but they might also feel that the A- player is dragging down their own performance and opportunities in the team if their work depends on the A- player. Realising someone is an A- player is hard, but even after that the situation can be quite difficult for founders. This is because they do get their work done on paper, so both sticking to one’s decision and giving feedback can be tougher than with team members that underperform far more. However, when you let go of the A- players, the team performance will increase drastically, because it creates an environment where people trust each others skills and want to improve to match the levels of everyone else on the team.