Preface from me

This is the translation of the original article in Russian about bad practises of IT interviews. To my astonishment I found almost all of them in the interviews that I've been taking for the last 6 months. The motivation for the current text is to attract attention to some bad patterns and give some improvement hints that could help to find a better candidate.

Here is the adopted text from the author:

Today I will try to share my personal experience of conducting good IT interviews . The ability of giving good IT interviews is getting crucial for a senior developer since we are more often involved into hiring process.

Sorting tasks and questions about twisted trees became memes of shit interviews long time ago. But how to do it right, no one told. I'll try.

There are no ideal interviews

There are 2 reasons for that.

• Practical: there are no Graduate Record Examinations for IT specialists. There is no universal estimation scale. Standard prefixes "junior-middle-senior-lead" help as much as a stick for building a spaceship. Every company has own standards: a senior developer in one appears to be pre-middle in another. The time has come to create a unified standard for IT specialists (I don't know any maybe you know?)
• Theoretical reason is a bit more complicated: there are too many required skills. You need 140 different scales, one per each skill, and every company will have its own unique requirement set for each combination.

The company requirements might change over time, in the beginning it's good to hire people with "shining eyes", but after years of stability, IPO, and revenue flowing down the cheeks such engineers become too risky for a stable company. It hires additional 9000 bureaucrats to disturb developers with process activities.  

This results in mass resignations and feedbacks like "they ruined all" or "it's not like it was before", but the company will continue to grow. 

It's a hard truth of life, from which we are coming to the next point.

We know how it's in Google

A very popular and bad habit is to copy interviews of big companies. The cargo cult is very popular in IT. After a publication of the famous book about Microsoft interviews the questions about golf balls and disks have been asked for the next 10 years. Today this tendency miraculously ended.

I experienced a startup hiring engineers which were able to solve puzzles and invert trees, but later the management was surprised, why those delayed MVP for half a year trying to find a more suitable tree shape for saving comments.

Big companies invent long lists of subjective requirements, which can be shortened to "we don't need losers". A candidate doesn't know a random definition from Wiki by heart? Go away! He made a typo in the code, didn't hear the question, didn't answer within 15 minutes - say good bye! The queue of potential candidates will never end. 

Remarkable story of the Homebrew creator, who was rejected by Google.

Is it bullshit? Yes. Such kind of screening spares money, therefore it's efficient for a corporate business. The rule of the game is: wanna cool salary and benefits, be able to read "The Cracking Code Interview" and Cormen fulltime and at any time of day think about how many balls can fit into Empire State Building. 

On the other hand there are startups  who don't care how many sorting algorithms you know, but it's crucial to them to get things done and have a team player. Everyone should stay tuned and be like-minded. For them an interview with a beer in a park is an optimal way to filter out not fitting candidates. 

Corporate transparency is rare. In reality very few are honest enough to say "We are building an e-commerce shop and it's not rocket science". On the other hand everyone is crazy about corporate values and selecting "the best from the best", as it's written in some Powerpoint presentation, which is the single source of truth. 

Where to find people

If you have recruiters on site, you're amazing. Don't read this part! But more often it's not the case. So you're left with two possible variants.

Outsourced recruiters

These are the cancer of IT. They don't give a shit about market, companies and candidates. But they earn quite well, getting 2-3 month salaries for each acquired candidate.

They generate great amount of spam messages according to the same template:

"Good day, %username%. We noticed your huge experience in %programming_language% and %framework_name%. There is a remarkable job in an international company. Relocation to Island is possible. I can share details on the phone. Be ready to turn on the web-cam. The real company name is under NDA".

All my friends receive dozens of such mails, which always land in the trash folder. Everyone knows, what happens next: they take 30 minutes of your life for dumb questions like "how much experience you have" and "how much time you spend for the road" and then proudly read some text about a great job and "2 bowls of rice" salary. Be careful as no one hires outsourced recruiters for good positions. Some day they will be replaced with scripts.

The second variant is to find people by yourself. Write an honest job description avoiding known cliches  about "coffee-cookies-market-leaders"! Post it to a popular job site and wait. Don't think that "good candidates don't come by themselves" - they do, most certainly. Very important is to be honest. It attracts people with the same mindset! If you're a team of "dumbasses" - write it. 

Don't forget to pay bonus to your employees for bringing referrals. That's is the whole secret.

3 abilities of candidates you should take care about

The aim of each interview is a binary decision between "yes" or "no". There are only 3 requirements to candidates you should care about. If any is not matching, say "good bye" to him or her. It takes years to develop any of those abilities. And compromises are not a good idea.

The first 2 abilities were taken from this amazing article by Joel Spolsky. 

Being smart (wisdom)

Don't confuse it with knowledge, erudition or IQ level. Certificates from olympics don't protect from shit code. Synthetic tests or questions about algorithms are bullshit, which means that the interviewer has no clue how to do this job (or it's just an intentional filter mentioned earlier).

Being smart is the ability to think, ask questions, analyse arguments, not make hasty conclusions, see pros and cons of solutions, processes and frameworks. Especially the own ones. 

Wisdom can be replaced with experience, but not always. A classical experience is the result of seeing much, but to convert it to knowledge you need some additional steps.

Get things done 

"Get Shit Done" is another variant of this ability. The younger and fresher is the project, the more it needs people, which are able to build a startup for a week. Old and stable projects need the opposite: less quick features, more solution consideration. Can you imagine the consequences, if Google allowed committing to master to every junior developer? We need again a golden middle.

To recognise the ability to do things easily, pay attention to the specificity of answers and of course to "shining eyes" as a sign of motivation. Even if the eyes are burning with hate to the whole IT, he will be able to build a MVP for a week.

The ability to get things done has a very unpleasant tendency, it decreases with the wisdom growth.

Team compatibility

IT is a team game, outsiders are not competitive. One of the main reasons of firing people is the incompatibility with the team. Even if 2 other requirements are matching, the third one should be a decision point: look at how much the candidate resembles the team and how good he can collaborate.

Bringing the most smartest geek into a team of highly efficient "alcoholics" is a shitty idea. A "ninja-superstar" will leave a team, where renaming of a file requires confirmation from the team lead (true story) and typos become tasks with story points. 

On the other hand both will become samples of efficiency in a right place. Therefore smart team leads reject even good candidates if they are not compatible with the team.

How to avoid own bias

Each interview is a scramble of 2 sides being in unequal positions. The company side has all information and owns the situation, a candidate is like a student coming to an exam in unknown subject. 

Smart interviewers know, that own bias is impossible to avoid, but you can try to cheat yourself. Many years ago I invented my own way to do this.

The questions should not be a way to demonstrate competence of the interviewer in "linked lists" or details of an article about hitting "Enter" in browser or any other he've read recently.  

If you hire a junior, it's ok to prove that he looked into 2 recommended books. A senior with all his years of experience has seen so much shit, that 90% of it is simply forgotten. 

In the high school I knew all unicodes and was able to read a string by bytes in a loop respecting the BOM. Right now I can't even name the difference between UTF-8 and UTF-16 without Google. Does it mean, I am a dumb redneck? Yes, but it doesn't show me as a non-confident developer.

Unfortunately the majority interviewers care too much about special and not-important things, therefore we have bunch of interviews with a team lead and some developer who doesn't want to work today asking which PHP function is cutting a string. 

A funny story happened to me, when I was preparing this article and asked people about their interview experience. Some guys sent me a personal message with a list of 500 theoretical questions about all kinds of algorithms and data structures, which according to them "helps to filter out weak candidates". I decided to download this list from their website to use it as an anti-pattern, but it was not available for next 3 days because of UnhandledException. What an irony!

The structure of a good tech interview

Let's memorise how a classical hiring process should look like:

• Hr screens the candidate checking adequateness and position match
• Tech interview(s)
• Conversation with a lead engineer about values, team collaboration and leadership principles (replaced previously popular "interpersonal skills", "focus on results" which became an object of multiple jokes)
• Making an offer and giving a party

All steps are clear and remain unchanged for all companies and positions, except for one - technical part. This topic is under heavy discussions, but in fact all best practices are there - take and use them. 

Don't try to do all the steps at once as an exhaustive marathon. You can split it perfectly into several 30 minute talks.

Step 1: Intro about company, product, tasks and plans.

The best interviewer for it is the product owner (if you use scrum), but also some tech leads with selling abilities. It would be enough to have a short intro like this:

• We as %company_name% do this and that.
• Our team is doing this for that (to understand why).
• We are N people with M developers etc (team and the processes)
• We write in %language_name% with %framework_name% and %database_name% (stack description).
• We are looking for new people, to do this and that (plans, understanding what we will do).

That's it. You're amazing. 

Step 2: "Tell about yourself"

A candidate can use a similar template. Firstly this could help to get to know each other and give chance to ask additional questions about CV. Secondly it's important to do first check of soft-skills. I cannot imagine a position above junior, where the ability to clearly convey own thoughts was not important. Here is the template:

• I am John, I write code in x for y years
• Currently I work in %company_name%, doing this and that (story about present time)
• We are doing all using that fancy shit (current stack)
• Before I did that and made this (the story about past and work experience)
• We used to do that, then this, the coolest thing was this (general tech background)

Optionally the candidate can add proves and facts to the story. If some of the points were skipped, you can ask them later. 

Step 3: A smalltalk about life and technologies

The starting point for an interview is important. You should remember, that we don't hire a salesman from Wall-street. We are facing an engineer, who is scared by interview books so much, that he has already took the position to invert trees and written down most of Big-O notation rules on his hand. 

That's why I start an interview with simple technical questions to break ice, set up equal dialogue and evaluate the general engineering competence. Not longer than 5 minutes. 

• What is your favourite language and framework? Tell me about its disadvantages
• Why do you program and what is driving you?
• You are senior and you can give one tip to yourself 10-20 years ago. What would it be?

The answers are not so important, but this will help to filter out some crazy candidates. 

Very good is the conversation about what you did in the past, which problems were solved - 80% of candidates can't give reasonable answers. Very helpful is the discussion about solving some problem e.g. how would you build the communication between micro-services - api, authorisation etc. 

Step 4: A real task

After you set up a contact, you can shoot some tasks. Usually there is time just for one, that's why select a task reasonably. Here are the examples of some idiotic and very popular tasks:

• "Which function is doing X", "what are kinds of Y", "how is Z working" - and other theoretical question. It's waste of time and first sign, that the interviewer is not professional and the company is shit. The candidate should say goodbye in this case.
• What is happening in the browser after pressing "Enter"? This question became very popular after this habr article. However it has not very much sense. 
• Tasks about coins, yarns, "Mount Fuji" became obsolete 5 years ago, no one could ever explain why they were asked. 
• "Your weak points", "personal achievements", "problems you solved" etc. In 100% cases you get socially acceptable answer or a prepared text. No one will answer honestly.
• Life-coding on a whiteboard or in "Google Docs". It's a very humiliating situation especially when there is time limit. If you want to watch the candidate writing some code (for whatever reason?), sit next and do pair programming in your favourite IDE. "Google Docs" are good to plan some solution variants, but not more than that. 

Now let's see the good ones:

• Give an easy version of a task, you solved recently. It's my favourite variant. The candidate understands what the team is doing, and the team sees how much is the candidate motivated to solve it. Do it as a dialog: how would you solve? what are the limitations? what would you use here? 
• How would you design a product similar to ours. It's very useful for young projects or strong NDA environments. You can take a similar product of competitors and discuss it.
• Here is a pull-request, made by one of our juniors. Do a code review. The candidate sees your real project, and the interviewer can evaluate his ability to read, write, discuss code without fanaticism and hysterics. 
• Tell me about non-optimal architectural decision from one of your past projects and why it was made. An engineer should be able to make and discuss ambiguous solutions.

I always ask about real problems in interview: how would you solve, optimise, scale something. The most important is to understand how the candidate thinks and how adequate he is. You will have a chance to evaluate his ability to program during the probation, since every company has it. 

Step 5: A home task

The tasks above have a problem - it doesn't give the information how the candidate writes the code. Yes it's not so much important: you can teach a monkey to write scripts, code reviews will make everyone better and there is a probation for the rest. But sometimes you also want to see the code.

The best variant here is to give a home task. Not more than for 1-2 hours. You can suggest it but without time limitations, and it should not be required. Many developers hate home tasks, for them there is a life-hack:

The code on Github is a 100% replacement for a home task. 

I do it myself as it's very convenient. The interviewer should not wait and the candidate doesn't waste his evening to solve another puzzle. Even if you don't have public projects, you can publish some test task you solved for another company. Amazing. Do it.

Step 6: Candidate questions

The last step which is almost always skipped or given 5 minutes at the end. A healthy interview is not only about some skills evaluation, a candidate should also have a chance to decide if he wants to work in company or not. In addition to the standard questions about the team, processes and frameworks, I have a question that I love to ask at the end of a technical interview (don't ask it HR or managers - they are prepared).

Are you happy to do, what you're doing? Why?

Think about it yourself. Goodbye.

Afterword from me

I am always very upset when I see that an interview was not well prepared. A company can justify it by not having enough time, resources or mind power, but think about how important is the hiring process to the business. Solving another everyday task has so less value compared to a potential team member who can help to solve N tasks in the future. Also don't forget that the most valuable resources of an IT company is its developers.

An interview must be prepared, it's a hard work which deserves as much attention as any other important task in your everyday work. Write down questions and design scenario of an interview. Plan time for each step and stick strictly to it, don't waste time for not important discussions or preparations.

Give a short overview of the interview to candidate in the beginning. Prepare questions and tasks before, don't try to invent them during the interview. Ask yourself what information each question or task is giving you and what impression the candidate will get. How would you answer questions yourself. Is it fair enough for the candidate's level.

I hope this text will change situation and help companies to find candidates they dream of ;-)