These toxic, toxic interviews
It all started when the author of Ruby on Rails confessed to the world:
Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I do not do riddles.- DHH (@dhh) February 21, 2017
He was joined by other developers:
@dhh Hello, I'm Rebecca. Whiteboards suck. I can not hold a marker for over a few minutes, I can type nonstop. I wrote Bard's Tale III.- Rebecca Heineman (@burgerbecky) February 28, 2017
One of Google's most senior engineers said that the devil does not remember how the qwissort works:
Hi, I'm Yonatan. I'm one of Google's most senior engineers, and I'll be damned if I can remember how quicksort works. https://t.co/yvofJHgCvG - (((Yonatan Zunger))) (@yonatanzunger) March 1, 2017
By the end of the day, tens and hundreds of various developers, including the authors of those products that you use every day, spoke out.
Such a flash mob may seem stupid to you, but it serves an important purpose: to demonstrate to everyone that it is normal not to put similar interviews. This breaks out spiral of silence .
How did this article come aboutFor me, as for many others, the interviews were regularly pain. (And once I also was afraid to walk on them.)
I wrote this program material primarily from my own experience: I had a lot of interviews in my life (start-ups, relocations). During the preparation of the article, I argued a lot with various developers on both sides of the barricades - both with candidates and interviewers. Now I myself, including myself, will interview other people in my projects and apply the experience gained. I have formed a definite position on this issue, which I want to share.
What kind of interviews are you talking about
quizzes ( "Which library function does X have a singularity Y?" )
puzzles ( "You were reduced to the size of a 5-cent coin and thrown into a blender.) Your weight has decreased so that the density of your body remains the same." The blades will start to spin after 60 seconds. ")
whiteboarding ( "whiteboarding" - when the code is required to be written on the whiteboard )
algorithmic ( "Expand the binary tree on a piece of paper" )
. @mxcl Did not you know? [Shayan Mohanty (@shayanjm) June is the most important thing in the world. 10, 2015
Than such interviews are harmful
Inspect people under stress who do not need to work under stressUnsuccessfully rolled out in production, someone from the developers broke the deadlines, shouted the seagull manager. Stress is everywhere, what can there be.
However, (if you do not work in public procurement) stress, as a rule, the situation is still atypical. And to check a new person precisely in conditions of an atypical situation is a somewhat insane undertaking.
You do not check the new bed in Ikea, throwing a cupboard on it? No, you lie down and imagine yourself sleeping on it. So why in the case of interviews do you do exactly the opposite?
The most wonderful developers I've met are nerds and geeks. They need quiet conditions. They need a flow state. In his best days such a person will encode you the most complicated task in a day. If you still want to test it for stress resistance, maybe instead of thinking about how to remove stress from your processes? (This will yield substantially more profit.)
Do not correlate with the developmentIncredibly, Google itself admitted that there is no correlation between how the candidate showed himself interview, and the way he went through the performance review in the process of work.
Are strikingly casual, putting you at risk of alienating a talented developer and taking a mediocreSuppose you are very well know some topic, and suddenly it pops up some quiz question. 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's much worse if you caught more than one unsuccessful quiz question, but several at once.)
Mastering the technical interview pic.twitter.com/14RlUgX0zU - The Practical Dev (@ThePracticalDev) January 12, 2017
Or, say, you write the code on the board, and the syntax has flown out of your head. How will it look from the outside - a problem with memory or with skills? Unknown.
Judging you in this case will be based on assumptions, and human assumptions are an incredibly random thing. They are often based on complete nonsense (for example, if you drink a lot of water, the interviewer may well perceive this as a sign that you are nervous or even lying about their qualifications.)
Elite unnecessary elitism and hazingAichi as a sphere of activity by its nature is incredibly prone to a number of stupid things:
cult of complexity ( If the solution is not complex enough or it was not enough for me, then something is not right )
elitism ( I'm better than them, I'm better than them, I've passed all the artificial barriers! )
hazing ( Gnobili, and I will )
The reasons for this are different, and one can argue about them. I will venture to say that hazing is growing out of psychology, the cult of complexity is from the engineering nature of our craft, and the elitism of the IT historians is for the CIS countries. All this is a bad thing, leading to bad decisions, so they should be squeezed out of themselves by drop.
The main arguments of the supporters of Google-style interviews
"After all, you need to check fundamental knowledge"Are you so sure of this? Who exactly is needed? Here, nevertheless, not the university chair and not the Olympiad circle, I suggest to remember why you are looking for a person. Correctly. Write an API, design an infrastructure, draw buttons, repair bugs, understand the task of communicating with the business, make the product more expensive and steeper. And do it all on time and for money.
The ability to unfold trees on paper does not help in any of these things (even, in fact, it can prevent: it will take the focus from the product to "pussy-cat", we spent a week and made a custom JSON parser, it is 7% faster " I worked with such people.).
Projects fail because someone can not make a RB tree, but because people do not know how to communicate and work together. - The backend developer (@ backendsecret) April 10, 2017 </ blockquote>
"Actually, this is required in practice"Nope, not required. Moreover, if I see a meurge-requester in the regex with a round trip of the graph or a custom implementation of the kvsort, I will, with a probability of 95%, reject such a requester with the mark dude, find the finished library . Not to mention the fervent desire to write your DBMS.
As for any features of the language or framework, the documentation is always at your service. (For travel to Cuba, they have long thought of Zeal / Dash).
Then follow the mandatory note about people writing the search kernel Google / Yandex. But your developers are not included in their number ( You Are Not Google ), and can perfectly read about A complex algorithm at a time when it is really needed. Everything is even more interesting: in such hardcore teams there is often such a special guy with PhD in mathematics who helps developers with algorithms.
"If a developer is worth something, he can do it"This is not an argument in the context of the problem at all, but rather an attempt to assert itself in the opinion that you are a good developer (and a person). Leave this attempt, you are a good developer! (Simply, most likely, you suffer from impostor's syndrome .) Come here, I'll hug you ^ _ ^
At the moment of despondency I recommend to recall Dan Abramov, who at one time did not go to Vkontakte:
I somehow tried to see you, but did not pass) Very happy, otherwise everything would have worked out differently .- Dan Abramov (@dan_abramov) July 6, 2017 </ blockquote>
and hundreds of other similar examples (flashmob # have been exchanged in facebook).
More importantly, all your judgments the right developer should know XYZ , most likely, are an illustration of survivor's errors :
The best software developers I know are always hacking over the holidays.True story.- Joe McCann (@joemccann) December 24, 2016
You can start a sentence with "All the best developers I know," as long as you end it with "& that's a great example of survivorship bias." - Sarah Mei (@sarahmei) December 25, 2016
"We do not have to push the buttons on the view in a dull way"I see. US too. But you really overestimate the importance and uniqueness of your tasks. (I maintain this without even knowing your company: almost everyone overestimates.)
"In our company, everything changes often, so we check universally"Let's be honest: it's impossible to test a person universally. (The IQ test was a beautiful idea, but failed ). And the knowledge of algorithms here also weakly helps.
How often and how much does it change? If your employees regularly and drastically change their specialization, then either you need it for something (let's say), or you should think about the processes. In both cases, it makes sense to check people for the required skills, rather than abstract ones. (If the iOS developer suddenly became a secretary, it's okay - check it for printing speed.)
If the changes are not so significant and not so frequent - well, somehow, the person will learn a new framework. He has already proved to you during this time that he is able to work and study.
"We have such a flow of people wishing to work, that serious filters are needed"Well, but to filter them with such interviews is to throw a coin.
You can invite them to pozhonglirovat - the correlation of selected candidates with their professional suitability will be almost the same as in the case of puzzles / whiteboarding (but at least time will save).
"You sow ignorance! Probably, this is due to the fact that you did not master the algorithms! "On the contrary, I want to bring you reasonable doubt instead of blind faith in trees as a working filter. Transition to the person with "did not master" is not an argument at all, in this article I tried to understand the problem on the merits.
"But it was always like this"... and this does not mean that the existing order of things is correct.
"I think it's O (f (n)) and I paint graphs on the board with pleasure. Well, all this is in vain? "Of course, not for nothing. No one denies the usefulness of this knowledge. I just say that it's unreasonable to use them as a filter interview.
"But after all, on Google / Facebook / Zalando they continue to talk like this, how do they go there?"Unfortunately, the world is not always arranged intelligently and expediently. If you really want the level of benefits provided by the largest technology companies, you will have to jump under the millstones of their filters. And that means training day and night for a long time and years of trying. Decide if it is worth it for you personally.
"And what should I ask then?"Now we're talkin '! It's simple: ask those things that the candidate will have to do with you. Ask the developer to design the tinder or uber. Discuss with him frequent problems in working with queues, serialization, sockets. Allow him to use the tools he used to use.
Valid responses to any interview question: "can you tell me an example where do you work in this company?" - Justin Searls (@searls) July 18, 2017And be sure to look 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 everything is in EXANTEWhen I was only here, the developers invited me to a long dialogue. They treated me with a Coke, discussed my past projects, explained in detail what the company is doing. I asked a number of questions on the technical part. There was a lot of debate on "why in this case there was such a decision, and not another." Including received a couple of questions on my code in the public domain. In the end, I was given a task from the category "How would you design X". We also periodically looked at the code on laptops.
Everything took somewhere around an hour (compare with the painful eight-hour interviews of one Russian campaign ). Interviews take 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 the newcomer not only the team but also the team members).
As you can see, there is no stress and a full opportunity to show knowledge-skills.
By the way, we regularly look for people . And we try not to lose sight of them, even if we can not take right now. And we can give friendly terms to the gaps, and then invite them in a few months.
It's not easy to change the world, but it's necessaryEven 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 for its defense. (New concepts generally reach the CIS with a traditional delay.)
The world is changing for the better. It is possible that in about twenty years the stupid interviews will be forgotten. Let's work on this goal!
I want you to think about how you are going to talk today.
|Vote for this post
Bring it to the Main Page