TypeScript and short sprints. How we made the front end interview variation tool

November 17, 2018 . We are a party of four. Everyone is elated - they passed the first stage of the ShRI , the School of Interface Design. It consisted of lectures and homework: mastered various front-end and near-tender technologies, tools, Scrum. They knew that all this would have to be used in a combat project in the second stage. But it is one thing to know, and another to really implement this project in the next 5 weeks.

We live, by the way, all four of us in one room in the Netizen hostel. Yandex settled us here before the first stage. Nice hostel, trendy.

Today's project presentations. We are not presenting, but to us. Yandex units bring production tasks for external and internal services, each just for 5 weeks, if you make a small group of people. The tasks are mostly front-end (we are in ShRI), but there are some nuances: you will need to file a small backend and design. Old-timers say it was different in the early years of ShRI. They did abstract tasks that were not related to production.

We are going to the whole stream of SRI 2018 in the hall, here everyone who is admitted to the second stage. For the first time we are asked to break into teams: before everyone was for himself. The four of us quickly consult together and decide - since we live together, we will do the project together. The team was named Bundle. Then we are told about affordable projects, there are more of them than the formed teams. This means that the departments where the projects came from have an incentive to make them more interesting for students, otherwise you can be left without performers.

They explain to us that each team will do one project, but first we need to choose several. Further, the system is as follows: if one project selected several teams, then the executing team is randomly determined among them, and so on until all students receive the tasks for the second stage. We are leaving with our curators in a meeting room, we are conferring, each team, regardless of the rest, votes for the projects they like. By the sum of the votes, we calculate those of them that are interesting to us as a team.

November 21, Wednesday . The two projects that seemed most interesting to us are taken by other teams according to the random system. We get the third - a tool for the variability of front-end interviews.

Interface developers at interviews at Yandex are often given the task of finding bugs in the search results layout. The candidate should open the proposed link, there he will see the results, which are compiled with errors. It is necessary to visually and using the JavaScript console in the browser to find errors and propose corrections.

The difficulty is that you want to give different candidates different sets of bugs, vary them depending on the expectations of the interviewee. But then before each interview you need to sit down and manually collect the results. It is better to have a tool at hand that would collect it yourself, place bugs on it and form a link to it. At the same time, the type of link itself should not hint to the candidate what bugs he needs to find. This is a small but additional complexity, because the easiest way to automatically insert errors is to pass them through query parameters in the link text. By convention, the address yandex.ru/search/?text=cats&bug=object could lead to an issue where the object response block is incorrectly compiled. I did not want to give such hints. It was necessary to "proxy" the page, showing it at an address that cannot be interpreted.

This project was on the list of our team because it is versatile. We understood that writing a job admin admin would require a backend and some design skills.

Thursday, November 22nd . In fact, on weekdays, lectures only continue (already without homework, for general development), and Saturday is provided for work on the project. On Saturday in the morning, the whole stream gathers together again, having all day to plan and code together with the manager (Yandex employee), and so on every Saturday until the end of the SRI. This is called shrikaton, it takes place in the office.

But our team lives together, so we start early. :) This is not a very big cheat - the four of us have a different regime of the day, work in addition to SRI. And yet we have the opportunity to advance on the project in the week too.

Select the database for the backend. One of us, Vani, had experience with MongoDB, this is a simple base from the point of view of integration, so we dwell on it. Yandex. Cloud will provide us with a Managed MongoDB cluster so that we don’t have to think about servicing the database. For the convenience of working with the database, we will use the Mongoose library - we will describe the main entities as Mongoose schemes and models (with typification, relationships, validation). So that the base can be raised locally, we add docker-compose.

November 24th. The first shrikaton. Each team sits at its own large table, each has a board - you can stick stickers, watch task statuses, and conduct regular stand-ups. You are distracted only for lunch. The curators help us: advise on the technical component, tell how to organize communication, how of us, four different people, create a team, work on Scrum, draw a kanban board, set goals, in general - start turning an idea into a product.

We distribute the roles: the two of us will be in the frontend of the admin panel, and the other two will be in the backend. Yandex calls this backend for frontend - we use a layer from the server on Node.js. We decide to write the server in TypeScript - we select it to comply with strict typing and fully implement the concept of OOP. For routing on the server, we take the minimal, flexible and functional Express web framework. We understand that the back and front should be developed independently, therefore, we introduce temporary “stubs” - manually prepared data for the front, as if they were formed and transmitted by the already working back. We write documentation for each HTTP handle in the Swagger service in order to correctly interpret the stubs and then it would be enough to remove them all and collapse the front and back. To do this, we are preparing to write a REST API.

We define the main goal - to implement four entities:

• admin server
• client part for admin panel,
• infrastructure
• pages with bugs.

At the end of each shrikaton (there are four of them), one of the team should speak and show a demo with intermediate results for the project. We agree that each of us will hold one demo as a whole. On the first demo, we mainly show layout with bugs - in the form in which candidates will study it at interviews. We also show the base admin panel - those parts that we managed to do in the first day.

Week from November 26 to December 2 . Winter and our project are gaining momentum. Discussed and documented APIs and contracts for the exchange of information between the client and server.

We agree to make more functionality in the admin panel than is stated in the ToR. The fact is that the candidate to whom we show the layout with bugs can then share a link to this page with a friend or in the front-end community in order to simplify the life of other candidates. This means that the link should “burn out” after some time, become inoperative. This was known immediately, when we were given the project, but for now, for the convenience of the interviewee, we want to display in the admin panel an editable field with the exact time of the "life" of the link.

In addition, we add the story. The admin in its original form was only a tool for generating links. History, we thought, will allow us to see which links have already been generated and for how long they have been active. We also added the ability for interviewees to attach text comments (in free form) to entries in history.

The demo on the second shrikaton is still showing with plugs - the backend is still being sawn. In the process of testing the demo, we find a number of problems with architecture, we add them to the backlog with high priority.

Week from December 3 to 9 . Another sprint. We determined that the optimal sprint length for us is 6 days, starting from Monday and ending with the shrikaton on Saturday. After the shrikatons, on Sundays, we arrange a retro and make a backlog for the next sprint.

We practice code reviews. Each pool request is reviewed by at least two team members (with rare exceptions in the form of pool requests containing minor corrections). We try to use the following practices:

• do not delay the pool request verification,
• write reviews in the form of discussion requests, not teams,
• explain in comments not only the proposed change, but also the reason
• generously use code examples and links to useful resources.

There was a question about redesign. We implemented the design that Yandex provided to us in the form of layouts initially, but the number of features increased, the admin panel needs changes, including visual ones. We communicate with customers, agree on a partial redesign, and begin to do it.

We fix problems in the architecture, get rid of stubs between the frontend and backend, connect the database. The documentation we compiled helped: when we turned off the stubs and made very small adjustments, the data began to correctly come from the back to the front. First show demo in battle mode.

Last two weeks. We swap places: the two of us who were responsible for the front are now responsible for the back - and vice versa. We came up with such a scheme so that each of us knows the whole project. Along the way, we are discussing with the manager and customers the details of the process of introducing the admin panel into production. The head of the search interface testing group Olya Molchanova helped us a lot, we agreed on specific implementation steps.

To draw up a technical report on the project (this is required from all teams), we write why we chose this or that approach or tool:

Implemented the UI as a Single Page Application due to the large number of advantages over the "classic" multi-page sites. Firstly, SPA resembles simple native applications, the only difference is that they are executed in the browser, and not in the operating system’s own process. Secondly, such applications always have rich UX. Due to the fact that we have only one web page, building a rich and functional user interface is much easier. At the same time, it is convenient to store and update the state of representations, as well as manage it. Thirdly, SPA excludes constant requests to the same content when moving around the site.

SPA also has disadvantages. When the interviewer first opens the admin panel, he will need to download a little more data. However, in our project, the assembled bundle in compressed form (gzip) weighs a little over 100 KB and is divided into fragments (chunks). As a result, the site is drawn equally quickly. The minuses of SPA traditionally include the fact that almost all search robots and social networks do not see the content of such sites. Our application was developed for internal use, so we do not need to use server-side rendering or generally care about SEO.

React was chosen as a library for developing SPA-applications, as:

• many new projects in Yandex are written in React, and old ones are written,
• You can use the Lego component library,
• all team members were familiar with React,
• React has 117 697 stars on GitHub, a community of millions of developers.

For convenient work with dates (in particular, to display the remaining time period for the link), the Moment.js library is used.

In the technical report, it is necessary to list that each of us has learned new things. A total of four lists:

1. Appreciated the full power of TypeScript. The language allows you to catch errors when writing code, makes refactoring and adding features more pleasant. We got acquainted with the organization of the project based on several config files.

2. Worked in the paradigm of microservice architecture and mono-repository.

3. Learned a lot about React (including from each other). Understood how to organize components so that they are easier to maintain and reuse.

4. Some of us have discovered for ourselves, while others have mastered various tools:

- Docker and Docker Compose. We learned how to install, configure, and run containers in a basic way.
- Git. The practice of parsing, creating, and injecting pool requests was consolidated. Recognized the importance of this process.
- Moongose ​​library, mongo-express admin panel.
- Yandex.Cloud.
- Swagger.
- BitBucket.

5. Got a huge leap in development thanks to team development.

- Learned to work in a scrum team.
- We worked in the task tracker, got acquainted with the kanban board, sprints. In real conditions, they realized how much more productive it is to conduct development in short cycles with a constant feedback.
- Set up CI through TeamCity.
- They saw that the code review is useful for all participants. Sometimes reading someone else's code is more useful than writing.
- We worked with the project manager, this brought the development closer to the "field" conditions.
- Due to regular demos, we got the skills of public speaking.

We complete the service, perform comprehensive testing, and draw up documentation. In parallel, you need to prepare for our own interviews on Yandex - some of them will be held the very next day after the completion of the project! This is bad news (because preparation is a little distracting from the project) and good (because further steps are not put off the shelf).

December 23. The final day of SRI, we come up with a finished project. Vanya says, the other three join in to answer questions. Summary - we made an admin panel that allows an employee to create search results URLs that are matched with errors before the front-end interview. These errors are arranged automatically in a few seconds - just tick them. In addition, the interviewee can look at the history of links and set the lifetime for your URL. And in the interview itself, as already mentioned, the candidate receives a link and must find and correct all errors. We added to the admin panel the ability to prepare a page with bugs not only based on the search interface, but also any other service, if necessary for an interview.

On the server side, NodeJS and the Express framework are used to host the interface and process REST API requests. The client side is React. The full technical report on the project was posted on the Disk .

^{_{The authors of this post :)}}

December 24th . We do not disagree right away - we live in a hostel for about a week and go through interviews. We write out only closer to the New Year.

May 21, 2019 . Now each of the four of us works at Yandex, no longer on an internship, but on a perpetual contract. We are interface developers Evgeny Goncharenko, Ivan Kolobaev, Sergey Makhlonov and Evgeny Starostin. The system that we made as a graduation project in ShRI is constantly used in interviews.

July 9th . Publish this post.