How to hire developers as a non-technical founder
Today, when everyone wants to launch their startup, we’ve seen some of them thriving without the technical co-founders. The examples of Ben Silbermann from Pinterest and Kathryn Minshew from the Muse prove that the lack of tech expertise is not an obstacle.
If you’re a non-technical founder striving to build a successful startup too, you may have realized the result depends greatly on your ability to hire a top-tier technical team. In this case, hiring a CTO, or asking any of your acquainted seasoned developers to help you vet the real professionals would be just the thing.
But hiring a CTO is not a walk in the park. It may take from 90 to 120 days to find and hire a suitable candidate, and even more time to onboard him. Looks like a challenge hard to surmount? No problem, we’ve got you covered!
In the article, we will share the questions you should be asking in the interview together with the good and the bad answers you’re most likely to receive.
What to do before an interview
Steer clear from Google when looking for tech concepts to discuss. In fact, it’s better to avoid going deep into tech, as you’ll either understand nothing in the answer, or get some standard info from Google, which will also be of little value for a non-techie.
Pay attention to how a developer answers technical questions. It’ s better look for someone who is able to explain technical concepts in a clear and simple way. It doesn’t only show the candidate's proficiency, but proves his empathy and ability to efficiently communicate with a non-technical person as well.
Prepare a standard list of questions. As soon as you find out particular skills needed to get the job done, map them out to the list of questions you will be asking each candidate. That will help you avoid bias and easily compare which candidate better fits the job.
Keeping this info in mind, you may come over to the interview, which should consist of 2 parts: candidate’s background experience and his technical expertise. Let’s see them in detail.
Discussing background experience
Here are the questions you absolutely should be asking, when discussing a candidate’s previous projects:
1. “Tell me about your most and least favorite projects. What did you like/dislike about them, and why?”
When the candidate starts complaining that the project was too complex and time-consuming, this is definitely a bad sign warning about the candidate’s low motivation and, possibly, irresponsibleness. Or he may throw something like “I knew the project far and wide, there was nothing unfamiliar to me”, which is no good either. It may hide the candidate’s unwillingness to learn and bring in some new techniques for the project’s good.
Finally, if the candidate speaks too much about the business side of the project, you may ask yourself “Is he showing deep domain understanding, or trying to hide technical knowledge gaps?”. To find out for sure, you might ask a couple more questions on both the technical and the domain aspects.
If the candidate admits that the project was challenging but interesting, this shows him as a motivated and enthusiastic person. It’s also good if he starts dwelling more on the technical aspects, and entrusting the business side to project managers and business analysts. However, it’s also worth checking the candidate’s communication skills. You need to make sure that the deep technical expertise doesn’t go hand in hand with his inability to act as a team, or reluctance to code with a view to the client’s needs and domain best practices.
Constructive criticism of the project is also welcome, if it’s backed by strong arguments and adequate reasons.
2. “What do you do for technical problem-solving?/How did you solve the problems that arose at your projects?”
If you ask about the problems a candidate solved at his projects but get no concrete examples of issues, what technical aspects they implied, and what exactly he did to curb the issues in response… Well, that’s not the developer worth hiring.
Hearing the word “decomposition” first is one of the best options possible. Still, not mentioning it explicitly doesn’t mark the candidate as unprofessional. A seasoned developer will tell you about performing the root-cause analysis, identifying dependencies, prioritizing tasks for problem-solving (not necessarily in this very order), seeing to the due timing and efficiency as well.
3. “How do you see your career development?”
When the candidate has no idea of his future professional growth, or doesn’t seem to be very enthusiastic about it, it’s not a good sign. But the other extreme, inadequate ambitiousness, is even worse. It can manifest in the desire to become a lead in, say, half a year, for no obvious reason, or get a promotion and substantial pay raise right after the probation period. You obviously don’t want a rock-star with a star fever on your team, do you?
The candidate has a clear understanding of his career development opportunities and realizes what competencies, qualifications, and certificates will be necessary for that. The passion for continuous learning and development gives points to any engineer, regardless of his competencies and seniority level. Still, the rush for certificates and shiny-new technologies sometimes mean denial of the projects that lie beyond a candidate’s professional interest. For instance, we interviewed an experienced and certified candidate who worked with the latest version of Angular and labelled other versions as outdated and uninteresting to him, which made his certifications and experience non-applicable for our company.
On the contrary, it doesn’t necessarily mean that a candidate is unprofessional, or it’s hard for him to tell about his future perspectives. He may just be an introvert who needs to be asked more leading questions like “How would you prefer to grow in your domain or tech stack?”, “Are you satisfied with the complexity of tasks you have?”.
4. “How do you organize and manage your working process? How do you believe the project work should be managed in its organizational, technical, and infrastructure aspects? ”
Saying that the working process is solely the project manager’s duty would be definitely a mistake. An experienced developer is always a self-starter, who manages time effectively and doesn’t need excessive supervision. Mentioning that one methodology is better than the others also indicates the lack of experience and bias, as any methodology can be beneficial for a certain project, and utterly inefficient for another one.
Ongoing communication with the team, the automation of any tasks that can be automated, proactive approach and regular code review for spotting defects as early as possible – this is what you want to hear. Mentioning regular exchange of code and peer reviews done by the developers is also an advantage. Finally, adherence to Continuous integration and deployment (CI&CD) practices allowing to make the delivery more efficient and cost-effective, shows that the candidate’s a real pro.
5. “What’s your approach to picking technologies and tools for the project?”
A candidate may say that this is not what he does, or believes he should do, as there are usually existing technologies and a pre-defined tool set for any project - and will be wrong. Even when the majority of technical solutions is determined, there’s always a room for improvement and suggestions of experienced engineers are highly-valued. Such an answer may also presume that the candidate lacks the interest in professional development, or is afraid of new things, which will result in outdated working approaches.
It’s great if a candidate mentions the quality of official documentation for the development frameworks, libraries, approaches, and tools, the availability of relevant online resources (e.g. Stack Overflow), information articles and forums. Saying about a strong development community that helps to address any issue even for an emerging technology (e.g., Flutter) is also a good point.
Switching to the tech side
And here are some technical points you’ll have to touch anyway:
1.“What do you like about a particular technology?”
Saying that he likes a technology because it’s popular, easy to master, or is high on software development technologies rankings shows that the candidate likes to cut corners, or simply lacks engineering experience. Both are equally undesirable.
The candidate should appeal to the technology’s usefulness for certain business goals (e.g.,efficient business process automation and optimization, cost-effectiveness, etc.) and proven efficiency for varied technical tasks (e.g., web/mobile development). Providing examples from prior development experience to support his viewpoint is also valuable.
2. “Please name the latest version of Python, Java (any other programming language or technology you’re discussing)? How does it differ from the previous version, what’s particularly new and useful about it?”
Naming the non-final version of the requested technology and being unable to enumerate its enhancements and advantages in comparison with the previous one looks like an epic fail. Especially for the startup projects. But note that the latest version could be released a month ago, and the candidate might have missed the updates because of his busy schedule. Still, if the release was half a year ago, or more, and the candidate isn’t up on it, it’s a warning sign.
A developer who knows Java, Python, C++, or any other programming language keeps track of the latest technology updates in his domain. Thus, he KNOWS the latest version and its peculiarities, understands the general trends and novelties and he will give you the only correct answer. If a developer doesn’t keep pace with rapid technology changes, it paves the way to critical security, compliance, and performance issues, and poses a threat to your business.
3. “Please compare technology A and technology B. How is one better than the other?”
Praising one technology over the other because of its popularity, easiness of learning, and developer’s ample expertise marks the unprofessional and biased approach. Not your bro.
Feelings aside, a good answer here is a well-grounded one. The technology can be labeled as superior due to its higher efficiency for the same scope of tasks, applicability for various development use-cases (e.g., web, data analytics, etc.), and not the ease-of-use or the developer’s personal preferences.
An extra tip
Deciding on the needed skill set and asking the right questions are a bare minimum for building your dream technical team. If you want to go further and make your team more diverse by different technology stacks, or people from various cultural backgrounds, you may start with blind screening and blind pre-hire testing. Thus, you won’t only set up an unbiased and effective hiring process, but will assemble a diverse team that will be smarter and more innovative as well.
Remember you always have a secret weapon: instead of spending a half of the year in the search for a CTO, you can hire an interim CTO/VP of engineering. CTO as a service implies having a part-time CTO helping to elaborate a project roadmap and timelines, perform budget estimates, provide expert advice on best-suited development tools, and carry out technical interviews.
What iTechArt has to say
Since iTechArt has worked on a number of successful projects for startups with non-technical co-founders, (for example, Voxy and Bevi), we know how to avert the potential problems a startup may face due to the lack of tech guidance and help our clients advance.
We’re also supporting the strive of non-technical people to contribute to the community well-being with the technical startups they launch. So, we’ve set up CTO as a service offering to help aspiring companies cover the lack of technical leadership, support businesses towards the next growth stage, and guide them from the product’s idea to a top-notch team that creates a working solution.