What theoretical base is needed for a jun interview?

Question

IT education

Whatever vacancy you open for a junior (with very rare exceptions), everywhere in the requirements you will find the item "understanding oop / solid / grasp / yagni / etc. etc." Against this background, I have a question, in what form is such a theoretical knowledge of a junior checked? No, I understand that this can be answered with "well, you come and they ask you", but I just can't understand: almost all juniors (including me, of course) who do not have a cool technical (and even better - practical) background , describing, for example, the principles of SOLID or OOP, they will simply voice the memorized text and, at best, will be able to back it up with a pet project in which there will be a division into classes (and even more than 2) and, most likely, a minimal separation of logic between classes (than more methods in one class, the better and prettier). What exactly does the employer want to see in the interview with Jun in this regard? It’s just that no matter who I talk to from beginners (even with those who are already looking for work and even finding it), most say that they know all these principles and rules, but even I can see that this is far from the case, because in their works, they are not used from the word at all.
Now I'm just at a small crossroads, I've been studying php for 9 months (especially focusing on clean, consciously building a bunch of bicycles, so that later it would be easier to deal with frameworks and legacy) on the principle of "I write a project and study new technologies along the way to screw them there" , and now I really feel the strength in myself technically to go to try out for a junior, but I understand that my understanding of OOP with its principles, etc. to put it mildly, not the best, because of this I try to immerse myself in the theory and I can’t even finish one pet project, because I rewrote its architecture several times, gradually improving it. And all because it seems to me that when I get into a real project, I will only interfere with my shit building, constantly rewriting it at the request of the elders, if I don’t delve into it myself.
PS I understand that the question turned out to be somewhat vague, to put it simply: I want to know how exactly they are checked and what kind of knowledge in this area should a junior actually have?
PPS Yes, I know that very often a job description is made by HR, who was not really explained what kind of developer the company is looking for, and he just piece by piece collects the average temperature of vacancies by hh, so he shoves it there under a carbon copy.

Answer 1

A real understanding of OOP and patterns is not a junior level.
And yes - as you correctly noted - those who speak, in fact, just memorized a couple of common spells.
As aptly said in Pelevin's last book,

Manya was happy. That's what it means to be the daughter of a banker - dad did not explain, dad instructed how to explain to others.

Here are people who can explain, but they themselves do not understand, recently somehow a lot has appeared.
In reality, a purely mechanical part of OOP is required from a junior:
- be able to use ready-made classes, confidently access properties and methods
- know what the main magic methods do
- understand namespaces and autoload
- in general, confidently read the source code of classes - that is, do not be afraid of the words implements and use (which is traits and not namespaces)
- be able to use control-click in Storm

Answer 2

they will simply voice the memorized text and, at best, will be able to back it up with a pet project

- that's enough, everything else is a matter of price. All the same, when it comes to juniors, they choose the cheapest of the accommodating, the most accommodating of the cheap, and so that they can get along with the team. And then there are such juniors that no one wants to be their mentor or they ask for such an allowance for mentoring that it is cheaper for them to give this allowance for processing and not hire anyone.

Answer 3

1) Don't be afraid to get rejected. Every failure is an experience.
2) In most cases, they themselves do not know and do not comply with what they wrote in the vacancy.
3) The most important thing is to go into this business. It doesn't matter what hole you fall into for your first job. As soon as they start sending you tasks in which you swim, your skills will fly up because you will have to deal with this.
4) Popular abbreviations are easy to memorize, no one will require you to write a dissertation about their use. Because read point 2.

Answer 4

Well, in general, the algorithm of action is as follows:
1. You find a company that is looking for juniors.
2. You come there for social services.
3. Perhaps you are doing a test task.
4. If unsuccessful, repeat starting from the first point.
9 months of self-study and some pet projects are enough base to start going to interviews.
The main problem is in answering questions like yours: different campaigns have different requirements for the level of a junior in soft / hard skills. Therefore, only through social services you will be able to know the level of your preparation and pull up the sinking areas.

Answer 5

Buddy, in practice, things are even worse for some programmers.
I personally know people who develop serious projects on cool frameworks and make complex applications. But if you ask about oops idioms, he will tell you a maximum of two. And he hears about solid for the first time ....
And they have been working as programmers for more than 6-7 years, claiming a good salary.
So what am I all about?
You need to know everything, to the maximum.
In general, in medium-sized companies, they usually divide junior / middle / senior according to the level of responsibility for some part of the work.

Answer 6

Yes, you need a theoretical understanding. So that when they say in the review that he violated Single Responsibility, he would not ask for an explanation of what it was all about, and even more so, he would not begin to prove that his solution was better. It’s normal if a junior “floats” a little in understanding these principles (a clear understanding will come with experience), it’s not normal if he thinks that something superfluous is required of him.

Answer 7

when I get into a real project, I will only interfere with my shit building, constantly rewriting it at the request of the elders,

Not certainly in that way. Dzhun will not be allowed to shit building.
To begin with, there will be simple tasks - fix bugs, add / remove a parameter from the api, change the color of an element, replace one image with another, etc.
Architecture will be allowed when you grow up to the middle

Answer 8

asking for more is in our mentality an attempt to hit the ball)
what an amazing jun will be, who knows all this, the level is essentially a middle, and at the same time you pay him like a jun.
And this feature is more than offset by the fact that every yesterday's "I'll learn C ++ in 21 days" has not moved further than the four principles of OOP in understanding (not experience, but only understanding), and much more to say.

Answer 9

Don't worry, no company hiring a junior will let him into architecture. It will be a breakthrough if you have access to the master branch.
You will be given tasks of the level "run through the ready-made array with users and put them in the template."
In larger companies, you won’t even work on real projects in the first couple of weeks, you will have pseudo-real tasks that are very similar to real ones (maybe even once they were), but they won’t get into production, even if they are perfectly done .

Answer 10

June comes to you and says
"I have a task to make such a simple service that will do this and that, but I don't really understand how to start"
And you start explaining to him for an hour and a half what's what.
Or the second option - a jun comes to you with the same question,
And you answer him
"Here, use a singleton, here is a factory method, then you'll come up then we'll see what happens, then for now make a decorator with a stub."
And you can go and start working.
The specific implementation of various patterns is a huge experience.
But first of all, it's just common terminology.
Yes, of course, a pattern as a term and concept differs from a term like "interpreter and compiler" in that it is difficult to explain it in a nutshell - you need to spend time studying, and preferably also try to write a couple of objects for stuffing your hand.
But in fact, this is what a junior is required to do - to know the terminology at a sufficient level to save a lot of time.

Answer 11

it is better that he had at least some kind of practical basis in the end than theoretical