Once again, after several interviews, I thought about evaluating the developers. The shift towards “strong” developers is clearly visible, whole teams of seniors are gathering. But here is the problem - there is gradation, but there are no clear criteria. How to distinguish a middle from a senior? What does june need to know in order to get a new title? You can write another text about knowledge of algorithms, the ability to solve problems independently, or you can approach the question from the other side: to evaluate not the level, but the path. The quality of problem solving is still determined not by bubble sorting and not by years behind the monitor.
So in the beginning everyone is equal. There is basic knowledge, no commercial experience. But, having received the first job, the beginner begins to move along one of the roads.
Mold sleeper
Copy-paste rules the world, it’s foolish to say that nobody does it. What is the difference between form-sleeper and others? The fact that he does nothing else. There is a standard algorithm: a typical task is the Internet (raywenderlich, medium, stackoverflow, ...) - mindless copying - closing a task. The trouble is that the task is not analyzed, and decisions are not evaluated. A person can copy the code for years and the whole development will be reduced to the speed of transfer. And if the variety of tasks is low, then the person will become a master of copying molds. Nothing will stop him from proudly fastening on himself the title of Senior in 5 years, although, if to speak objectively, it will be a maximum of middle.
Practitioner
What if? Such a question does not allow a person to simply do the task. What if we take a different solution? What if a different approach is taken? How does it work inside? And so on and so forth. Curiosity makes you write code, a lot of code. And over time, the quantity begins to turn into quality. The code is becoming cleaner, more universal, more scalable. When a book / article on approaches to development falls into the hands of a person, he is only surprised, because he himself used all this for a long time.
Theorist
All the same, but vice versa) If you solve a problem, why not read how it was solved before you. As a task, it’s not just to solve, but to do it right. And the theoretician studies the experience of others' mistakes so as not to stuff mistakes himself.
The trouble is that what is described is spherical horses in a vacuum. Each developer has all three, and the purpose of these chaotic thoughts is to encourage to evaluate not by mythical levels, but by the ratio of approaches. And first of all, ask who exactly is needed. If there is a large stream of similar simple tasks, the form sleeper will do better than others. There is a need to solve complex problems - I would advise a theoretician, it will be easier for him to study small details and to understand the essence of the process. If the tasks are complex and require speed, then a practitioner will obviously be needed.
Now a little about the direct interviews. It makes no sense to ask for algorithms, SOLID, ask for code examples. Interviewing and code writing are not the same thing.
If you need a theoretician, ask that he read the last, which of the reads made the greatest impression on him. Or maybe he disagrees with something and has his own vision?
If you need a practitioner, ask about your projects. About interesting tasks. About the technologies and libraries that were used and why.
If you need a form sleeper, then the best indicators will be years of experience and a variety of tasks.