The third and final interview in our interview process is a technical interview. However, as you have read, the interview is to give you a glimpse into how we work together more than it is to evaluate your deep technical skills. Knowing some ruby won't hurt, but it isn't a must to have a really successful meeting.

Oh yeah, and congratulations as you've already proven yourself as a great candidate at this point. Let's work together to focus on fit, working style and your ability to get your hands dirty!

The Process

Our technical interview will work through a specific problem using a pair programming approach. Below you will see an example we've used before. The idea is really to give both parties a chance to understand a problem, explore possible solutions and try to implement as much as possible in 45 minutes.

Understanding the problem is always an important step as it can be hard and has a major impact on how the solution will evolve. When moving too quickly, we can frequently find ourselves solving the wrong problem. However, fixating on perfection in understanding the problem also leads to missed opportunities as the world (and our client) can happily move on without us!

Exploring solutions is the fun part but also requires discipline as we don't want to jump on the first thing that comes to mind. Talk through a couple of different approaches and find the one that "feels the best" given the existing context, time available and importance of the problem.

Lastly, turning a solution into beautiful pseudo code (or ruby) is a great way to solidify thinking and ensure that the leading solution works well in practice. Pseudo code with comments is a nice way to start. Some amount of ruby to follow is ideal (the language was built for developer happiness after all).

An Example

Here is an example that we have used during a technical interview:

The interview will consist of a ruby focused exercise surrounding the Matey project, a gem built to bring user metrics to light through View Components. During the interview any number of collaboration methods can be used from Google Docs, Meet, or VS Code LiveShare.

The basis of the work to be done is generally provided via an existing issue. For example, this issue has been used several times in interviews: During the interview, the following link was shared with the candidate and matey issue 44.

Our Tooling

The following are not absolutely necessary, but do make the process much more realistic. Not only do we love using the following toolchain, but we find it helps give the candidate an accurate view of what we do every day.

Note: It isn't essential to have the following software installed. We're entrpreneurial and can find a way to work together if you aren't able to get things running. If you have a stack you prefer, we'd be happy to give it a try and to learn from you!

• Visual Studio Code installed and configured with your favourite theme.
• Live Share extension added and some degree of confidence it would work. We can fallback to a Google Meet if necessary.
• Harled OSS a very basic level of understanding of our OSS packages with a focus on matey.
• Eagerness to learn through the entire process. You'll see that we are happy to learn from you.

What We Look For

What we look for is really simple. It should also be the same thing you are looking for! That is, an excitement to work together, to grow together, to evolve a culture and ultimately a passion to really move the needle on the world!

"You'll see that we are happy to learn from you."

Just as much as we'll be assessing fit, we'll be looking for signs that you are doing the same. We want to know that you're thinking about your best work environment and if it is aligned with the type of work that we do and the approach that we use.

When working through the problem, we'll be watching to see:

• how you think about problems and mostly how you explain your thought process and collaborate with another team member to ensure a solid Understanding
• how you think the effort should be time boxed given your understanding or experience in the problem space

When ideating solutions, we'll be watching to see

• what approach do you take when creative thinking
• how big or small do you go on your variations and what is your "silly" (or we're done) threshold?
• how deep you go into any possible solution for validating or invalidating it.

By the way, there isn't a right or wrong for any of these.

Lastly, when working on pseudo code and real code, we'll be watching to see:

• how you take into account existing code, design patterns and style when formulating a solution
• how you use resources to look for help and how you function in a pair programming session
• how you make suggestions while we're driving!

Our technical interviews aren't scary, they are just a tool for both of us to see if we're a match! If you like what you've read, and you're ready to be a big fish in a small pond then please checkout our open positions!