How to enter IT: a new set of HeadHunter School of Programmers

Hey. My name is Leo, and I am a developer at HeadHunter. Want to know how I became them? Perhaps, I will start from the very beginning - when my youthful acne could be compared in number only with the hours spent playing the playstation. Some forces of the universe (moms, dads, thank you :) I started working in an investment bank and traded currencies, stocks, bonds (yes, like in the movie “The Wolf of Wall Street”).

At first, life in the bank was rather boring: a lot of manual labor and pretentious, old-fashioned brokers who thought only of their commission.
')
Everything changed with the arrival of programming in my life. Manual labor went into the background, I started writing code that did my work. At first it was simple and straightforward, but over time it acquired complex case studies. Then, at one point, “something went wrong” and the bank lost a huge bunch of dough. So I learned that plastic surgery is expensive and painful development is not only code, but also testing, quality control and other interesting and extremely useful practices.

It became clear that knowledge is not enough and you need to learn. I went to well-known resources in search of knowledge, I took several courses at coursera.org, I even finished the specialization Fundamentals of Computing. But this was not enough for me, I wanted to communicate with real people from the IT industry, and then I came across a post about recruiting to the School of Programmers HeadHunter 2014/2015, which I successfully entered.


Approximately such topics had to be studied during school.

I note the most useful, in my opinion, lectures.

Development Methodologies

In the lectures on the development process, I received only theoretical knowledge, which, in principle, can be found online or in books. The main value is the practical experience that I gained during the team work on the project. We had stand-ups twice a week, demo for customers and retrospectives. We learned to work as a team, to trust and help each other.

Engineering practices

At lectures and homework in engineering practice, I gained practical skills in refactoring code, TDD, unit testing in general, CI, and, of course, review of code. These skills helped to successfully cope with the team project.

Command line

One of the very first lectures turned out to be quite difficult for me, because before that I had never worked in the console. There was a lot of material, and bash is not the most obvious language, but practical tasks helped get a little comfortable and start using the console as a convenient tool.

After the course of lectures, a team project followed - we did Slack for HR, which is highly integrated with the HeadHunter API. During the project, we all proved to be a good side and each received an offer to work at hh.ru, which I gladly accepted and went to work.
In the first year of work at HeadHunter, I went to help my home school, participated in the interview for beginners in school. It was an interesting experience - to watch how a person thinks, to calm him down, to help him look for options, and not to be nervous and fall into a stupor because of a difficult task. After all, the main thing that we look at at the interviews is thinking: if you don’t know how to solve the problem, you have to ask questions, talk, move forward, and there, look, and get out for an answer. Of course, without basic knowledge, for example, what O (n) or a stack is, it is practically impossible to pass, but this is only the basis on which to build your thinking.

In the next school 2016/2017 I gave the first lecture on engineering practices. Performing in public is not easy, and everyone knows that. We had an internal seminar where all beginner lecturers are taught how to speak. We trained how to stand and gesticulate correctly, in what rhythm to speak and how to hold the attention of the audience. The training greatly helped in preparing for the lecture and in the speech itself. You begin to understand everything even better, in more detail and more precisely, when you tell others. Scary of course, but very interesting) I received feedback, this year the lecture will be even better and there will be more of them, come!

As I already wrote, schooling is divided into two phases: lectures and practical tasks.
At school 2016/2017 I was lucky to be the curator of one of the projects. The project curator is a rather vague position; here everyone chooses which role to play in the team: product manager, project manager, or team leader.

Product manager

Most of all he knows what the product will look like in the end. Able to prioritize individual tasks. Decides in terms of what to do and what not.

Project Manager

He organizes the work of the team, organizes processes - stand-up, retro, demo, etc. It helps to solve organizational issues.

Timlid

He organizes the work of the team from the inside, is responsible for the technical side of the product. He acts as an assistant to any member of the team, and if he does not possess technical expertise, he knows who to turn to for help.

I chose the second role and a little first, giving the role of team leader to the team itself. Our team was engaged in a project with the code name Checker. The main goal was to automate checks of entrance tasks from applicants of the School of Programmers. There were 5 people in the team and I, the manager :) We found our customers among the people who devoted the most time to school. Work with the school begins long before its opening - these are lists of lecturers, site uptime, marketing support, and much more. But even more effort is required to check the applicants' forms, to give them test tasks and to have a conversation. We collected these activities, analyzed the pain, prioritized, decomposed into separate stages and tasks and began to work. I tried to incorporate into the work all the main practices from hh.ru (revision code, stand-ups, task decomposition and its evaluation, personal responsibility for the release date, demo, retro). We did something like Scrum with 4 weeks of iterations and demos after them.

After each demo, we made retro and improved processes. Retro - in my opinion, one of the most difficult meetings in the whole development process. In order to conduct it qualitatively, you need complete trust within the team, you need to be on the same wavelength and be ready to change and progress. Our first retro pleasantly surprised me with a good working atmosphere, a number of honestly expressed problems and effective ways to solve them, which we took to action.



Many thanks to the guys who really grew up, became cool developers. It's great that my whole team has reached the end and we are all working together now at hh.ru!



Our project will be the first project in 7 years of school, which will reach sales, now the new applications will be checked by a robot with a part of former students, so it is not very angry and harsh))

I am still in our school. At first I was a student in it, I helped to interview the children, became a lecturer, then a project manager and now I am a curator. The school is a very multifaceted project, in which, if you wish, you can gain tremendous knowledge and experience that helps to move further in its development. I chose the path of the team leader, others choose the path towards working with technologies, and both paths can find a basis in the school of programmers.

We are starting a new set of 2017/2018. This year we are waiting for 30 students, come!