Today opened a new set of in Moscow. From September 7 to October 25, the first stage of training will take place. Students from other cities will be able to participate in it remotely or in person - the company will pay for travel and accommodation in a hostel. The second, which is also the final stage, will last until December 3, it can only be completed in person.
My name is Julia Seredich, we wrote this post together with Sergey Kazakov. We are both interface developers in the Minsk office of Yandex and graduates of SRI from previous years.
On the occasion of the opening of registration in Moscow, we publish an analysis of the introductory tasks for the previous School - here in Minsk.
If we trace the history of ShRI assignments, then from year to year we tested three skills that are important for a programmer:
- Layout. Every developer should be able to typeset. It doesn't happen that you have an uncle Seryozha who typesets for the whole team, and you only write scripts. Therefore, each student must show how he can typeset.
- JavaScript. If the business was limited to layout, then we would have not the School of Interface Development, but the School of Layout Makers. A beautifully designed interface needs to be revived. Therefore, there is always a task for JS, but sometimes it is also a task for algorithms - we love them so much.
- Problem solving is perhaps the most important skill of a developer. In the creation of interfaces, everything changes very quickly. It's like Lewis Carroll: "You have to run as fast just to stay in the same place, and to get to another place you need to run twice as fast." Every day we are faced with new technologies - you need to reckon with them and be able to understand them. Therefore, in the third task, we proposed to understand technologies that a novice developer is usually not familiar with.
In the analysis of each task, we will tell you not only about the correct procedure, but also about common mistakes.
Task 1: Portfolio
Alexey Cherenkevich, designer of Yandex.Collections, who knows how to typeset, and his colleague in the service, interface developer Sergey Samsonov, worked on the first task.
Condition
Create a portfolio site: tell us about yourself, your work and expectations from the School. The site should correspond to the proposed layout as much as possible (links to layouts: , , , ). We are only interested in layout, so please do not use JavaScript.
When checking, we will consider:
- indent sizes, color correctness, font style, point size;
- semantic layout;
- the presence of various states of elements: displaying buttons and links when hovering over the cursor, highlighting active input fields, etc.;
- cross-browser compatibility (tested in the latest versions of popular browsers).
The advantage will be:
- use of modern CSS solutions: flexbox, grid, etc.;
- Adaptive layout;
- use of pre- and (or) post-processors, assembly, minification, optimization of the output code;
- HTML form validation, stylized file upload button.
The task is quite voluminous, so you can skip what will not work. This will slightly reduce the score, but you will still be able to demonstrate your knowledge. Upon completion of the work, send us two links - to the portfolio and the source code on GitHub.
The layouts proposed in the assignment were not just with screens for mobile devices, tablets and desktops, but also with a real specification.
In order to bring as much objectivity as possible into the result of the test of the first task, there were a lot of criteria for this test.
Criteria
Designed site. It seems obvious, but some guys skipped some blocks entirely - either they wanted to save time, or they couldn't do them. The layout can be conditionally divided into four main screens: the main screen with an avatar, a block with a list of expectations from SRI, a block with a portfolio and a block with contact information. They could be done in sections or simply with the help of div, the main thing is that all four blocks were available.
Compliance layout layout. The designer made a separate specification (including colors, typography, button states, etc.) to make it easier for candidates. At the bottom was a hint on the indents and features of the first screen. The guys who took into account all the wishes of the designer were very pleased: for example, the first screen had to turn out to be no less than the height of the viewport.
Adaptive layout - this is when the interface is not just laid out so that at three resolutions everything is pixel by pixel according to the layout. In intermediate states, the layout should also not fall apart. Someone forgot to limit the maximum width of the container and pulled everything to 1920 pixels, someone messed up with the backgrounds, but in general, the candidates coped with this task well.
Semantic layout. “How many times have they told the world” that the link should be formatted as , the button as . Fortunately, most of the candidates fulfilled this requirement as well. Not everyone recognized the lurking list in expectations from SRI by making it with div tags, but it's not that bad. There was a candidate who inserted all the semantic tags that he only knew - where it was necessary and where it was not necessary. For example, instead of a list - and . Still, semantics is about understanding the composition of your page and the purpose of each block (here the majority did it), as well as about the use of pre- and / or post-processors (few did it here, although it was also in points - most often they connected less and scss) .
Working slider. In the assignment, we wrote that JS cannot be used. Here the ability to solve problems was tested - the slider could be made using a bundle and . All the magic happens at the level of the #button-N:checked ~ .slider-inner .slider-slides selector. When we click on one of the checkbox inputs, it goes into the checked state. We can take advantage of this and assign the translate we need to the slide container: transform: translate(-33%). You can see the implementation of the slider .
Drop-down lists. Here it all boils down to and a similar selector: .accordion-item input:checked ~ .accordion-item__content. You can see the implementation .
Having :hover, :active and :focu* states. A very important point. Comfort depended on it during interaction with the interface. The user should always receive feedback on their actions. This item was checked throughout the entire interaction with the questionnaire. If I clicked the “Call me” button and visually nothing happened (even though the request was sent) - this is bad, because then I will click it again and again. As a result, ten requests will be sent and I will be called back ten times. We should not forget that mobile devices do not have a mouse, which means that there should not be hover. And one more thing that did not affect those who completed the item about semantics. If your control is not an interactive element, then when hovering over it, the cursor will remain standard. It looks very untidy, even if you have written a reaction to hover. Don't underestimate cursor: pointer.
Animations. It is important that everything that happens with the elements of the reaction is smooth. Nothing in life is instant, so having transitions on hover and active was enough to make the interface nicer. Well, those who animated the slider and lists are generally great.
Using the latest technology. Many have used flex, yet no one has done the job with grid. The point was counted if flex was used correctly. If somewhere the layout was dispersed because of these very flex - alas, you did not receive additional points.
Form validation. It was only required to add the required attribute to each input of the form. We added points to those who validated the email field as email.
File upload button styling. We expected to see a bunch of the form: and Select file . The next step was to hide the input and style the label. There is another common way - to make a transparent input and put it on top of the button. But not all browsers allow styling , and such a solution cannot be called fully cross-browser. And it's semantically more correct to make a label.
Crossbrowser compatibility. We checked that everything is fine in the last two versions of modern browsers (without IE - the participants were lucky), as well as in Safari on iPhones and Chrome on Androids.
We, on the contrary, deducted points if someone used JS or Bootstrap: both made the whole task meaningless. Moreover, participants with Bootstrap not only received a minus, but also lost a lot of points for semantics and implemented elements.
Those who tagged their site somewhere on the Internet did not get much advantage - but the reviewers were very happy when they did not have to download the repositories and run them locally on their computer. So it served as a plus in karma.
The first task was very useful primarily for the student. Those who we did not accept now have a typed-up resume - you can proudly attach it to all the responses or put it on your gh-pages.
Task 2: Transport route
The author of the task is the head of the search interfaces group Denis Balyko.
Condition
You have a map of the starry sky. It shows the name of each star, as well as the distance from it to other stars in light seconds. Implement the solution function, which should take three arguments: an object in which the keys are the names of the stars, and the values are the distances to the stars (one-way traffic in space), as well as the names of the start and end points of the path - start and finish, respectively. The function should return the shortest distance from the start star to the finish star and the path to follow.
Function signature:
const solution = function(graph, start, finish) { // Ваше решение }Input example:
const graph = { start: { A: 50, B: 20 }, A: { C: 40, D: 20 }, B: { A: 90, D: 90 }, C: { D: 160, finish: 50 }, D: { finish: 20 }, finish: {} }; const start = 'start'; const finish = 'finish';Sample output:
{ distance: 90, path: ['start', 'A', 'D', 'finish'] }Note: solution framework is in src/ folder, place your solution in solution.js.
Checking the second task was the most automated and objective. Most of the guys guessed that it was necessary to implement Dijkstra's algorithm. Those who found its description and implemented the algorithm in JS are great. However, when checking the assignment, we came across many papers with the same errors. We searched the Internet for code snippets and found an article from where the participants copied the algorithm. It's funny that many copied the code from the article along with the author's comments. Such works received a low score. We do not prohibit the use of any sources, but we want a person to delve into what he writes.
Criteria
The main points were awarded for tests. Sometimes it was seen that the guys took over the repository by renaming the folders, and the tests fell simply because they could not find the necessary files. This year we tried to help these guys and put everything back in place for them. But next year we plan to switch to the contest system, and this will not be said goodbye.
There were also "human", manual criteria. For example, the presence of a single codestyle. Nobody deducted points for using tabs instead of spaces or vice versa. Another thing is if you alternate single quotes with double ones according to one rule you know, and put semicolons at random.
Separately, the clarity and readability of the solution were taken into account. At all conferences in the world they say that 80% of a programmer's job consists of reading someone else's code. Even schoolchildren are code-reviewed by their curators and each other. So this criterion had significant weight. There were works in which there were no variables longer than one character - please do not do this. The comments of the participants were very pleasing - with the exception of those that were identical to the comments of Stella Chang.
The last criterion is the availability of autotests. Only a few people added them, but for everyone it became a huge plus in karma.
The right decision:
const solution = function(graph, START, FINISH) {
// Всё не бесплатно в этом мире
const costs = Object.assign({[FINISH]: Infinity}, graph[START]);
// Первая волна родительских нод
const parents = { [FINISH]: null };
Object.keys(graph[START]).reduce((acc, child) => (acc[child] = START) && acc, parents)
const visited = [];
let node;
// Ищем «дешёвого» родителя, отмечаем пройденные
do {
node = lowestCostNode(costs, visited);
let children = graph[node];
for (let n in children) {
let newCost = costs[node] + children[n];
// Ещё не оценена или нашёлся более дешёвый переход
if (!costs[n] || costs[n] > newCost) {
costs[n] = newCost;
parents[n] = node;
}
}
visited.push(node);
} while (node)
return {
distance: costs[FINISH],
path: optimalPath(parents)
};
// Возврат назад по самым «дешёвым» родителям
function optimalPath(parents) {
let optimalPath = [FINISH];
let parent = parents[FINISH];
while (parent && parent !== START) {
optimalPath.push(parent);
parent = parents[parent];
}
optimalPath.push(START);
return optimalPath.reverse();
}
// Минимальная стоимость из текущей ноды среди непросмотренных
function lowestCostNode(costs, visited) {
return Object.keys(costs).reduce((lowest, node) => {
if (lowest === null || costs[node] < costs[lowest]) {
if (!visited.includes(node)) {
lowest = node;
}
}
return lowest;
}, null);
};
};Task 3: Calendar of events
It was prepared by interface developers Sergey Kazakov and Alexander Podskrebkin.
Condition
Write a mini-calendar to display the schedule. You can take any schedule you like. For example, the schedule of front-end conferences in 2019.
The calendar should look like a list. There are no other design requirements. Make it possible to set event reminders 3, 7 and 14 days in advance. After the first download from the Internet, the calendar should open and function offline.
Useful resources
Schedule of front-end conferences:
service workers:
Notifications API:
The third task was the most interesting to check, because there were a lot of solutions, everyone has their own. We checked how the candidate handles unfamiliar technologies - whether he knows how to research, whether he tests his solutions.
Criteria
Compiled calendar. Yes, it still needed to be laid out. There were those who took the condition too literally and did not insert a single line of CSS code. It did not look very personal, but if everything worked, the points did not decrease.
Getting a list of events from a source. This is no longer a layout task, so the list of events sewn into it was not counted. You can always cancel the conference, reschedule it, add a new one. So it was necessary to receive data from the outside and render the layout based on the received JSON. It was important to get the data in any way (using the fetch method or using XMLHttpRequest). If a person added a polyfill for fetch and marked his choice in the readme, this was counted as a plus.
Service worker registration without errors and work offline after the first download. service worker with schedule caching on first boot. Details about service workers, their capabilities and how to work with them (cache strategies, offline work) can be found here.
Ability to set a reminderso that it really works in 3, 7, 14 days. It was necessary to understand the Notifications API, was right on task. We didn't expect any particular implementation of checking if it's time to push. Any working option was accepted: storage in localStorage, IndexDB, or periodic polling by a service worker. It was even possible to make a push server (here ), but offline it would not work. It was equally important to get a push after the page was closed - and opened after some time. If the reminder "died" at the same time as the page was closed, the decision was not counted. It's cool when the guys thought about verifiers and made it possible to get a push right now - so as not to wait 3 days.
Ability to move the icon to the desktop (P.W.A.). We checked for the existence of the file with the correct icons. Some guys made this file (or left it generated in CreateReactApp) - but didn't add the right icons. Then, when trying to install, an error like "need another icon" occurred.
Codestyle and project structure. As in the second task, we looked at a single code style (even if it did not match ours). Some guys screwed linters - it's great.
Errors in the console. If there was an indicator directly in the console that something was wrong, and the participant did not pay attention to it, then we took points.
Results
Funny in the decisions of the participants:
- One questionnaire contained the following text: “A programmer friend helped me build a react application. I bombarded him with questions of what, how and why, he told. I liked it very much, I want to know more about it. We were rooting for this survey with all our hearts, but unfortunately, the candidate's friend did not help him much to make a working application.
- One candidate sent a link to GitHub, where the RAR archive was located - it's hard to comment on this somehow. 🙂
- Another candidate, in the comment on the first line of the solution.js file, honestly admitted that he copied the algorithm.
We received questionnaires from 76 candidates and selected 23 of them. We were sent questionnaires not only from Minsk, but also from Moscow, St. Petersburg and even Tatarstan. Some guys surprised me with their current professions: one of them is a medical examiner, and the other is a medical student.
It turned out an interesting distribution of the success of the tasks. The participants coped with the first task by an average of 60%, with the second - by 50%, and the third turned out to be the most difficult and completed it by an average of 40%.
At first glance, the tasks look complex and time-consuming. The reason is not that we want to weed out as many candidates as possible. During the training, students are faced with real tasks - to make a chat, Yandex.Music for children or Yandex.Weather for weather-dependent people. This requires a starting base.
I remember seeing my SRI introductory assignment two years ago and thinking that I would never solve it. The main thing at this moment is to sit down, read the conditions carefully and start doing. It turns out that the conditions contain almost 80% of the solution. For example, in the condition of the third task (the most difficult one), we added links to service workers and Notifications API on MDN. The students who studied the contents of the links did well.
I really want this article to be read by candidates who plan to enter SRI in the future, who could not enter the Minsk School, or who are starting to take any other test task. As you can see, it's quite realistic to do so. You just need to believe in yourself and listen to all the prompts of the authors.
Source: habr.com