Geekly Articles each Day
📜 ⬆️ ⬇️

These toxic, toxic job interviews



It all started when the author of Ruby on Rails confessed to the world:

Other developers joined it:

One of the most senior engineers at Google said that not a damn thing remembers how the quicksort works:

By the end of the day, dozens and hundreds of various developers had expressed themselves, including the authors of the products that you use every day.

Such a flash mob may seem nonsense to you, but it serves an important purpose: to demonstrate to everyone that not to put up such interviews for anything is normal. It breaks the spiral of silence .
')

How did this article come about?


For me, as for many others, interviews were regularly a pain. (And once I was also scared to go to them.)

I wrote this program material primarily from my own experience: I had to talk a lot in my life (startups, relocations). In the process of preparing the article, I argued a lot with various developers on both sides of the barricades - both with candidates and interviewers. Now I am including myself interviewing other people in my projects and applying the experience gained. I have formed a certain position on this issue, which I want to share.

What interviews are we talking about?




Why such interviews are harmful


They check under stress people who do not intend to work under stress


Popped out badly in production, one of the developers broke deadlines, shouted the gull manager. Stress is everywhere, what is already there.

However (if you do not work in the state order) stress, as a rule, the situation is still atypical. And it is a somewhat crazy idea to check a new person in the conditions of an atypical situation.
You do not check the new bed in Ikea, throwing a wardrobe at her? No, you lie down and imagine yourself sleeping on it. So why are you doing exactly the opposite in the case of interviews?

The most wonderful developers I have met are the nerds and the geeks. They need calm conditions. They need a flow condition. In the best of his times, such a person will code your most difficult task in a day. If you still want to test it for resistance to stress, maybe you should instead think how to remove stress from your processes? (This will give significantly more profit.)

Do not correlate with the development


Incredibly, Google itself admitted that there is no correlation between the way the candidate showed himself during the interview and how he went through the performance review in the process.


Wear a startlingly random character, putting you at risk of pushing away a talented developer and taking mediocre


Suppose you know a certain topic quite well, and suddenly a quiz question pops up on it. You do not know the answer. People notice this, and, as a rule, assume that you do not know anything about the whole topic. (It is much worse if you have caught more than one unfortunate quiz question, but several at once.)


Or, say, you write the code on the board, and the syntax is out of your head. What would it look like from the side - a problem with memory or with skills? Unknown.

Judge you in this case will be based on assumptions, and human assumptions - an incredibly random thing. They are often based on complete nonsense (for example, if you drink a lot of water, the interviewer may take it as a sign that you are nervous or even lying about your qualifications.)

Generate unnecessary elitism and hazing


Aichi as a field of activity is by its nature incredibly susceptible to a series of nonsense:


The reasons here are different, and you can argue about them. I would venture to say that the hazing grows out of psychology, the cult of complexity - from the engineering nature of our craft, while elitism among IT specialists is historical for the CIS countries. All this is bad stuff, leading to bad decisions, which means they should be squeezed out of themselves drop by drop.

The main arguments of supporters of Google-style interviews


"After all, you need to check the fundamental knowledge"


Are you so sure about that? Who exactly need? Here, nevertheless, is not a university department or an olympiad group; I suggest remembering why you are looking for a person at all. Right. Write API, design infrastructure, draw buttons, repair bugs, understand the task of communicating with the business, make the product more expensive and better. And do it all on time and for money.

The ability to deploy trees on a piece of paper does not help in any of these things (even, in fact, can interfere: take the focus from the product to "god-cats, we spent a week and made a custom JSON parser, it is 7% faster ." worked with such people.).


“Actually, this is required in practice.”



No, not required. Moreover, if I see a marge-request in the repository with a knee-length bypass of the graph or a custom implementation of the quicksort, I’ll reject such a request with a dude like 95% with a 95% probability , find a ready-made library . Not to mention the earnest desire to write your database.

As for some features of a language or framework, documentation is always at your service. (For trips to Cuba, Zeal / Dash was invented long ago).

Next must follow a mandatory remark about people writing the search engine Google / Yandex. But your developers are not among them ( You Are Not Google ), and they can perfectly read about a complex algorithm at the moment it is really needed. Everything is even more interesting: in such hardcore teams there is often such a special guy with a PhD in mathematics who helps developers with algorithms.

“If a developer is worth something, he can do it.”


This is not an argument at all in the context of the problem, but rather an attempt to establish yourself in the opinion that you are a good developer (and person). Leave this attempt, you are a good developer! (It's just likely to suffer from an impostor syndrome .) Go here, I will hug you ^ _ ^

In a moment of despondency, I recommend recalling Dan Abramov, who at one time did not pass on Vkontakte:

and hundreds of other similar examples (flashmob #metered in facebook).

More importantly, the right developer should know all your judgments should know XYZ , most likely, are an illustration of the survivor's error :



"We are not stupid to move the buttons on the view"


Understand. U.S. too. But you really overestimate the importance and uniqueness of your tasks. (I say this without even knowing your company: almost everyone overestimates.)

"In our company, everything changes frequently, so we are checking universally"


Let's be honest: it is universally impossible to verify a person. (IQ-test was a beautiful idea, but failed ). And knowledge of the algorithms here also helps little.

How often and how much does everything change with you? If your employees regularly and drastically change their specialization, then either you need it for some reason (say), or you should think about the processes. In both cases, it makes sense to check people for the required skills, and not for abstract ones. (If an iOS developer suddenly became a secretary, no problem - check it for print speed.)

If the changes are not so significant and not so frequent - well, the business will be learned by the person of the new framework. He has already proved to you during this time that he is able to work and study.

“We have such a stream of people who want to be employed, that we need serious filters”


Good, but filtering them with such interviews is to flip a coin.
You can suggest them to juggle - the correlation of the candidates selected as a result with their professional suitability will be almost the same as in the case of puzzles / whiteboarding (but at least save time).

“You sow ignorance! Perhaps this is due to the fact that you have not mastered the algorithms! "


On the contrary, I want to bring you reasonable doubt instead of blind faith in the trees as a working filter. Going to a person with “not mastered” is not an argument at all, in this article I tried to understand the problem in essence.

"But it was always like this."


... and this does not mean at all that the existing order of things is correct.

“I count O (f (n)) and with pleasure draw graphs on the board. Well, is it all for nothing? ”


Of course, for good reason. No one denies the usefulness of this knowledge. I only argue that it is not sensible to use them as an interview filter.

“But after all, on Google / Facebook / Zalando they continue to talk like that, how can I get there?”


Unfortunately, the world is not always arranged reasonably and expediently. If you seriously want the level of benefits that are given by the largest technology companies, you will have to jump under the millstones of their filters. And that means preparing day and night for a long time and years of trying. Decide whether it is worth it for you personally.

"And then what to ask?"


Now we're talkin '! It's simple: ask those things that the candidate will have to do with you. Ask the developer to design a tinder or uber. Discuss common problems with it in queues, serialization, sockets. Allow him to use the tools he is used to using.
And be sure to watch and discuss the code, be it GitHub or something written during the interview process.

By the way, you can add puzzles / algorithms, if you really want. Just consider everything that is written in this article.

How things are in EXANTE


When I got here, the developers invited me for a long dialogue. We were treated to cola, discussed my past projects, told in detail what the company was doing. I asked a number of technical questions. There was a lot of debate on the topic “why in this case there was such a decision, and not otherwise.” Including received a couple of questions on my code in the public domain. In the end I was given a puzzle from the category "How would you design an X". We also periodically watched the code on laptops.

Everything took somewhere around an hour (compare with the painful eight-hour interviews of one Russian campaign ). Interviews are conducted in the form of informal communication, and not interrogation - even in those rare cases when the whole team is present (sometimes you want to understand the reaction to a novice not only of the team leader, but also of the team members).

As you can see, no stress and full ability to show knowledge-skills.

By the way, we regularly look for people . We also try not to lose sight of them, even if we cannot take them right now. And we can friendly indicate the spaces, and then invite a few months later.

Changing the world is not easy, but necessary


Even when we discussed the problem on Twitter, the idea of ​​this article was in the minority among the Russian-speaking branch of the dialogue: only I and another Finnish CTO stood up to defend it. (New concepts generally reach the CIS with a traditional belatedness.)

There was such a wonderful Hungarian obstetrician Ignaz Philip Semmelweis . He first came up with the idea that 30-50% mortality during childbirth is caused by infections from the dirty hands of doctors. And he didn’t just find a confession: he was censored, ridiculed, placed in a psychiatric hospital. He died from beatings. Now Semmelweis is known as the founder of asepsis and the “savior of mothers”.

The world is changing for the better. It is possible that in twenty years, stupid interviews will be forgotten. Let's work on this goal!

I want you today to think about how you will be interviewing.

Things to think about


Source: https://habr.com/ru/post/335096/

More articles:


All Articles