After conducting hundreds of interviews and building a team of over 100 software developers, LLInformatics founders Lukasz Lazewski and Mariusz Pikula have found that evaluating technical skills is a relatively small part of hiring – ensuring culture fit is more important, and you don’t need to be a tech expert to do that.

Knowing why is more important than knowing how

You may not understand the ins and outs of code, but as a founder, you still play a vital role in leading the entire team – tech or otherwise.

Being a leader means having a clear vision of where you want to reach and inspiring others to go there with you. Awareness of your technical limitations doesn’t make you a less competent leader; instead, it helps you set realistic expectations and trust your team’s expertise.

3 Tips for Building a Tech Team

Tip #1: Have a clear vision of the company culture you want to create

Your first employees will be the ones who will help you build the company culture you envision. That’s why you need to understand that vision clearly and then use it as a reference when interviewing.

Company culture might seem like an abstract marketing gimmick or an unimportant “nice-to-have”, but it’s actually a powerful tool to help you make difficult decisions.

For example, let’s say you’re evaluating two candidates for the same position:

• Candidate A has many years of experience in technologies tangential to the primary technology you’re looking for. However, they demonstrate great passion, ownership, and a willingness to learn. You see that they stay hungry and curious for more. They want to learn and grow as a part of the team. It’s less about “me” but more about “us”. Their past colleagues and bosses speak highly of them.
• Candidate B is very experienced and confident in the exact technology you’re looking for, with a strong portfolio of past projects, excellent experience and references, and a solid GitHub profile. However, they come across as a solo player and are driven solely by incentives (i.e., money and benefits).

Which should you choose? If you’re unclear on your company culture, it’s tough to decide. However, it gets much easier by establishing a few key characteristics you’re looking for.

For example, if your company culture values curiosity, ownership, and being a team player, you should choose Candidate A.

On the other hand, if your company culture is all about being competitive, working independently, and rewarding top performance, Candidate B would be a better choice.

Remember that you can’t have everything – you must make trade-offs.

Tip #2: Establish an interview process

Before you publish the job offer, be clear on how you want to conduct the hiring process. If all goes well, you will probably get dozens of candidates, so you must be disciplined and organised to go through them as quickly as possible while ensuring you don’t overlook any hidden gems.

We suggest these four steps:

1. CV review: Before committing to an interview, you should check each applicant’s experiences against the job requirements. Also, check and understand if they potentially fit elsewhere in the organisation – you might find people who would be great for another role. If the profile looks interesting, park them for a review in a different hiring flow. That’s how we’ve found some of our best colleagues, who have been with us for years.
2. First interview: Here, you will evaluate culture fit, background, soft skills, and general expectations (including salary). This step is mainly to get a feel of the candidate – you’d be surprised how often someone seems like a great fit on paper but shows several red flags during the conversation. That’s why we recommend doing this before the technical interview. At this point, asking a few simple questions about problem-solving and the candidate’s general attitude towards coding is a great practice, as this will help both sides to understand if that work culture is mutually understood and what they want to commit to.
3. Technical interview: Once you know which candidates might fit in, it’s time to evaluate their hard skills. If you’re not tech savvy, you will need help here. Try to find someone in your company or personal network who could help you evaluate who are the excellent coders. As your company grows, this will get easier. Each team in your organisation may have developed rules and parameters to assess the “right fit” and required tech skills. Also, as you participate in some of these interviews (just be present), you will get a feel for the candidate’s problem-solving attitude and approach to challenges.
4. Final interview: You might end up with a handful of promising candidates – that’s great! However, it’s not over yet. Now it’s time to discuss contract details, compensation, and exceptional circumstances.

Pro tip: it’s better to avoid sending them a task. Instead, ask the candidate to walk you through past projects and how they solved complex problems. Also, ask them what they could have done differently. These questions will show you their thought processes, the depth of their knowledge, and how self-aware they are of their strengths and where they need to improve.

Very important: after each step, inform the candidates as soon as possible whether they have moved forward. It doesn’t have to be a long message, and you don’t have to explain the decision if you don’t want to – just be respectful and straightforward.

Tip #3: Look beyond the years of experience

Seniority does not descend automatically from the heavens after reaching a certain number of years of experience. Many very experienced coders lack the traits of a senior developer, such as the desire to share knowledge, the ability and willingness to help and coach more junior colleagues, a strategic vision of what should be done and why, rather than just knowing how to do it, displaying a high level of ownership, and staying up to date with recent developments in their fields.

In fact, “seniority” means two things in parallel: experience working in a given tech stack (e.g. JavaScript, Ruby on Rails) and maturity level as a professional. The second aspect, although often overlooked, is the one which poses the most significant risk to the stability of collaboration.

Developers should understand that 90% of their time will not be spent building exciting new features but rather finding issues and adjusting existing code. Even in early-stage startups, it’s just a matter of time until change requests come in and start moving things around. That’s why it’s great to know you have people who are not emotional about it, who won’t feel attached to their feature or piece of code – that’s what we consider “true seniority”.

Hiring developers shouldn’t be just a matter of evaluating technical abilities – remember that even ChatGPT can pump out code nowadays.

You should not base your hiring decisions only on “hard skills”, especially in early-stage startups – you are selecting people who will undoubtedly go through some challenging situations and decision-making with you. Therefore, for each role, you need to evaluate if that is the person that you would like to have by your side in such cases.

Tech skill is just a toolset. You might go through multiple pivots, and technologies will change, but your team’s mindset and maturity will always be there.