Finding great developers with both technical and personal skills isn't easy. It actually tends to be a difficult task, that will only get more difficult over time. Tech companies have an advantage since they already employ tech workers who can interview candidates and evaluate them. Non-tech people who run a business do not have this capability.

Considering even tech companies face barriers in finding good developers, how can business people without tech knowledge do it? Even though it's a super difficult task, it's not impossible.

Before we start, let's assume you are a business owner of your own startup, have limited technical background, and are planning to build software on which your business will be based. With that in mind, first you have to define what kind of people you are looking for. Then we will see how to conduct an interview.

Defining the desired skills of a developer

This is a super important step and if you miss it you could easily be lost on how to find and interview candidates and the odds you will hire the wrong person are quite high. When looking for candidates, you can distinguish between two equally important but different skills: personal and technical. Missing either might ruin your startup from the beginning. Let's define them.

A person you need

N1. Nice and polite person

Working with an impolite person is not pleasurable at all and could make your communication very difficult and stressful.

N2. A person who understands you

A software developer who can look through the business's glasses is a BINGO, since he/she understands you and your needs. Many developers only pay attention to technology and disregard the business.

N3. A person who knows what he/she is doing (a professional)

An experienced freelance developer that knows how to build software and knows the process.

N4. A person who is interested in a product you want to build

A person who only needs a job, usually wouldn't care about your product and wouldn't try to understand the purpose of it. This leads to poorly developed software.

A person you don't need

D1. A person who cannot clearly express him or herself

Lack of communication definitely leads to bad software. There is a strong correlation between communication and the quality of software.

D2. A desperate person looking for a job

Usually leads to a failure and as soon as a developer finds a new job, he/she will leave you with a half-finished product.

How to conduct an interview

I've split it in three steps. The first two steps are usually in written form, whilst the last one is in person.

Step one

Since you defined the skills you need, the next step is to conduct an interview so you increase your chances of finding the best candidate possible.

Let's imagine the following: you want to build a software platform (a web application for example) for social networking, something like Facebook, and you have an idea about the concept and how it should work.

The first step is to create a job post for this. In the post you should explain your idea about the app, but only briefly, maximum 2-3 sentences. And at the end you should ask candidates when applying for the position to give you an estimate of how long it will take to build an app and how much it will cost.

After collecting the applications, you might find answers regarding estimates fall into these groups:

1. I need X months to build it and will cost Y amount
2. I need around X months to build it and will cost around Y amount
3. I might need from X to Y months (a wide range, like from one month to 36 months) to build it and might cost between Z and W amount (also a wide range like $1,000 to $500,000)
4. I cannot give an estimate

The answer you are looking for is number 4. Answer 3 might also work. What you definitely don't need are answers 1 and 2. So you can rule out the candidates who fall into the groups 1 and 2.

Here is why: It's impossible to give an estimate without enough information about the app. It's like asking "how much does a vehicle cost?". No one could answer that question like "it costs $12,000" because the question does not specify what type of vehicle, used or new condition etc. A new Tesla definitely wouldn't cost the same as a used Toyota Corolla from 1991. So without enough data about a project, it's impossible to give an estimate. Experienced developers who know how to build a software know that very well.

People who fall under groups 1 and 2 also might be people who are not interested in your project/business and all they want is to get a job. They are not the ideal choice either.

So this first test will eliminate some of the people who:

• are not sure how to build a software (N3)
• don't have any interest in the product (N4)
• probably only need a job (D2)

Step two

After collecting all the answers and deciding which candidates will move forward, the second phase begins. This phase can still be accomplished in writing. Since the candidates should already be familiar with the application you want to build, now you would ask them, despite lack of the information about the project, how they would proceed with project development and what a typical process looks for them. In this step, you want to see how you and the developer would interact and communicate during the development and what the process will look like.

The answer you are looking for is that you fully understand how the developer approaches projects and what your interaction would be throughout the whole process. If you are still not sure how you will work together after reading the answers, it is a red flag.

The answer might look something like:

I am assuming I will be the only one building the app. If there are other developers in the team, we need to discuss the process together. But this is the way I would usually do it:

The first step would be to sit together and to collect all information about the project so that I can have a complete picture. Without understanding a domain, building reliable software that does what it is supposed to do, is not possible.

Since I understand the domain now, I can give a rough estimation about duration and cost.

The next thing I will do is to split the project into milestones so that we have a clear plan and can review the ongoing process. I will also setup a staging website so that you can follow how software emerges.

When I start developing the app, I'll do it in small pieces and integrate them incrementally (daily basis). Whenever I add a new functionality, I will set it on the staging website in order to get feedback from you. That means I'll constantly report to you (max every couple of days) so you can keep track and are aware of all progress.

It is vital to get early feedback from you to make sure we are building the right app from the start. This way any misunderstanding we could have had can be easily fixed since we are integrating small pieces of software at a time.

When we reach the first milestone we will recheck if we are on the right track and make adjustments if needed.

At the end of the process I will deploy it on production and reach the first live customers.

It doesn't need to be written exactly like this, but the general idea to understand what to expect during the entire process of development. Their answers will show a couple of things:

First, it's supposed to show that the developer knows how the process of a development will take place. Which means they've done that already and they have experience in that regard. The more you understand the process the better. If you struggle understanding it and think a candidate might be a good one, you can ask for additional explanation. If it's still not clear afterwards, then a candidate either is not 100% sure how to do it or doesn't know how to clearly express him or herself. There is a pretty strong correlation between a candidate's poor communication and how he/she will perform. In either case it's probably not the right candidate for you.

The candidates are supposed to show that they understand your needs. Sometimes good candidates need to look at the project from a business perspective. Explaining the process from your point of view, as a business owner and not necessarily familiar with software, will help make your expectations and needs clear for any developer. A candidate who understands your needs will say something like:

When I start developing the app, I'll do it in small pieces and integrate them incrementally (daily basis). Whenever I add a new functionality, I will set it on the staging website in order to get feedback from you. That means I'll constantly report to you (max every couple of days) so you can keep track and are aware of all progress.

This clearly expresses that the candidate understands that you need to keep track of development and to be involved in the process. As a non-tech person the process might not be familiar to you, but the candidate should explain how you will be involved in it.

Candidates who give answers like: Now I understand what I have to build, and once I am done I'll come back to you and show the finished app. I will need for it X month(s) should be totally ruled out. These candidates show lack of experience in software development since building software involves a lot of discussions during the development process (unless the app is a trivial one) since there will probably be many instances that arise that were not covered in the initial discussion about the scope of work. It's also extremely difficult to transfer knowledge about a whole app idea to the developer in one sitting, especially for any app that is not trivial. At the end you might end up with an application you didn't want since development could easily deviate from what you want due to a lack of communication.

Additional points for candidates if they can explain why they want you to be involved in the process like:

It is vital to get early feedback from you to make sure we are building the right app from the start. This way any misunderstanding we could have had can be easily fixed since we are integrating small pieces of software at a time.

This type of response shows the developer knows that early input and working on small increments are vital to building applications efficiently. Experienced developers know this very well.

As it's mentioned above, the reason for the second step is to understand the process as much as possible. At the end, you should choose candidates whose process you like and understand the most.

This second test will help you to find candidates who:

• understand your needs as a business owner (N2)
• are experienced and know the process of a software development (N3)
• can clearly express him or herself the way it's understandable for you as a non-tech person (D1)

Step three

Once you filter through candidates by using steps 1 and 2, you get to the final step. This step should take place in person between you and the developer.

At this step you can discuss with the candidate the process from step two, you should ask questions to make sure you get a whole picture of the process. The candidate's answers need to be clear and understandable for you as well. This is another way to evaluate competence in person.

Afterwards you should talk about the application you want to build, and you need to explain to the candidate your idea more in depth. In this phase, ideal candidates usually ask many questions about the application, trying to get a complete understanding of your idea and gathering information to give estimates/suggestions/comments on your idea. If this is not the case, it is a red flag.

This part should also show whether the candidate is interested in your project and how seriously he/she takes it. It will also show the candidate's passion to work on your project, which also might be very important for you. There is no rule of thumb of how many questions a candidate needs to ask or how he or she should behave in order to show passion, this all depends on your personal judgement.

Since you are sitting with the candidate in person (or via video call), you will be able to observe a candidate and his behavior. Because you will be trusting this person with your project, it is important they exhibit politeness and honesty. At the end, you must go with your gut feeling; if you don’t like someone in person, even if you don’t know why, it is best to skip that candidate.

To see if someone is trustworthy, paying attention to body language is important. It might be that you don't explicitly understand what someone's body language is saying, but the unconscious part of your brain probably does and it sends signals to the conscious part that the person is not a good match for you. This is your gut feeling, go with it. This is a skill that can be trained, and for you as a business owner, it can be very helpful to study body language.

That's why it was important to conduct this step in person, or via video call if in person is not possible.

This step should show:

• Nice and polite person (N1)
• A person who knows what he/she is doing (a professional) (N3)
• A person who is interested in your product (N4)
• A person with a good verbal skills (D1)

At the end

If it is not mentioned during the interview, make sure to ask about deploying your app to production, though good candidates would have already explained this part. Many developers think that their job is done when they finish building the app and totally miss the part of setting the app up and running. If it's a web application or a web-site, and you want it online for your users/clients to access when they type, for example, www.my-website.com, make sure the developer knows that you want a final product that is ready to go live for your customers.

Summary

The process of finding a good freelance software developer is not easy and it might take a while. After interviewing many candidates that you may feel are not good, you will eventually find the one you are looking for. You just need to be persistent and keep searching.

Alle Artikel anzeigen