Short guide to hiring normal people

For two reasons.

Practical reason: no one came up with a unified certification exam for IT specialists. There is no universal ruler to measure everyone. Standard seniority grade "Junior-Middle-Senior-Lead" helps not more than a stick found in the forest when building a spaceship. Therefore, each company has their grades and a Senior from one company may turn out to be a Middle in another. A unified community standard should have been created long ago, but I have not seen such a standard so far (will you show me?).

The theoretical reason is a bit more complicated: variety of necessary skills is too large. It turns out that we need not one, but about 140+ grades, and each company will have its own set of requirements. They will also change together with the company growth: at the beginning it is more profitable to hire those who have "fiery eyes", then in the years of stability, after the IPO happened and stable revenue is secured, howling engineers are too dangerous: a company usually hires over 9000 bureaucratic executives to accompany those and to distract them with processes. After that, earlier employed specialists usually run away in horror, writing posts "How they screwed everything up there" and "XXX is no longer same cake", while the company can continue to grow steadily.

This is the harsh insight into real life which logically gives reasons for the next section.

A popular bad practice is to copy interviews of large companies. The cargo cult is generally favorite entertainment in IT field. After the release of the book about the Microsoft interviews, questions about round manhole covers and golf balls fitting into school bus were being asked for another ten years. Now this practice miraculously stopped.

I have seen how developers were recruited for a startup according to their capacity to solve puzzles and traverse trees, and then the company wondered why they delayed MVP for half a year while choosing the right tree data structure to store comments.

Enterprises on serious grounds create lists of subjective rules for hiring, which actually look like this:

The candidate does not remember by heart some random definition from Wikipedia — let him go bollocks. He made a typo in a code? — chase him out with a broom. The candidate did not hear the question and did not fit into the given 15 minutes — bye-bye! The flow of candidates will not exhaust anyway.

Is it a shit? Yes, it is. But such a selection saves a lot of bucks, which means that it is efficient for a bloodthirsty corporation. These are the rules of the game: if you want a Google salary and a VHI, be ready to sit full-time for a month at Cracking Code Interview mixed with Cormen's book and all the day round think about how many balls may fit into the Empire State Building.

On the other hand, there are startups that do not care how many sort algorithms you know, but for them it is vital that you do things and fit into the team. Everybody should be "on the same page" or "like-minded", as they like to say. For them, interviewing in the park while drinking a beer is a fabby efficient process, sifting out any stuffy dudes.

Unfortunately, in real life few people are so honest with themselves to say directly: "Well, we are doing an online store, it doesn’t take much wits to proceed". Everybody is sick with unique corporate values and "select only the best". At least that’s what that HR presentation says. PowerPoint, as you know, would not lie.

If you have internal recruiters — you are wonderful and gorgeous, feel free to skip this chapter. However, they are often not available, therefore there are two options.

First option — outsourced recruiters. Those are IT cancer. They shit on the market, company and candidates, they live well at their expense, getting 1−2 monthly salaries of each successful candidate.

They work following same scheme, which is massively spammed everywhere: "Hello, %username%. We noticed you have a huge experience in %programming_language% and %framework_name%. We offer you a unique job in the European company "Intercom Blockchain Ltd". Relocation to Voronezh is possible. I will tell the details by phone. Prepare a webcam. Company name is protected by NDA".

All my friends receive such letters in dozens a week, no one even reads them. Everyone knows what will happen next: half an hour of your life will be lost for stupid questions: "How much experience do you have?", "Do you spend a lot of time for the road?", and then the recruiter would proudly sight-read job description with a salary of two rice bowls a month. Because nobody hires recruiters in order to search personnel for good positions.

Someday all of them will be replaced with scripts.

There is a second option: look for personnel on your own. First you shall write an honest text, describing the position, trying to avoid clichés about the "coffee-cookies-marketmaker", then post the information on one of the popular sites and wait. Do not believe the fairy tales that "good candidates do not come themselves", they do come of course! The main thing is honesty. It attracts exactly those who is needed. If you are a team of slackers, write exactly as it is.

Better pay cash bonuses to your own employees for the recommended specialists. That’s the whole secret.

The goal of any interview is to make a decision "to hire" or "not to hire", and there are only three qualities in a candidate to look at. New dude does not fit at least one of the requirements — sorry and goodbye. Such things do not fix themselves in a year, so in my memory the compromises never ended well.

First two qualities are from the article by Joel Spolsky The Guerrilla Guide to Interviewing (version 3.0), which itself is very OK.

This is not to be confused with knowledge, erudition, or IQ level. Diplomas from skills contests do not save from shitty code. Synthetic benchmarks or questions as regards the knowledge of algorithms — a complete bullshit, meaning that the interviewer does not understand how to do his job (well, or this is the process, see above).

Smartness — is the ability to reason, ask questions, analyze arguments, not make hasty conclusions, see the pros and cons of solutions, processes, frameworks. Especially his own ones. Wisdom can be replaced by experience, but not always. A classic experience is a lot of things seen before, however, several more intermediate steps are necessary to turn it into knowledge.

The younger and immature the project is, the more it needs people who can create a product from scratch in a week. Old and stable projects need the opposite: the less people think of features and think more about logic, the better. If Google allowed every junior committing to a master, imagine what would begin. So again: you need to find the 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 deteriorates in proportion to growing wisdom.

IT is a team game — loners are not competitive here. 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 alcos 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 typos.

At 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.

Any interview is a fight between two yokozunas who are in a definitely unequal position. The company side has all the information at its disposal and is ready for anything, the candidate is like a student who has come to an exam with no idea in what the subject is.

Smart interviewers remember that it is impossible to get rid of their own biased approach, but you can try to deceive this attitude. I came up with my universal way to avoid biased approach many years ago.

Any question of the "Does he know?" type is a failure on the part of the interviewer. The fact that he does not know, and you know (because you have read about it five minutes ago or remembered from the university program) means the candidate is a shit, right? No! The interviewer, who does not realize his own biased approach, is the shit here.

The correct way to put your question is "to understand whether he can." Further on we sort out the options together and we evaluate the presence of the three qualities described above. That is all.

Questions should not be an attempt to assert oneself just because you know the "intrusive list" term and memorized articles about pressing Enter in a browser, or any other information that you have recently read…

When you hire a junior developer, it may be a conditional marker that he read the two must-read books. In contrast, a senior developer had seen so much shit in his life that he had already simply forgotten 90% of that. In the university, for example, I remembered by heart all the Unicode encodings and could read the string byte by byte, respecting the BOM. Now I can't even tell the difference between UTF-8 and UTF-16 without googling. Does this mean I am an illiterate redneck? Of course! But that does not make me a less experienced developer.

Unfortunately, in most cases, people kick back and hold an interview in style "a team leader together with team member who is too lazy to work today, interrogate a candidate about the function that cuts a string in PHP".

A funny story happened when I was preparing this post and interviewing people: some guy sent me a link to a list of fifty theoretical questions as regards all types of algorithms and data structures, which, according to his statements, "perfectly helps to sift out any weaklings". I wanted to refer to it as an example of how one shall not do it, but I could not —their web-site is unavailable for three days with UnhandledException. Oh, irony, heartless creature!

Let me remind you what a classic hiring process looks like:

All stages here are generally understandable and similar for all companies and positions, except for one — technical interview. The topic is raising lots of crappy discussions, although in fact all the best practices are existing for a long time — take and use them.

Do not try to shove all the steps into one exhaustive marathon-interview. All this can be perfectly divided into several 30-minute conversations.

The product owner (or corresponding scrum role in your company) will do the best at this stage. However, technical leaders also sometimes sell well. A simple 5-minutes long prepared speech of the following type will do:

That is all. You are gorgeous.

The same prepared speech, but on the side of the candidate. First, for the sake of a banal 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 clearly convey thoughts would not be useful. The plan is something like this:

• I, Jack, have been developing in %language_name% for that many years.
• Now I am working at %company_name%, and doing these things (telling about the present occupation).
• We develop everything with that thing using that trendy whatchamacallit (currently used stack).
• Previously I used to do this and have done that (telling about the past and work experience).
• We used to do this, later we did that, but the coolest thing was that one (more generalized technical background).

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 sales person from Wall Street. We have a developer here who is so intimidated by books telling interview stories that he had already prepared himself for tree traversal and wrote out the basic properties of Big-O notation on his arm.

Therefore, 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.

• What is your favorite language and framework? Now tell me the weak points of them.
• Why are you a developer at all and what drives you?
• You are a senior developer now and you can give an advice to yourself, yet a junior 10−20 years ago. What would you advise? (thx @theKashey).

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 made, you can bomb with tasks. 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:

Now let's see the good tasks:

There is one problem with the list of tasks above — none checks the ability to write a 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:

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 Xs and Os again. Even if there are no projects, you can legally post on GitHub a test assignment made for another company. Pretty awesome. Do like this.

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 a technical interview (there is no sense to ask it to HRs and managers — they are prepared).

After this question, you can lie back in the armchair and enjoy the flow of alarm bells that will sprinkle back — from the false standard phrases to deep insights into IT life. The question is this:

Well, think about it yourself at your leisure. Ciao!