Recently, I've been doing many interviews to find a new job. Because I had some experience of doing them myself too, it was painful to see how companies lose good candidates because their interviewers sometimes didn't understand what they were doing. But I feel their pain. Sorting algorithms and rotating RB-trees have become memes of shitty interviews, but nobody gave any new advice on doing it right. Here I want to share my view, which helped me out many times — from hiring junior devs to finding my own team lead.

For two reasons.

Practical one: there is no ruler to properly measure engineers. Standard grades "Junior-Middle-Senior-Lead" helps not more than a stick from the forest helps us measure the speed of light. Just take a look at levels.fyi to see how different it is from company to company. And there is still no single community standard for that.

The second reason is a bit more complicated: a variety of skills today is wide. You need not one, but 148 different "rulers" to measure an engineer. And they will change with your company growth: at the beginning, it's more profitable to hire those with "fire in their eyes", while in the years of stability and good revenue, howling engineers are too dangerous. It’s time for a company to hire 9000 bureaucrats and surround them with "processes".

After that, early employers will run away in horror, writing unveiling posts on Medium, while the company can continue to grow steadily. That's absolutely normal.

This leads us to the popular today's bad practice — copying large companies interviews. The cargo cult in IT is strong like never before. I've seen startups hiring developers based on how well they were spinning trees, and then wondering why MVP was delayed for a year. Of course, they spent the whole year arguing about the best tree structure for storing 25 comments and understanding how Docker works.

On the other hand, we have large companies that have come up with lists of subjective rules for hiring "The Best" (that's how it's written in that PowerPoint presentation). The candidate does not remember some random definition from Wikipedia — let him go bollocks. Did not hear the question and did not fit into the given 15 minutes — go clean my toilet, moron. The flow of new candidates will never run out anyway.

Those are the rules of the game. If you want Google's salary, benefits, and healthcare, be ready to sit for a month at Cracking Code Interview mixed with Cormen, and loudly present why manholes are round and how many golf balls may fit the Empire State Building. Preferably in dance.

Let's move towards the sane interview process. The main goal of any interview is to make a binary decision "HIRE" or "NO HIRE". In order to do that, there are only three qualities to look at. New dude does not fit at least one of them — sorry, it's not gonna work. These things do not fix themselves in a year, no compromise has ever ended well in my memory.

This is not to be confused with knowledge, erudition, or IQ level. Olympic diplomas do not save anyone from shitty code. Synthetic benchmarks and "100 algorithms" tests are bullshit, meaning that the interviewer has no idea how to do his job (well, or it's the Big Corp process, see above).

Smartness — is the ability to reason, ask questions, analyze arguments, not jump to conclusions fast, see the pros and cons of solutions, processes, and frameworks. Especially own ones. Wisdom can be replaced by experience, but not always. The experience becomes knowledge only if it has been properly reflected, that requires, again, smartness (or a mentor).

The younger and immature the project is, the more it needs people who can create an MVP in a week from scratch. Old and mature projects need the opposite: the fewer people think of features and think more about quality, the better. You need to find your own balance.

The ability to get things done is simply identifiable from direct answers to the asked questions and the notorious "fiery eyes". Even if the eyes are full of hate for all the IT world, this dude will definitely put together an MVP in a week.

The ability to get things done has one unpleasant feature: it reduces with the growth of wisdom. And there's nothing you can do about it. "I'm too old for this shit" mode on.

IT is a team game — solo players are not competitive here anymore. In my memory, the incompatibility of a person with a team is one of the main reasons for dismissal. So even if the candidate fits the other requirements, there is always the third one — how much the candidate "looks alike" the team and how well he is capable to collaborate.

To hire even the most intelligent nerd into a team of highly efficient alcoholics is a shitty idea. "Ninja-Superstar" will also rot in the team, where the file renaming needs to be coordinated with the team lead (true story), or where story points are assigned to "correct typo" tickets.

Despite that, both candidates, being in the right place, can become geniuses of efficiency. Therefore, wise team leaders are able not to hire good candidates who, unfortunately, will not team up with others.

To understand exactly who we need, we need to dive deeper into the way engineering teams work. Every team is a micro-company within the company. They go through the same stages of evolution — from a small "start-up" team of friends who bootstrap a new project using latest frameworks to an elderly barely moving team of pensioners, whose only task is to maintain it's own stability while the company makes millions of revenue.

That's why any team of engineers has unofficial roles. You don't always have to have them all. The necessary set of these roles must change over time, so there is nothing wrong with old ones leaving and new ones coming. I use the set of five which one of my good friends told me about:

Can design the entire project for years ahead. They're the kind of people who first aim for six months, but then hit the target with one shot. And enjoy it.

Pros: sees the big picture. Help other engineers to keep the structure clean. Help product manager to plan big changes.
Cons: usually slow. Not experimenters. You don't need more than one.
Usage: everywhere except early-stage startups.

They solve problems faster than the rest of the team can even plan a meeting to discuss them.

Pros: the fastest members of any team. Real fighter jets.
Cons: require more quality control. Often burn out of routine.
Usage: ideal for start-ups. Help new teams deliver the product faster, and solve problems in old teams. To protect from burnout, better to give them some research tasks.

Know all newest frameworks and best practices.

Pros: can give you any tool to solve problems.
Cons: new fancy tools are usually less ready for long term battles. Let’s rewrite it in 2 months, yay!
Usage: useful for new teams because can help to choose the most effective tools, as well as for old ones, because can push them towards modern solutions.

Can do a lot of tickets at an average speed. Have no problems with long routine tasks. The “ideal” engineers from books.

Pros: close tickets that others don't even want to start. Don’t require a lot of time to manage. You can never have too much of them.
Cons: work badly without other roles due to inability to self-administrate. Always need a person to answer questions.
Usage: good addition for any team of more than one person.

Help keep things clean, documentation up to date and code organized. Organize processes and notices mistakes of other team members. Slow down a team in general (sometimes it's a good thing).

Pros: 80 lvl organization skills. Good reviewers and QAs.
Cons: bureaucracy always eats other team members' time. Can down it to zero.
Usage: required in a mature team to prevent "geeks" and "troubleshooters" from breaking everything up.

That's it.

Always look for the roles your team need, not just the popular ones

One person almost never has one "clean" role. Usually, it's a set of two, rarely three. Some roles are naturally complement each other, others require a strong team leader to make them work together. Spend some time thinking about them and the balance you need.

Any interview is a battle between two unequal sides. The company side has all the information and ready for anything, while the candidate is like a student who has come to an exam with even no idea in what the subject is.

Smart interviewers always remember: it's impossible to avoid own biases, but you can reduce their impact. I came up with my way of avoiding them many years ago.

If I ask a candidate a question that has the only correct answer (and I probably know it) — it's a terrible biased question

Any question of the "Does he know?" type is an interviewer failure. The fact that candidate does not know something you know (probably because you have read about it five minutes ago) means the candidate is shit, right? No! The interviewer, who does not realize his own bias, that's the main shit in the room.

The correct way to put your question is "to understand what he can". Further on we sort out the answers and evaluate the three qualities from above. That's it.

Questions should not be an attempt to amuse your ego by knowing the term "intrusive list" from university or memorized articles about pressing Enter in a browser, or any other information that you have recently read.

Yes, when you hire a junior developer, it may be a marker that he read the two must-read books. With seniors, it just doesn't work. The senior developer had seen so much crap in his life that he'd already forgotten 90% of that. In times of university, for example, I remembered all the Unicode encodings and could read the string byte by byte in plain C, respecting the BOM. Now I can't even tell the difference between UTF-8 and UTF-16 without googling. Does this mean I'm a stupid bastard? Of course! But that does not make me a less experienced developer.

Unfortunately, in most cases, people kick back and do interview in style "a team leader with the guy who is too lazy to work today, interrogate a candidate about the function that cuts a string in PHP on the whiteboard". Shame. There's still a lot of work to be done here.

Let's remember the classical recruitment process steps:

• Screening by an HR for adequacy and position fitness overall
• Technical interview (from one to infinite)
• Conversation with one of the lead developers about values, leadership principles, and other "very important" corporate stuff
• Offer, contract and everybody drinks!

All these stages are clear and unchangeable from company to company, except for one — technical interview. A topic that is horrifying to everyone, but has clear steps to avoid disaster.

The product owner (or whatever scrum role for that you have) works the best at this stage. However, technical leaders also sometimes sell well. A simple 5-minutes prepared speech will do:

• We are in %company_name% doing X and Y (what are we doing)
• Our team is working at solving Z problem (what are we REALLY doing)
• We have N persons, M of them are developers, use Scrum, etc. (team and processes)
• We write everything in %language_name% using %framework_name% and %database_name% (stack description)
• Now we are looking for new people to do this and that (plans and understanding what we will be doing)

That is all. You are gorgeous.

The same prepared speech, but on the side of the candidate. First, for the sake of a trivial acquaintance and further questions as regards the CV. Secondly, which is more important, to test the primary soft skills. I cannot imagine a position above the junior developer, where the ability to convey thoughts would not be useful. The plan is something like this:

• I have been coding in %language_name% for N years
• Now I'm working at %company_name%, and doing X to solve Y (present occupation and tasks)
• We're using X, Y, and the fancy crap over there (current stack)
• Previously I used to do this and that (the past and experience)
• I've also been working on X and Y, but the coolest shit I did was Z (general technical background and plans for future)

Optionally the story can be completed with proofs and facts. If one of the questions was omitted, you can ask about it during the next stage.

The point where the interview actually begins. Here it is worth remembering that we are not hiring salesperson from Wall Street. We have a developer here who is so intimidated by books telling horror interview stories that he had already prepared himself for tree rotation and wrote out the properties of Big-O notation on his arm.

That's why I never start with the stressful "why do you want to leave your company?" It will only increase anxiety. I always start with the simplest technical "ice-breaker" questions in order to start a dialogue between peers and evaluate the overall engineering adequacy. Not more than 5 minutes (but I never fit hehe). Here's a list of my favorite questions. One-two is usually enough.

• What is your favorite language and framework? Now tell me it's weaknesses
• How did you become a developer? What drives you?
• If your favorite programming language didn't exist, which one would you choose?
• Imagine you could give yourself advice 10 years ago. What would you advise?

The answers are not so important, but sometimes even at this stage, you can catch out a couple of insane or violent ones.

When the contact is established, you can bomb your questions. Usually, there is time for one task at maximum, so choose wisely. I would immediately give examples of some idiotic and useless tasks among the popular ones:

• ⛔️ "What function does X", "what are Y types," "how does Z work", and other theoretical issues discussed above. It's a waste of time and a clear sign that the interviewer is incompetent, the office is shit and you have to say goodbye right away.
• ⛔️ "What happens after pressing Enter in a browser?" After that very post on Medium, everybody got literally sick with this issue. This question does not give anything but the fun of feeding one's ego.
• ⛔️ Puzzles with coins, ropes and "How would you move mount Fuji". Obsolete five years ago and no one could understand why they were asked at all.
• ⛔️ "Your greatest weakness", "your personal achievement", "problems you solved", etc. In 148% of cases, you get a "socially acceptable" and prepared answer. No one will answer that honestly.
• ⛔️ Live coding in a whiteboard or Google Docs. Humiliating practice, especially when they do it with a time limit (almost always). If you want to watch how a person writes a code (for some reason) — sit next to each other and do pair programming in your favorite IDE. Google Docs is good for drafting solutions, no more.

Now let's see the good questions:

• ✅ To give a simplified version of the problem that you were recently dealing with. My favorite option. The candidate immediately understands what the team does, and the team sees how much interested the candidate is. This stage shall go in a dialogue mode: how would you solve it? And what are the limitations? What would you use here?
• ✅ Some time ago, we had the following problem. How would you solve it in our place? Ask for 2-3 options, which will make it clearer what role the candidate will play in the team.
• ✅ How would you develop a product similar to ours? Suitable for new products or strict NDA rules. You can take a similar product of competitors and discuss it together.
• ✅ Here is a pull request made by one of our juniors. Make the code review. The candidate sees the real project, and the interviewer his ability to read, develop, and discuss code without fanaticism and hysteria.
• ✅ Tell us about a non-optimum architectural solution in one of your past projects and why it was made. The developer must be able to make and discuss ambiguous decisions.

There is one problem with the list of tasks above — none checks the ability to write code. Yes, it is a secondary problem, you can teach coding even a monkey, linters and code review will trim anyone's job, and the rest will be determined by the trial period, but sometimes you still want to have a look at the code.

The most adequate option here is to give a test assignment to be done at home. One that will take an hour or two. Propose it without any time limit and the commitment to do it. For obvious reasons, many developers do not like test assignments, therefore I have a life hack for them:

GitHub profile with some code in it fully replaces the test assignment

I myself stick to this approach and it is mega-convenient. The interviewer does not have to wait for several days, and the candidate — to spend the evening on the tic-tac-toe again. Even if there are no projects, you can legally post on GitHub a test assignment made for another company. Pretty awesome. Please, start doing it.

The last stage, which for some reason everyone forgets, devoting five minutes to it at the end. A healthy interview implies that not only the company evaluates the candidate, but also the candidate decides whether he wants to work there. In addition to standard questions about the team, processes, and frameworks, I have a question that I adore asking at the end of an interview.

After this question, you can lie back in the armchair and enjoy the flow of good ideas or alarms (depends). The question is this:

Are you happy to do what you are doing? Why?

Well, think about it at free time too. Ciao!