A Quick Guide to Hiring People in IT I employ more than 15,000 people -- designers and IT developers. And still often conduct interviews for key positions on my own, remotely. So today I decided to put all my experience in this short article. Here are a few key principles and ideas which I find invaluable.

The perfect interview does not exist

Or, at least, it has not been invented yet. Even the standard junior-middle-senior levels gradation does not help much. Because each company has its own needs, and a senior from one firm may barely qualify as a middle in another.

The main reason for this is the extreme variety of required skills. There are hundreds of programming languages, tools, styles, frameworks. Testing them all just doesn't work in an hour (or two hours, or three hours) format. You would need to conduct two hundred different tests. And each company would have its own set of questions. As a society, we are not at that level yet.

Remember the famous story about the author of Homebrew, who was not hired by Google, despite the fact that most of its engineers use his software. As you can see, even Google's vetting processes are not always working properly.

There is no objectivity in interviews. If you think there is, you are lying to yourself. This is important to understand and accept.

Related: Here's The No. 1 Thing You Shouldn't Do When Interviewing Job Candidates

Understand: you are not Google

Popular industry practice is to wholesale copy interviews from the biggest companies. After the release of the book about interviews at Microsoft people asked about manholes, moving mountains, and golf balls for years (and many are still asking). But it just does not work. At least if you are not Microsoft and don't need to solve problems of their level.

Nowadays, interviews are often conducted backward. The candidate does not remember some paragraph from Wikipedia (which he could Google in 10 seconds) or makes a simple typo in code (which the program would have corrected anyway) — and he is sent away. "His knowledge is not adequate." He didn't solve the problem in the allotted 10 minutes — goodbye! And in the end, they wonder why their real project is struggling to pick up steam.

I saw one startup recruiting engineers by testing their ability to solve puzzles and build graphs. And then the founders were wondering why their MVP (minimum viable product) was delayed for almost a year. The team was too busy choosing the appropriate data set for storing comments.

Everybody is fully invested in their "unique corporate culture" and "picking only the best." When, in fact, we are afraid to admit to ourselves that we are making just an ordinary website or a regular app. There is no need for the best developers ever. If the idea is good, and the workflow is set up well, just about anyone would do.

Where to find people

With the world going remote, the world is your oyster now. There are millions of decent developers, some asking as low as $30,000 per year. You can post job offers and look for developers on job boards, Telegram and WhatsApp channels, Facebook groups, even subreddits. I found that in the US regular websites work best: Indeed, Glassdoor, Hired, AngelList (if you are from a startup), Smartly, Jora. It's great if your company is fairly well-known: people can come to you on their own, using the form on the site to send an application. I have done it this way a few years ago, and now rarely need to use job boards.

It is also worth trying outstaffing. This option works even if you don't have internal recruiters. Just contact a specialized company and they will provide you with specialists of any kind. A convenient option when you are just starting out (and do not know exactly how many employees you will need) or when you are scaling fast (for the same reason). I find it is better than outsourcing for startups because it is in the best interests of the outstaffing agency to give you the best candidates. Agencies usually get a percentage of their workers' hourly wage, and if you are not satisfied with the employees they give you, they earn nothing.

Another good way is to involve your employees in the search. They all usually have several friends in a similar field with whom they communicate from time to time. If they bring them to you, and you like them, your employees can be paid a small percentage of their initial salary. There is no downside to this. And as a potential upside, the new person will automatically have someone who will introduce him to the company and will be responsible for him. The atmosphere of friendship is created by itself, without you having to do much work.

Related: Top 10 Best Free Job Posting Sites

The only three qualities you need to check

The goal of any interview is to make a binary "yes" or "no" decision, and there are only three qualities in a potential developer you should look for. If the person does not fit all three of them — sorry, goodbye. Remember, it is much easier (and less painful) to find someone else rather than hope they develop the qualities you are looking for. Most importantly:

1. They should be wise.

Don't confuse this with knowledge, education, or IQ. Diplomas and degrees rarely matter. What is more important is their ability to ask questions (including during the interview!), make decisions, understand the advantages and disadvantages of functions and frameworks.

2. They should be able to hunker down and work.

The younger the project, the more it needs developers who know how to get a startup running in a week. The opposite is true for old and stable projects: the cost of mistakes is too high, so developers should think more about internal logic and less about how to add different features.

Determining a person's ability to do things is simple: they will answer the questions directly, they will be enthusiastic about their work, they will be ready to go into the details. But be cautioned: the ability and readiness to get stuff done also have an unpleasant feature. They are steadily declining with the growth of wisdom.

3. They should be compatible with your team.

Any successful IT project needs a solid team. The days when Facebook could be developed by a lone programmer are sadly over. I find team incompatibility one of the main reasons people struggle with their work. They just don't feel the energy and the drive to do their best.

New candidates should not detract from your team, they should add to it. They should be similar enough with the rest. They should be easy to work with. Even a genius developer nowadays is not worth ten good ones. Wise team leaders should know how to refuse good candidates if they, unfortunately, will not be a good fit for the team.

How to avoid your own bias

During the interview, the two parties are in an unequal position. The interviewer speaks from a position of strength. He holds all the cards. The candidate is like a student who came to an exam, and is often treated as such.

But you are looking for a good employee, not a good student. You are looking for a developer, a partner who could think on their own. So you need a way to level the playing field.

Years ago I came up with my own way to check for bias in an interview. It's simple: if you ask a question that has only one answer, and you know that answer, this question is biased.

Think about it. It does not give you any relevant information about a candidate. If they don't know, they can still be brilliant. The question does not give you any insight into their thinking process, it doesn't tell you if they are wise and if they are a good fit for your team.

They don't know, but you know. So what? This is not a contest. Sometimes such questions can be asked of a candidate for the position of a junior developer. To see if he has any interest in this field at all. But if you are looking to hire a middle, senior, or lead developer, it is completely pointless.

Overall, as you can see, even tech interviews are still more magic than science. There are some automated systems, and the AI is trying to help (I know of Pymetrics, HireVue, and a few others). But I have tried them, and they are not ready for the mass market. For the next few decades, at least, the personal, human approach is the best we can do, even in IT.