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

    Hey. My name is Leo and I'm a developer at HeadHunter. Want to know how I became one? Perhaps I’ll start from the very beginning - when my youthful acne in quantity could be compared only with the hours spent playing the playstation. By some forces of the universe (mom, dad, thank you :) I started working in an investment bank and traded in currencies, stocks, bonds (yes, like in the movie “Wolf from Wall Street”).

    At first, life in the bank was rather boring: a lot of manual labor and pathos, old-fashioned brokers who thought only of their commission.

    Everything has changed with the advent of programming in my life. Manual labor faded into the background, I started writing code that did my job. At first it was simple and straightforward, but over time it grew into complex cases. Then at one point, “something went wrong” and the bank lost a hefty pile of dough. So I found out that plastic surgery is expensive and painful to develop - it is not only code, but also testing, quality control and other interesting and extremely useful practices.

    It became clear that there was not enough knowledge and needed to learn. I went to well-known resources in search of knowledge, took several courses on, and even completed 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 a post caught my eyeabout recruiting to the HeadHunter School of Programmers 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

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

    Engineering practices

    At lectures and homework on engineering practices, I gained practical skills in code refactoring, TDD, unit testing in general, CI, and, of course, code review. 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 to get a little accustomed 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 showed ourselves on the good side and everyone received an offer to work at, which I gladly accepted and went to work.
    In the first year of work at HeadHunter, I went to help my native school, participated in the interview of newcomers to the school. It was an interesting experience - to watch how a person thinks, to reassure him, to help him look for options, and not to be nervous and stupor because of a difficult task. Indeed, the main thing that we look at during interviews is thinking: if you don’t know how to solve the problem, you need to ask questions, reason, move forward, and there, you look, and you will come out to the answer. Of course, without basic knowledge, for example, what is O (n) or a stack, it is almost impossible to pass, but this is only the basis on which to build your thinking.

    At the next school 2016/2017, I gave the first lecture on engineering practices. Speaking in public is not easy, and everyone knows that. We had an internal seminar at which all beginning lecturers are taught how to speak. We trained how to stand and gesticulate correctly, in what rhythm to speak and how to keep the audience's attention. The training greatly helped in preparing for the lecture and in the presentation itself. You begin to understand everything even better, in more detail and more precisely, when you tell others. It’s scary of course, but very interesting) I received a feedback, this year the lecture will be even better and there will be more, come!

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

    Product manager

    Most of all he knows how the product will look in the end. Able to prioritize individual tasks. Makes a decision in terms of what to do and what not.

    Project manager

    He is engaged in organizing the work of the team, arranging processes - stand-up, retro, demo, etc. Helps to solve organizational issues.


    He is engaged in organizing the work of the team from the inside, he 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 have technical expertise, he knows who to turn to for help.

    I chose the second role and a little first, giving the role of team lead to the team itself. Our team was involved in a project codenamed Auditor. The main goal was to automate checks of introductory assignments from applicants to the School of Programmers. There were 5 people in the team and I, the manager :) We found our customers among the people who spent the most time on school. Work with the school begins long before its opening - these are lists of lecturers, site performance, marketing support and much more. But even more effort is required to check the profiles of applicants, give them test assignments and interview. We collected these activities, analyzed pains, prioritized, decomposed into separate stages and tasks, and started working. I tried to implement all the main practices from (review code, stand-ups, decomposition of the task and its assessment, personal responsibility for the release date, demo, retro). We got something like Scrum with 4-week iterations and a demo after them.

    After each demo, we did retro and improved processes. Retro is, in my opinion, one of the most difficult meetings in the entire development process. To carry it out qualitatively, you need complete trust within the team, you need to be on the same wavelength and be ready to change and progress something. Our first retro I was pleasantly surprised by the good working atmosphere, the number of honestly expressed problems and effective ways of solving 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 reached the end and we all work together at now!

    Our project will be the first project in 7 years of school that will go on sale, now the robot will check new applications with a piece of former students, so it's not very angry and harsh))

    I am still in our school. At first I was a student in it, helped interview the guys, became a lecturer, then a project manager, and now I am a curator. The school is a very multifaceted project, in which, if desired, you can get enormous knowledge and experience that helps to move forward in its development. I chose the path of team lead, others choose the path towards working with technology, and both paths can find the basis in the school of programmers.

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

    Also popular now: