Hello!
I liked your vacancy and your company and your ideals of corporate culture so much that I decided to offer you my humble candidacy. Here is my super-unique resume, send me a test, and we can also talk for an hour or two so that we can roughly understand whether we want each other.
Preamble
I have been working as a programmer for a long time. It so happened that I happened to be on both sides of the "barricades": I went through at least a hundred interviews, more often being refused and conducted at least fifty interviews, more often than not.
Usually I was interviewed by two people: a manager / boss and a programmer / techie. Less often - one, even less often - three or more. As a rule, they ask questions from completely different areas, so let's conditionally divide the interview into a test task, inspecting soft skills and inspecting technical skills.
Test
It is unlikely that I will send the solution back to the test task, if I do not verify that it is working and fulfills the task. Accordingly, another programmer receives for verification, basically, only working solutions, among which he must choose those that, according to his assessment (opinion), are quite suitable. Having worked with many programmers in a team, I know firsthand about their fierce intolerance of other people's code, to someone else's train of thought. Therefore, even if you offer them a better solution than could ripen in their head, you run the risk of running into misunderstanding and refusal. At the same time, when asked to describe the reasons, you can get both a completely leftist nonsense (once they reproached me that I sent the task in the archive, and did not publish it on my github, of course, I will dirty my space), and a complete ignore. Therefore, playing a test task is actually a game of "please another techie you know nothing about," that is, a great random.
By the way, by the order of the test task and the interview, you can catch the relationship in the firm between the manager and the programmer. If you are asked to solve a test task before the interview, then the manager considers himself to be more busy than his subordinates, tries to save his time to the maximum by delegating the basic check. If you are asked to solve the test task after the interview, it means that the programmers in the company currently have such a heavy workload that they are not even distracted to check the test tasks of random people. You can catch even more relationships if the interview is done in stages, first with some people, then with others. I hope you grasped the essence.
Checking soft skills
"Tell us about yourself?" - a question that puts a person with a deeply technical mindset into a stupor (hereinafter we will call him a constructor). A designer can dump his name, age, height and weight, nationality and eye color after a little digging in his memory, but at the same time he will not understand what all this has to do with the case, because he came to sell his technical skill, and not himself. "What exactly do you want to know about me?" - I usually answer and see disappointment in the eyes of the boss, the boss rarely likes when he is answered with a question to a question, because now the ball is on his side and he has to think. If I thought differently, then of course, I would have dumped on him a pre-prepared savory story of my beloved with detailed details of how cool, cool and, most importantly, better than others I am. But if I thought differently,I would hardly become a programmer. Therefore, in response to the answer “what you want and tell me,” I start to stupidly list where I worked and what projects I was involved in, plus what technologies I used, what makes my next mistake, since all this is already written in the resume and does not cause anything but boredom. After all, words cannot convey the volume, weight and significance that I feel in my head.
And here I make an assumption: let's say that a programmer SHOULD NOT have strong soft skills.
Let's go from the opposite: let's say that a programmer MUST have strong soft skills, then why do we need a manager? Why then do I need a company if I can go to the freelance exchange and find myself a customer there myself? Mr. Ford is a great inventor of the last century, he invented the conveyor, an incredibly efficient thing that, apparently, not everyone has yet learned to use. In some companies, they cut this trick and inserted a special link between programmers and customers - managers, who are essentially translators from “human” to “programmer”. The manager's task is to agree with the programmer and the customer, the programmer's task is to “agree” with the code. Expecting an additional advanced skill from the programmer to negotiate and communicate, you cut off those programmerswhich, due to the absence of these soft skills, freed up enough space in their head to pump their development skill much deeper.
Let's imagine that we are interviewed by a company that understands this idea. Nevertheless, she still wants to evaluate the general sociability, simply in order to weed out people who are completely incapable of teamwork. How can this be done effectively in 1-2 hours of conversation? None. I have not seen a single person at the interview who behaved dissolutely, disrespectfully or inappropriately expressed himself, and this is natural, because at the interview we are all as open as possible, friendly and adequate. Therefore, having passed thousands of interviewees through himself, the interviewer begins to pay more attention to other details: how the person is dressed, what hairstyle he has, how he smells, what grimaces he makes, what emotions he shows, what gestures he uses, how long he looks into his eyes, how often looks away, how quickly he answers questions.And he forms his final "expert" decision, in fact, on bare intuition. After all, he is faced with the task of “choosing the best at the moment”, and not “weeding out the suitable from the unsuitable,” and he cannot go against this task.
The assessment of the speed of reaction is a separate mistake. Instant responders don't really even have time to think. People who slow down with the answer, on the contrary, plunge into the palaces of the mind, carefully weighing all possible options, until they feel that it would be appropriate to think a little more. Even if they immediately have a suitable answer.
Testing technical skills
It would seem that technical knowledge is orders of magnitude more important than communication ability, but in fact, rarely does a company arrange an interview in such a way that the technical part is superior to the social one. There are, of course, exceptions, once I had the opportunity to communicate for 4 hours with a very friendly techie, from whom I learned a lot of interesting, but useless tricks in my real life.
So, is it really possible to evaluate a person well enough in 1-2 hours of conversations to make the right decision? Of course not. The most important mistake here - exactly the same as in the previous part - is the task of finding the best, and not weeding out the right ones from the unsuitable ones. As a result, the interview turns from a search for knowledge into a search for gaps, because the more gaps the interviewer finds, the less suitable the candidate is and the easier it is to add-subtract-calculate virtual points. An additional mistake is that we check that the candidate has only the knowledge that we know ourselves, completely losing sight of the knowledge that we do not know, which could be much more useful in the company than another copy of me.
Particularly slippery in what is happening is that the inspection turned into an exam tests not the candidate's ability to program, but his ability to explain, convey, teach, that is, in fact, the same test of communication skills in a different plane. For example, I can quickly and efficiently design a normalized database structure or normalize an existing one, but I am completely unable to explain in words to another person how to do this, because when I normalize, I do not use Russian words, I use internal knowledge that I have not acquired. in pairs at the university, but on "combat" experience. Not everyone understands this skill difference between performer and teacher. Another canonical example is confusion over design patterns. Maybe I know the pattern that you ask me,but in my head it is called differently and its implementation may be slightly different.
Especially what I dislike is the inspection of very small and super-specific details, which belong to Google, not in my head. What is the third parameter in the bubble sort function responsible for? Arrange the queue in two stacks. How to make a selection so that not so, but like this? Of course, it's good when these details are in the head, the programmer saves time, and the company saves money. But what you will never learn by asking such questions is what lies in the candidate's head INSTEAD of this knowledge, knowledge of such low value. Perhaps there is a deep understanding of asynchrony, or maybe the skill of rolling up to girls at parties, but the question has been asked, the time has been spent, the interview for the next step is close to its completion, and you have scouted out little meaning.
I don't even want to talk about requests to compile the code from paper in my head. Are you looking for a programmer or a compiler / interpreter for a position? In the day-to-day work routine, a programmer is used to relying on the environment, using its capabilities to the maximum, saving his "processor" time where possible. Therefore, it is not surprising that such tasks are performed slowly and often incorrectly. Instead, it would be better to ask what media he uses and what he likes about them, maybe you will find something new and tasty for yourself.
Is there a way out?
If you set out to save on brains, I'm sorry, you will continue to skip the necessary frames in pursuit of the best. I can only draw your attention to the fact that good brains are almost constantly looking for a better place than their current one, so losing the “best” brain is as easy as “finding” it.
If you have enough budget, you can try the following trick: offer 1 trial month of work to everyone for half the rate and decide on the results of the work. It can be combined with preliminary interviews by switching the task from finding the best to finding suitable ones, but remember that interviews of this kind are practically useless and only take time.