Introduction

If we analyse a software industry and companies in it, we can distinguish two main types of companies: service-based companies and product based companies.

The first one – service-based – does not provide any service or product directly to end users. They work for customers who do. They could be further divided into two subcategories: outsourcing companies and agencies.

A second main category could be product-based companies. These in turn provide a value to end users. Either directly via software they produce (SaaS companies) or indirectly (software teams support the goals of the business).

Depending on the company type we’re hiring for we may seek different things. In this post I would like to show how the tech interview may look like in different company types.

Tech interviews for service based companies

As mentioned earlier we may split service-based companies into two subcategories. So let’s have a closer look at both of them:

Outsourcing companies

In places like these a candidate may be considered for multiple projects. Operation departments have really difficult jobs here and shuffling engineers between clients may be complex at times. The reason why this flux of developers happens may be for example because people want to learn something new and try out a different environment, or simply the contract has ended and the company needs to find new work for the employees.

This dynamic also has some effect on the hiring process. During the interviews the candidate may be already considered for different clients with a distinct culture or tech stack. That means that firstly, there may be no need for super rigorous culture fit check. All in all the interviewee is going to work for the end customer, so they should fit into their culture. We may however try to sense if the candidate would be a good team-player.

Secondly, it’s hard to determine the ultimate tech stack so there’s no point in checking very specific tools – it’s more important that the person knows the fundamentals and has the ability to learn and adapt quickly.

One thing that can make the hiring process more efficient and consistent is to create a hiring framework within a company. It could be achieved for example by defining what certain experience levels mean – e.g. “what does it mean to be a senior developer”. The well-defined frames for the levels may help recruiters to make their decision, and for the business departments of the company it may give some ideas how to calculate the rate for the developer.

I wrote a separate article that focuses on how to design an interview for a software house.

Agencies

The second subcategory of service-based companies are agencies. They provide more end-to-end services for their clients like for instance development of the custom e-commerce platform. There could be two main types of the projects: those that have an end and those that are ongoing.

In the first case, the faster the company finishes the project, the more money they get.
In the second case, it’s important to maintain a long relationship with a customer to have a constant flow of money. That means the less disruptions in the project, the better.

No matter which case we consider, it boils down to a good knowledge of tools and processes. In fixed-price projects, expertise in certain areas allows developers to move faster and more confidently. In the on-going projects, a consistent toolset in the company lets the company easily replace people when they decide to move on.

What does it mean for the hiring process? We may spend more time verifying specific tools. We can of course see how eager to learn new things the candidate is, but this also means more risk for the company to hire the person and teach them the tools they use. It depends on the context obviously.

Also, the team fit matters more. In both scenarios people are going to work together for longer periods – on different projects that start and end, or on long-lived ones.

Tech interviews for product-based companies

The second main category of companies are product based companies. They develop products for the end customers. Usually there’s some vision and mission behind the product so in this case it also matters to verify the team fit and if the candidate understands the company mission. If the company is a dynamic start-up that works towards some noble goals like education or ecology, it may not be the perfect place for people who value good engineering and well-designed processes. And the opposite – engineers who would like to have a strong effect on the product they work on may feel uncomfortable in big, structured enterprises.

The fact that the company grows their own product gives also an opportunity for the recruiter to check other strengths of the candidate. Maybe the interviewee isn’t the best in the JavaScript fundamentals but has strong inclination to the product work and could support the team with great ideas.

👉 Giving the candidate a chance to shine in other fields is always a good idea. I wrote about this in my other post about advice for technical recruiters

One thing that we, as recruiters should have in mind is to keep an open mind for the candidates’ ideas. The fact that some solution works in our company doesn’t necessarily mean that this is the right approach. Maybe the candidate has some other experience and can even suggest something more efficient for a given problem.

Because the company grows their own product for many years, depending on the industry, the interview process may also verify the candidate’s domain knowledge. For example, being an expert in Java may not be enough, the job offer may also require experience in the finance industry etc.

Conclusion

There are a couple of software company types. Depending on which type our company represents, we may tackle the technical interview process differently.

  • In case of the service-based companies that offer outsourcing, the crucial thing is to have versatile candidates with strong fundamental knowledge and ability to adapt to a new environment.
  • The service-based agencies may verify the candidate’s knowledge of certain tools which could help the company deliver projects faster.
  • The product-based companies may look for the culture fit, check if the candidate follows the vision and mission, and also potentially check the candidate’s domain knowledge.

References

Author

I'm a software engineer with 9 years of experience. I highly value team work and focus a lot on knowledge sharing aspects within teams. I also support companies with technical interview process. On top of that I read psychological books in my spare time and find other people fascinating.