Healthy person interview

This article was written as a response to the article “Interview at Dodo Pizza” by a developer with Signor experience. I do not pretend to be true judgments, I would like to express a rather popular opinion among my friends about the hiring process in particular and the life of the developer as a whole.

First of all, let's decide who the lead developer is, at least as I understand it. The lead developer, also known as Signor, is a developer with many years of experience (10+ years) who managed to work in several offices on several projects. Over his rather big career, such a developer most likely saw both terry legacy and smoothie startups and a bloody enterprise.

  • He does not believe in any transitions to .Net Core, monolith splitting, microservice approach and high loads. Because it was promised to him many times already, but in fact the code base was a poorly structured bad code, and the high load is 100 orders per minute.
  • He does not believe in all sorts of flexible methodologies, which in fact boil down to the lack of TK and incompetent managers who set tasks. Oh yes, and that same age coach without a technical background with 2 years of experience who explains how to work.
  • He does not believe in any spirit and values, because they immediately disappear somewhere when the revenue ceases to grow and there is an urgent need to look for the guilty. For these guys, with the systematic error of the survivor, do not stop believing that they are cool managers, and not just lucky.
  • He does not need Friday get-togethers in a free environment, barbecue and team building trips, as he most likely already has family and children and wants to spend free time with them.
  • He does not need free energy drinks and sandwiches in the office, since he would rather eat a tasty and healthy dinner at home than feed him with this chemistry.

Before you say, well, they say, what a capricious, everything is not right for him, let's figure it out, but what does the leading developer usually want from the company?

  • He wants adequate management. So that the project manager understands his subject area and, preferably, a little more understanding of the development. So that obviously unfeasible features are not promised to customers.
  • He wants to work according to agreed requirements. And not because he is so finicky. But because he understands that the requirements determine the architecture and terms of implementation, and changing them can lead to the fact that the architecture will need to be propped up with crutches, since no one will give time to change.
  • , , , , .
  • , . , , , CI/CD, .
  • , , .
  • , , , , . , , , , 50% . .

Now, having decided on the introductory, you can move on to the topic of a healthy interview.
So how can you interview such capricious creatures as leading developers?

Communication with HR is probably a necessary item and, probably, it is necessary to start with it. The main goal here is to discard obviously impassable options in order to reduce the burden on people conducting technical interviews. This is essentially the only goal, because I personally saw a couple of times in my lifetime how adequate in communication people flew off the coils after six months.

According to a technical interview


To begin with, why is all this being asked? Most likely, all this is necessary only in order to protect yourself from incompetent employees. But do you seriously think that a developer with ten years of experience, who worked at least 1.5 years in each place, successfully deceived everyone for ten years that he could not write code? And if so, why are you sure that your technical interview will figure it out?

Why are all these tree traversing algorithms needed in an interview? Will he write these trees or sorting algorithms in prod every day? Yes, we have a pizzeria, our orders at 23.59 turn into a pumpkin, we are not talking to Boston Dynamics here.

Here, in my opinion, it would be much more useful to just talk with a candidate for life, assessing the degree of his immersion in the problem. It’s one thing to say, well, I used X technology on the project, and it’s quite another thing to find out from the candidate that there were such and such problems that they solved so-and-so. This allows you to evaluate a person’s experience much more than repeating standard algorithms before an interview. It is also necessary to consider that all people are different and for some the interview is a lot of stress. When several detectives begin to pry out something, it usually turns out even worse than when one (if the goal is to take an adequate person). During the conversation, you must honestly tell the real situation in the company, who sets the tasks, are there development standards, CI / CD and so on.

Actually, that's all. These two points are quite enough to hire excellent employees, which my colleagues and I have seen from my experience more than once. If your process is stretched by 5 steps, if you have dozens of developers, and CTO is interviewing, if you are interviewing in person, and you need a test day, then something is broken. So here somewhere someone’s ambitions or complexes are hidden, someone is trying to copy the “best” Western samples without really thinking about why this is done. This also includes that marketing bulletite about culture and values. I don’t know if this affects the Jones and Middle, but believe me, the Signorers are well aware that this is a big deal. And if the employer tries to hang a lot of noodles on the ears, then at some point the internal bulshitometer works and the candidate falls off.

So, in my opinion, the secret to successful interviews is simple.

  • Appreciate someone else’s time
  • Tell the truth
  • Do not ask anything not related to direct labor
  • Learn to listen to the candidate

And you will be successful.

All Articles