At Forward Financing, we are always trying to improve how we work. We have some core tenets to how we work as a team. Our director of engineering, Patrick Hereford, wrote a great post about that recently. You should check it out here
We are growing the engineering team here, in a push that will eventually more than double the size of our group. This growth is key to support all of the new work coming our way, marking an increased investment in tech here at Forward Financing. These positions are for different levels of engineers and for both local and remote team members. This is a very exciting time for us, but how successful we are may ultimately depend on who we hire.
We care about finding team members interested in joining a blameless culture rooted in learning. We do this mainly with code review and pairing. There are lots of great engineers out there, all with their own styles and preferred ways of working in a team. We want to focus on finding team members who will strengthen the values we have in place and bring in different points of view.
We talked a lot about how we might tailor an interview solution that fits our team, and we came together on pair programming. We do not practice strict formal pairing here as a whole, but we really like to collaborate, especially on large features. It is common for each person to either hop on a call with another engineer about a challenge, an idea, or to talk over code review. Being able to communicate well with any new person is key.
In the end we set up a process for pairing with a candidate who could be done in about an hour and had both a backend and frontend section (we are a full-stack team). We choose to go with a three-person call, one teammate leading the frontend, and another teammate to lead the backend portion. This works out well for us because then two engineers get to talk to the candidate, and the candidate also gets to ask questions and see how we work with each other.
The idea is to give a small window into how we work, while also getting an idea about how the candidate might fit. Our setup is based on our own codebases, with a few features removed. This worked for us because it is nice to see a candidate work with code that is based on our actual codebase, and also makes it simpler for us to guide a candidate.
Once we start the exercise with the candidate, the main point is to have them be the ones driving the solutions and communicating with us about what they are thinking. We try to make it clear that we want to see how they work. We stress that it is not a test. We are completely happy with talking it out, looking at docs for syntax and pseudo-coding solutions as a first pass.
Also, it is great to hear about optimizations the candidate might make, or what they may change with more time to complete. This lets us get a sense for a person’s personality, disposition and problem-solving style. I am enjoying getting a chance to talk to so many engineers and to see how they communicate. All in all, the goal is to make it as painless for the candidates as possible while giving us all the chance to get to know each other.
This is an energy-intensive process for us for sure, but so far, the opportunity to meet people and showing where they may fit in with the team has been a really a good investment for us. The team is growing, and it feels like we are growing in all the right ways.