Good day! My name is Vassen, I am a beginner backend developer who has set a goal to retrain from an economist to programmers from scratch. I started training at the end of September last year and at the moment it turns out that exactly six months have passed since the start of the journey. Everything is fine, I have not yet rolled in and it is not known when I will “roll in”, I realize that a lot of things remain unexplored, in which areas I have only very superficial ideas and just continue to study further.
One way or another, the difference between understanding basic things now and then, at the start, is huge, and in such a short time period I managed to fill a couple of bumps, get some kind of experience, understand what I was wrong about and I can warn fellow travelers from repeating my errors. Also, this article is a kind of answer to my own question from the last article, where I was worried about the fact that I have so few completed projects, about an empty github profile and I don’t know how to evaluate my progress. At the same time, advice to beginners on how to learn more effectively, improve their practical programming skills, gradually filling out their github. So, what mistakes did I make during this time and what was wrong.
At the very beginning, like many others, I probably made my own route. There are many different ways to visualize this, a lot of articles have been written and videos have been shot.
So, the main mistake is that no matter how it seems to you at the beginning, the roadmap is more of a guide than a route and you should not take it too seriously and categorically. According to it, you can only prepare for some kind of quiz, where you can shine with the number of technologies you know, rather than their understanding and deep knowledge. Well, purely formally, of course, you can write down work with various databases in your portfolio if you raised them to some kind of ORM and wrote a couple of cruds, but this knowledge is unlikely to impress someone at an interview. Add to this the fact that some things interchange each other and it turns out that some unrealistic number of projects is needed purely for show in the resume and only Cthulhu knows how much time it takes, and I doubt that this is a rational waste of time.
Personally, I have such an association. Imagine some
interface an abstract large orchard where you can pick any fruit or berry. You enter it empty-handed, the exit is in front of you, and you can’t say that it is somehow very far away. You need to go through the garden so that at the exit you have as many fruits as possible in your hands, so that somebody at the exit, he could make a full-fledged drink out of them and sell them. Which one? Yes, it is not known, maybe fruit drink, maybe a cocktail, maybe compote. What kind of fruit is needed for this someone? Yes, it is also unknown, but the main thing is that their there should be enough to make some kind of drink. As you probably guessed, “so much is how much?” also does not have a specific answer. The garden is abstract, after all. Forgot to introduce this somebody – your potential employer, who decides whether you have enough fruit with you. Each fruit is some kind of stack, framework, library or some kind of approach that you must own in sufficient quantity. So try to carry in one hand a couple of watermelons, a dozen apples, a handful of gooseberries, etc. While you are walking from bush to bush, you drop something and lose it, while you still need lemons, currants, melons. And you also have to be friendly, don’t forget, we are pumping soft skills, periodically shouting out from under the bush about our successes, the employer wants to know how you make this or that decision, how you think, are you ready to work in a team…
I think you got the idea that you can’t take everything away and there is no road as such. Determine what is asked more often, how much is usually needed and learn exactly this, rather than taking on everything at once or going only one single route. And the second thought is that some things are worth understanding and using before they are in this scheme. The most obvious example is Dependecy Injection, it comes from Dependency Inversion, it comes from SOLID, which comes from… from the house that Jack built. Seriously, you won’t be able to understand most of the articles and other people’s code if you don’t understand what kind of beast it is, why it is, what a dependency container is. Therefore, immediately after studying the base on the language, gnaw DI until you bite through to the state of using it on the machine.
My mistake was that I put off litcode tasks for a very long time. Here, of course, there are a considerable number of people with experience who will say that the litcode is not needed and it was useful to them exactly 0 times in their work and they will be right. But they already have work and experience, which is much more valuable than the ability to sort arrays and recursively traverse trees, and we, beginners, must somehow compensate for the lack of such dignity as they have, in order to show everyone at the interview so that everyone gasps and offered an offer. Put yourself in the shoes of an hiring person who gets hundreds of responses with + – the same resumes for a vacancy of a back-mid-junior, how to weed out the least suitable candidates? It is quite logical to drive a little on algorithms. At least I think so, I can be wrong, of course, but for some reason, more and more often I see in vacancies a requirement for knowledge of algorithms and data structures, or a mention of passing such testing at an interview. Therefore, since learning from scratch is a rather long undertaking, and there are many even simple tasks on the litcode, it is worth starting to solve them as early as possible. At least by solving one a day, in six months you will already have a solid number and an understanding of these very algorithms fixed by hand.
I regret that I did not take on the litcode for a long time, I started solving only a month ago and I have few tasks, but this month I have already realized that:
– I began to better understand basic algorithms and find solutions to problems, which is a little emotionally pleasing and gives confidence (I remind you that I am an economist, and my understanding of algorithms and their effectiveness was absent initially);
– the quality of the code is improving and primitive skills are being fixed: with each solved task, I increasingly place adequate indents and spaces, brackets, which I didn’t do initially (and now it hurts to look at the first projects), and it has also become easier to work with LINQ expressions, although a few months ago all these lambdas seemed to be some kind of extraterrestrial matter;
– I get used to routine things: I solved the problem, created a commit, added information about the results, updated the repository. It comes to the point that when it was not physically possible to solve problems, I felt some kind of tension, that for two or three days I had not solved anything new and had not updated the repository. In general, there is some kind of excitement, focus on results, which also has a positive effect on learning.
And if we leave aside the connection between the interview and the litcode, then for oneself this is an excellent indicator of educational progress, naturally within reasonable limits and without fanaticism, because the goal is to gain new knowledge and consolidate it, and not to get some kind of achievement.
The more problems you solve, the easier it will be to do it in the future, start reading books on algorithms, they will lead to new questions about resources, about optimization and efficiency, which in turn will lead to things like immutability, for example.
Responses to vacancies
Okay, who are we kidding, rejections are always unpleasant to receive, and often the moment “X” is postponed for later. And when it comes to an interview, it somehow even becomes embarrassing to apply for vacancies that require at least a year of commercial experience and a bunch of other things to know and be able to use for their intended purpose. I planned to go first to some level, I understand that it seems that I began to understand the most popular things quite well, you see – and they will be rejected less often. But now the realization has come that it was not worth doing this and it was worth spamming for all open vacancies and maybe a little more. For what? So that at least someone from this list would give you a test task. At the current stage, getting at least a test task is already progress, because you get some specific task that needs to be implemented, while you usually need to do it within a limited time frame and do it with the highest quality. Well, ok, they want to check the knowledge of some basic things. And this task (ideally, of course) will be checked by someone for the result and quality, and if the stars converge, you will get feedback. And this is now very valuable and more productive than any of your own projects, which usually no one watches and evaluates except yourself (objectively and impartially, of course)
Experienced developers will say, of course, that it’s not a royal thing to solve test problems, but we keep in our heads about dignity and its size, right? Therefore, we are now looking for any opportunity to get some kind of task and try to solve it. For example, I recently implemented a full-fledged RESTful API service for playing tic-tac-toe. For some, this is nonsense and elementary, I understand, but for me personally it was necessary to solve such a problem, because it is a challenge and I have not done such things before.
We also include all hackathons that have requirements, conditions and deadlines there, we get used to it from a young age. As an example, quite by accident I found out about this hackathonin which he took part. It was only thanks to him that I learned about such a thing as the .NET Graph SDK and spent most of the time studying its API and documentation on how to register my application with Azure and enable Active Directory authentication. Therefore, there was almost no time left for the application itself, and I didn’t come up with anything smarter than to make a prototype of an email client (consider just a page with the latest letters and attachments to them), which calls ChatGPT inside itself and translates letters into English, and also overtakes voice attachments to text. Let’s just say that I took a basic express course on Azure and got experience that I didn’t count on initially, as well as plus one more project in the repository.
Do not ignore activities, participate wherever you can, even if you lack knowledge – get it as the train moves.
If you managed to read this article to the end, then thank you for your attention and I really hope that my advice will not be harmful and will help in further learning. To summarize, the theses came out as follows:
If you have compiled a developer roadmap, use it as a guide, not as a strict guideline. And pay attention to Dependecy Injection as early as possible.
Start solving litcode problems as early as possible. Save the result of the solution to your github, so you can track your progress, which will give you an incentive to continue learning.
Apply to vacancies, even if you do not meet the requirements. Your goal is to get a test problem, practice problem solving. And participate in hackathons, they give invaluable experience at the initial stage and replenish your github profile.
In addition, I wanted to inform you that I am open to any projects and proposals, I am looking for experience as a back developer. Are you front with a cool idea? Write, I will do some project for several people. Do you have some kind of problem that you can shove onto someone? Super, it will be very interesting to try your hand.