The past (somewhat, if you are careful) predicts the future
TL;DR: People are unlikely to make swift changes to their core behaviors. By detecting what they care about now, you will get an accurate estimation of their near future behavior. That helps you answer the second question you need to ask during an interview: «Can I work with you?»
The previous behaviors will likely continue to manifest themselves. That is one of the natural qualities of us humans. Like Newtonian objects, we stay in motion when we are in motion and lay at rest when we are already at rest. To change that, we have to exert a massive force and consciously apply it. If we do it for a long enough time, new behaviors set in and become habits. But without that effort, we usually continue being who we are. Perfectionists will continue chasing the ideal state and delaying project deliveries. Cowboys will continue YOLOing untested solutions to production. In other words, the matters people care about now are likely to govern their future behaviors.
That quality is both a challenge and a trait, depending on how you look at it. If you want to change those behaviors in yourself, that is a challenge. If you need to understand how a person would behave in a given context, that is a valuable trait. And you can and should use this trait as a tool to learn more about your candidates.
In our previous post, we introduced a framework for hiring software engineers. It consists of three questions that you need to get sincere answers to:
- Can the candidate do the work?
- Can I work with you?
- Does the candidate want to work with me?
The best way to answer the first question is to let them do some actual work. To answer the second one, assess their current behaviors and map them to your company culture. This post explains in detail how to perform such an assessment.
Can I work with you?
To answer this question, all you need to do is compare a candidate behavior to your company culture.
Let us illustrate what we mean with a concrete case. At AutoIterative, we have already pulled all the hard work of defining what our culture is. For example, one of our core values at AutoIterative is «to do science instead of cargo-culting.» That means that we always want to understand why we do what we do. Whether ideas are ours or not, we are comfortable questioning and challenging them. So how do we determine where the candidate stands in that regard? Could we ask straight whether they are confident with challenging their ideas? Sure, but that will not give us a rigorous assessment. Chances are, the answer would be: «yes, of course, I am!» We do not want to measure wishful thinking or imagination. The better question would be to ask a candidate about the last time they had their ideas challenged. From their answers, we can derive a more reliable estimation of their behavior.
Let us show how a typical conversation could unroll (along with our notes explaining why do we ask what we ask):
Interviewer: Tell me about a recent case when someone challenged an idea that you introduced?
Candidate: Once, I pushed for the idea of adding monitoring to our service. It was roughly a year ago, and I got a lot of pushback from my team.
Notes: The answer hints that the candidate cares about monitoring and metrics. It is also helpful for analysis: it tells us how long ago that happened, it is relevant, and it presents a situation. It is worth investigating in-depth, so we decide to continue exploring it.
Interviewer: Interesting, what happened? What was the pushback? (Note that we are using an open-ended question here. We do not want our biases to influence their answers.)
Candidate: Well, we were having issues in production at that moment. We were spending a lot of time reading logs, trying to understand what was happening. Also, we were under pressure to deliver a new feature. That could be the reason why people were not really receptive to my idea when I proposed it. One of the engineers said that we have no time for it now.
Notes: The answer sheds even more light on the situation. First, it reveals that the team was under pressure (a data point on how the candidate might perform in such circumstances). Second, it shows that the candidate wanted to improve the situation by investing in observability (this is great for us!). It also tells us there was a conflict (a data point on how the candidate might defuse them). Now we should dig into those individual aspects.
Interviewer: Why did you want to add metrics? (asking why will force the candidate to explain their reasoning. That defines the task they had to do at the moment.)
Candidate: Because reading logs is not the same as having metrics that you can query. Some visibility would have improved the situation. I just wanted to understand the problem, fix it and prevent us from getting into it in the future. We had to start somewhere, and having those metrics would have provided a lot of value.
Notes: This candidate demonstrates that they care about the runtime (a valuable trait for us!). They opt to invest a bit today for a better future (again, aligned with our values). If they care about those things in our company, we would be happy to work with them. Now, let us dig into the conflict bit.
Interviewer: Interesting, and how did you handle the situation of your coworker saying a flat-out «no» to your idea? (Note that here we exaggerate a bit what the candidate said. Will they correct our impression? Will they confirm it and elaborate more on how they saw the situation?)
Candidate: I did not reply at the exact time they said no. I did not want to provoke a conflict in front of everyone during a standup meeting. It was not the first time I got a pushback either. But we were all suffering, and I thought it was critical to add metrics to our system to help us out of the situation. So after the meeting, I approached my manager and explained the value we will get if we have metrics. I asked for help pushing this forward.
Notes: yes, this was an open conflict, and we need to drive the questions to the resolution.
Interviewer: And what happened? How did you present the idea to your manager? (Note the open-ended question again. It pushes the candidate to explain how they behaved, allowing us to derive the why behind that.)
Candidate: I explained that we were drowning in operational work and that we were blind. I learned in the SRE book that measuring requests and latencies is one of the first steps to do. (Note: this could be cargo-culting. Let us make a note, so we can later dig into their reasoning.) I thought it made sense to try it. I told my manager that I was ready to take ownership of the whole process. Initially, I just wanted to add a couple of metrics as a proof of concept and see if that improved our situation. If it did, we would spend less time debugging and more time working on features. He liked the idea, and we started working on a plan to communicate to our team that I would start working on it.
Notes: From their answers, we already have a clear definition of the action that the candidate took. But there are more data points about the candidate. They think about the team’s success (time spent working on a product instead of debugging). They built a proof-of-concept to validate the idea before proposing a full solution. They approached the manager asking for help instead of openly arguing back. This behavior could hint at them being context-aware and a team-player. They understood that the whole team is under stress caused by the pressure to deliver.
The natural next step would be to push for closure and ask how the situation ended. If you need more context, you can continue asking open-ended questions. You will discover more details and get a more refined picture of a candidate’s behavior. You can ask what the candidate learned from the situation and what conclusions they drew from it. But let us wrap up the example here.
The conclusion
As many of you probably realized, this is an interpretation of STAR/SOARA techniques. The question explicitly asks for a story from the past, not for an imaginary scenario. How a candidate replies to such an interview will yield a lot of information and map to a behavior. Their answer will tell a story, and their narrative will highlight what they value. From that, we would see what their natural tendencies will be. And if you did your introspection and know what your behaviors are, then comparing those two will answer whether you can work together.
Note, however, that those techniques are not a silver bullet either. They will not give you a 100% precise picture of a candidate out of a limited interview time. No method will do that for you. But when applied correctly, they raise your accuracy way above just the feelings. Focus on understanding and thoroughly defining your culture. That will give you the exact dimensions along which to measure your candidates. That, in turn, will provide a set of values to assess. From them, you get an understanding of which questions are efficient for you and which are not. Practice using the best ones, and you will answer the second question with ease and precision.
Meanwhile, the AutoIterative platform will assess the candidate’s ability to do the work.
… and, of course, The Marketing Pitch™
We solved the problem of software developer technical assessment. You no longer need to resort to obscure rituals or torture them with the «Can you reverse a linked list on a whiteboard?» (true story™) type of questions. You no longer have to *guess whether the candidate can deliver something that works. With the AutoIterative Production Challenges™, you can instead just test that. And you can do it without investing a single engineering hour before you know the answer.
Launch your free demo and start technical assessments within seconds.
Try the free, fully functional demo of the Autoiterative platform.
