When I decide which application architecture to choose, or how to design a database, or what preparatory work is needed to start, or what to write in the next block of code, I think. I think about what I want to get, how it solves my problem, are there any better solutions. Agree, this approach will be useful in many areas, and not only intellectual work. But in this article I want to talk about interviewing IT specialists. Moreover, specialists with experience, Middle level and above. Get ready, I'll be a little sarcastic.
Why did I decide to write about this?
I took part in a number of interviews when I was interviewed. I must say right away that I still have the feeling that preparing for an interview is technically dishonest. But we can discuss this in the comments. A couple of times I skipped the interview over a couple of simple basic questions. After that, I reproached myself for incompetence. How could I aim for the big league if I could not rant the principles of OOP? Later, the protection worked and I began to think, but do I really need to know this as a schoolboy the multiplication table?
The specialist must know the basic theory (?)
OOP, SOLID and a whole bunch of principles without which development will come to a standstill. If you are hiring a computer science teacher, be sure to ask all this.
But, you take the developer. Should he know this? Let's figure it out.
Should he understand this? Yes. But how can you check? The easiest way is to ask. That is, he must know. In the end, a student who has just graduated from a university will be able to answer ideally to the theory. But that doesn't mean anything yet. Or should we try to find a way to check how he understands them? Fortunately, these principles have the most direct practical application. Maybe we should offer him a couple of simple tasks? After all, at work, he will solve problems.
The specialist must know how the tool with which he has to work (?)
Undoubtedly. For this, abstractions were invented, so that every time you think about the details of the implementation. If you think so, then I advise you to study the issue even deeper, to the principles of the processor and semiconductors.
, , , . , , . , , ? , , . , . , . , . , .
, ?
. , , . , .
/, .
:
- , . . . . ?
- / ... , / + 1... ... == ? % == 0... - , . , . !
- , .
- ?
- , .
, . , , . . , . , , .
, . , . . . : " ?". , , -, . , , " ". , .
. , , .
: " C#".
, - .
- , ?
- , !
- . ?
- !....
, , Comedy Club. - : ", , , . ".
? , . , . , . , , , . , - . , . , , .
. . , , , , . - . , , .
, . .
? , . SOLID. , ( ), , , . , .
, , , . , , .
, .
Questions about basic theory should be left to junior specialists. Serious guys need a serious challenge.
A serious challenge is trying to balance between several not entirely correct decisions in order to choose the best of evils. Set application tasks.
Think carefully about why you are taking a person. What tasks should he perform. From here the tasks themselves will take over.
That's all. You can applaud, you can throw stones. I will endure everything. But I really hope that you did not want to pass by.