Interface development school: analysis of tasks for Minsk and a new set in Moscow
Today, a new set has been opened for the Yandex Interface Development School in Moscow. From September 7 to October 25 will be the first stage of training. Students from other cities will be able to participate in it remotely or internally - the company will pay for the road and accommodation in the hostel. The second, he is the final stage will last until December 3, it can only go in person.
My name is Julia Seredich, we wrote this post together with Sergey Kazakov. We are both interface developers at the Minsk office of Yandex and SRI graduates of past years.
')
On the occasion of the opening of registration in Moscow, we publish an analysis of the introductory assignments to the previous School - here in Minsk.
If we trace the history of the SRI assignments, then year after year we tested three important skills for the programmer:
In the analysis of each task, we will tell not only about the correct course of action, but also about common mistakes.
Above the first task was the designer of Yandex.Collections Alexey Cherenkevich, who knows how to typeset, and his colleague in service, interface developer Sergey Samsonov.
The models proposed in the assignment were not just with screens for mobile devices, tablets and desktops, but also with this specification.
To bring as much objectivity as possible into the result of checking the first task, there were a lot of criteria for this checking.
Curb site . This seems obvious, but some guys missed some of the blocks entirely - whether they wanted to save time, or could not make them. The layout can be 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 made sections or simply with the help of a div, the main thing is that all four blocks were available.
Matching layout layout . The designer made a separate specification (including colors, typography, button states, etc.) to make candidates easier. Below was a tip on the indents and features of the first screen. Very pleased with the guys who took into account all the wishes of the designer: for example, the first screen should have turned out no less than the height of the viewport.
Adaptive layout is when the interface is not simply folded so that at three resolutions everything is pixel by pixel in the layout. In intermediate states, the layout also should not fall apart. Someone forgot to limit the maximum width of the container and pulled everything up to 1920 pixels, someone messed up with the backgrounds, but on the whole the candidates coped well with this task.
Semantic layout . “How many times have they told the world” that the link should be framed as <a>, the button should be like <button>. Fortunately, most candidates have fulfilled this requirement. Not everyone recognized the hidden list in the expectations of the SRI, making it with the help of div tags, but this is not so scary. There was a candidate who inserted all the semantic tags that he only knew - where necessary and where not. For example, instead of a list - <section> and <article>. Still, semantics - it’s about understanding the composition of your page and the purpose of each block (most of them coped here), as well as about the use of pre- and / or postprocessors (few people coped here, although it was also in paragraphs — less often and less connected) .
Working slider . In the task we wrote that JS can not be used. The ability to solve problems was tested here - the slider could be made using the <input> and <label for = ”# id”> bundles. All magic happens at the selector level # button-N: checked ~ .slider-inner .slider-slides. When we click on one of the checkboxes, it goes into the checked state. We can use this and assign the required translate to the container with slides: transform: translate (-33%). The implementation of the slider can be viewed here .
Drop-down lists . It all came down to <input name = "accordion" type = "radio"> and a similar selector: .accordion-item input: checked ~ .accordion-item__content. Implementation can be found here .
Presence of states: hover,: active and: focu * . Very important point. Comfort depended on it while interacting with the interface. The user should always receive feedback about their actions. This item was checked throughout the interaction with the questionnaire. If I pressed the “Call me” button and visually nothing happened (even though the request was sent), this is bad, because then I will press it again and again. In the end, send ten requests and call back ten times. Do not forget that there is no mouse on mobile devices - which means there should not be a hover. And one more thing that did not affect those who fulfilled the point about semantics. If your control is not an interactive element, then when you hover over it, the cursor will remain standard. It looks very untidy, even if you have prescribed a hover reaction. Don't underestimate cursor: pointer.
Animations . It is important that all reactions taking place with elements are smooth. There is nothing instantaneous in life, so the presence of transitions on hover and active was enough to make the interface more pleasant. Well, those who animated the slider and lists, generally well done.
Using the latest technology . Many used flex, while no one completed the task using the grid. Item counted if flex was used correctly. If somewhere, the lay-out because of these flex flexed - alas, you did not receive any additional points.
Validation of the form . All that was needed was to add the required attribute to each form input. We added a score to those who validated the email field as email.
Styling the file upload button . We expected to see a link like: <input type = ”file” id = ”file” name = ”file” class = ”inputfile” /> and <label for = ”file”> Select the file </ label>. Then it was required 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 <input type = ”file”>, and such a solution cannot be called fully cross-browser. Yes, and semantically correct to make a label.
Cross-browser compatibility . We checked that everything is fine, in the last two versions of modern browsers (without IE, participants were lucky), as well as in Safari on iPhones and in Chrome on androids.
We, on the contrary, shot points if someone used JS or Bootstrap: both of them deprived of the meaning of the whole task. Moreover, participants with Bootstrap not only received a minus, but also received less points for the semantics and the implemented elements.
Those who marked their site somewhere on the Internet did not receive a particular advantage - but the testers 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 in the first place for the student. Those whom we did not accept now have a summary of the summary - you can proudly attach it to all responses or put it on your gh-pages.
The author of the task is Denis Balyko, the head of the group of search interfaces.
Verification of the second task was the most automated and objective. Most of the guys guessed that it was necessary to implement the Dijkstra algorithm. Those who found its description and implemented the algorithm on JS are great. However, when checking the assignment, we met a lot of work with the same errors. We searched the Internet for code snippets and found an article from which participants wrote off 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 people to delve into what he writes.
Key points were awarded for tests. Sometimes it was obvious that the guys were managing the repository, renaming the folders, and the tests were falling simply because they could not find the files they needed. This year we tried to help such guys and put everything back for them. But next year we are planning to switch to the contest system, and this will not be forgiven anymore.
There were also “human”, manual criteria. For example - the presence of a single codestyle. Nobody reduced points for using tabs instead of spaces or vice versa. Another thing is if you alternate single quotes with double ones according to the rule you know, and put dots with commas separately.
Separately taken into account clarity and readability of the decision. At all conferences in the world, it is said that the work of a programmer consists of 80% of reading someone else's code. Even schoolchildren pass through coding books - from their curators and each other. So this criterion had considerable weight. There were works in which there were no variables longer than one character - please do not do so. Very pleased with the comments of the participants - 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 was a huge plus in karma.
Correct solution:
It was prepared by interface developers Sergey Kazakov and Alexander Podskrebkin.
The third task was the most interesting to check, because there were a lot of solutions, each with his own. We checked how the candidate handles unfamiliar technologies — whether he is able to research whether he is testing his decisions.
Rolled up calendar . Yes, it still needed to impose. There were those who understood the condition too literally and did not insert a single line of CSS code. It didn’t look very impersonal, but if everything worked, the scores did not decrease.
Get a list of events from the source . This task is not on the layout, so the list of events sewn into it was not counted. You can always cancel the conference, transfer it, add a new one. So it was necessary to receive data from the outside and render the layout already on the basis of the received JSON. It was important to get 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 considered a plus.
Registration service service without errors and work offline after the first download. Here is an example of a service worker with schedule caching on the first boot. Details about service workers, their capabilities and ways of working with them (strategies for working with the cache, working offline) can be found here .
The ability to set a reminder so that it really worked after 3, 7, 14 days. It was necessary to understand the Notifications API, the link to which was directly in the task. We did not wait for any concrete implementation of checking whether the time had come for pushing. Any working option was accepted: storage in localStorage, IndexDB or periodic polling by a service worker. You could even make a push server (here's an example ), but it would not work offline. It was equally important to get a push after the page was closed - and opened after some time. If the reminder "died" simultaneously with the closure of the page, the decision was not counted. Cool, when the guys thought about the inspectors and made it possible to get a push right now - not to wait for 3 days.
The ability to bring the icon to the desktop (PWA). We checked the presence of the file manifest.json with the correct icons. Some guys made this file (or left it generated in CreateReactApp) - but they didn’t add the right icons. Then, when trying to install, an error like “need another icon” occurred.
Code Style and Project Structure . As in the second task, we looked at a single code style (even if it did not coincide with ours). Some guys screwed up the linter is great.
Errors in the console . If there was an indicator right in the console that something was wrong and the participant did not pay attention to it, then we shot points.
Funny in the decisions of the participants:
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 have surprised their current professions: one of them is a medical examiner, and the other is a medical university student.
It turned out an interesting distribution of the success of assignments. With the first task, the participants coped on average by 60%, with the second - by 50%, and the third turned out to be the most difficult and it was completed on average by 40%.
At first glance, the tasks look complicated and time consuming. The reason is not that we want to weed out as many candidates as possible. While studying, students are faced with real challenges - to make a chat, Yandex.Music for children, or Yandex.Poloda for weather-dependent people. For this you need a starting base.
I remember when I saw my introductory task in SRI two years ago and thought that I would never solve it. The main thing at this moment is to sit down, carefully read the conditions and start doing it. 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 references to service workers and Notifications API on MDN. Students who studied the contents of the links coped without difficulty.
I really want this article to be read by candidates who plan to enter the SRI in the future, could not enroll in the Minsk School, or begin to do any other test task. As you can see, to do quite real. You just need to believe in yourself and listen to all the prompts of the authors.
My name is Julia Seredich, we wrote this post together with Sergey Kazakov. We are both interface developers at the Minsk office of Yandex and SRI graduates of past years.
')
On the occasion of the opening of registration in Moscow, we publish an analysis of the introductory assignments to the previous School - here in Minsk.
If we trace the history of the SRI assignments, then year after year we tested three important skills for the programmer:
- Layout. Every developer should be able to typeset. There is no such thing that you have Uncle Serozha, who imposes for the whole team, and you just write scripts. Therefore, each student must show how he can impose.
- Javascript If the case was limited to the layout, then we would have not the Interface Development School, but the Layout School. A beautiful web 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 probably the main skill of the developer. In creating interfaces, everything changes very quickly. It's like Lewis Carroll: "You have to run as fast as you need to just stay in the same place, and to get to another place, you have to run twice as fast." Every day we are faced with new technologies - it is necessary to reckon with them and be able to understand them. Therefore, in the third assignment, we proposed to understand the technologies with which the novice developer is usually not familiar.
In the analysis of each task, we will tell not only about the correct course of action, but also about common mistakes.
Task 1: Portfolio
Above the first task was the designer of Yandex.Collections Alexey Cherenkevich, who knows how to typeset, and his colleague in service, interface developer Sergey Samsonov.
Condition
Create a portfolio site: tell about yourself, your work and expectations from the School. The site should correspond as much as possible to the proposed layout (links to layouts: 1000px , 600px , 320px , specification ). We are only interested in the layout, so please do not use JavaScript.
When checking, we will consider:
- indentation sizes, correct color, font style, size;
- semantic layout;
- the presence of various states of elements: the display of buttons and links when you hover the cursor, the selection of active input fields, etc .;
- Cross-browser compatibility (checked in the latest versions of popular browsers).
Plus will be:
- use of modern CSS solutions: flexbox, grid, etc .;
- Adaptive layout;
- use of pre- and (or) postprocessors, assembly, minification, optimization of the output code;
- HTML form validation, stylized file upload button.
The task is quite voluminous, so you can skip something that will not work. This will lower the score a little, but you can still demonstrate your knowledge. Upon completion, send us two links - a portfolio and source code on GitHub.
The models proposed in the assignment were not just with screens for mobile devices, tablets and desktops, but also with this specification.
To bring as much objectivity as possible into the result of checking the first task, there were a lot of criteria for this checking.
Criteria
Curb site . This seems obvious, but some guys missed some of the blocks entirely - whether they wanted to save time, or could not make them. The layout can be 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 made sections or simply with the help of a div, the main thing is that all four blocks were available.
Matching layout layout . The designer made a separate specification (including colors, typography, button states, etc.) to make candidates easier. Below was a tip on the indents and features of the first screen. Very pleased with the guys who took into account all the wishes of the designer: for example, the first screen should have turned out no less than the height of the viewport.
Adaptive layout is when the interface is not simply folded so that at three resolutions everything is pixel by pixel in the layout. In intermediate states, the layout also should not fall apart. Someone forgot to limit the maximum width of the container and pulled everything up to 1920 pixels, someone messed up with the backgrounds, but on the whole the candidates coped well with this task.
Semantic layout . “How many times have they told the world” that the link should be framed as <a>, the button should be like <button>. Fortunately, most candidates have fulfilled this requirement. Not everyone recognized the hidden list in the expectations of the SRI, making it with the help of div tags, but this is not so scary. There was a candidate who inserted all the semantic tags that he only knew - where necessary and where not. For example, instead of a list - <section> and <article>. Still, semantics - it’s about understanding the composition of your page and the purpose of each block (most of them coped here), as well as about the use of pre- and / or postprocessors (few people coped here, although it was also in paragraphs — less often and less connected) .
Working slider . In the task we wrote that JS can not be used. The ability to solve problems was tested here - the slider could be made using the <input> and <label for = ”# id”> bundles. All magic happens at the selector level # button-N: checked ~ .slider-inner .slider-slides. When we click on one of the checkboxes, it goes into the checked state. We can use this and assign the required translate to the container with slides: transform: translate (-33%). The implementation of the slider can be viewed here .
Drop-down lists . It all came down to <input name = "accordion" type = "radio"> and a similar selector: .accordion-item input: checked ~ .accordion-item__content. Implementation can be found here .
Presence of states: hover,: active and: focu * . Very important point. Comfort depended on it while interacting with the interface. The user should always receive feedback about their actions. This item was checked throughout the interaction with the questionnaire. If I pressed the “Call me” button and visually nothing happened (even though the request was sent), this is bad, because then I will press it again and again. In the end, send ten requests and call back ten times. Do not forget that there is no mouse on mobile devices - which means there should not be a hover. And one more thing that did not affect those who fulfilled the point about semantics. If your control is not an interactive element, then when you hover over it, the cursor will remain standard. It looks very untidy, even if you have prescribed a hover reaction. Don't underestimate cursor: pointer.
Animations . It is important that all reactions taking place with elements are smooth. There is nothing instantaneous in life, so the presence of transitions on hover and active was enough to make the interface more pleasant. Well, those who animated the slider and lists, generally well done.
Using the latest technology . Many used flex, while no one completed the task using the grid. Item counted if flex was used correctly. If somewhere, the lay-out because of these flex flexed - alas, you did not receive any additional points.
Validation of the form . All that was needed was to add the required attribute to each form input. We added a score to those who validated the email field as email.
Styling the file upload button . We expected to see a link like: <input type = ”file” id = ”file” name = ”file” class = ”inputfile” /> and <label for = ”file”> Select the file </ label>. Then it was required 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 <input type = ”file”>, and such a solution cannot be called fully cross-browser. Yes, and semantically correct to make a label.
Cross-browser compatibility . We checked that everything is fine, in the last two versions of modern browsers (without IE, participants were lucky), as well as in Safari on iPhones and in Chrome on androids.
We, on the contrary, shot points if someone used JS or Bootstrap: both of them deprived of the meaning of the whole task. Moreover, participants with Bootstrap not only received a minus, but also received less points for the semantics and the implemented elements.
Those who marked their site somewhere on the Internet did not receive a particular advantage - but the testers 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 in the first place for the student. Those whom we did not accept now have a summary of the summary - you can proudly attach it to all responses or put it on your gh-pages.
Task 2: Transport Path
The author of the task is Denis Balyko, the head of the group of search interfaces.
Condition
You have a starry sky map. It shows the name of each star, as well as the distance from it to other stars in light seconds. Implement the function solution, which should take three arguments: the 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), and the names of the starting and ending 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 be taken.
Signature function:const solution = function(graph, start, finish) { // }
Sample input: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: the solution framework is in the src / folder, put your solution in solution.js.
Verification of the second task was the most automated and objective. Most of the guys guessed that it was necessary to implement the Dijkstra algorithm. Those who found its description and implemented the algorithm on JS are great. However, when checking the assignment, we met a lot of work with the same errors. We searched the Internet for code snippets and found an article from which participants wrote off 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 people to delve into what he writes.
Criteria
Key points were awarded for tests. Sometimes it was obvious that the guys were managing the repository, renaming the folders, and the tests were falling simply because they could not find the files they needed. This year we tried to help such guys and put everything back for them. But next year we are planning to switch to the contest system, and this will not be forgiven anymore.
There were also “human”, manual criteria. For example - the presence of a single codestyle. Nobody reduced points for using tabs instead of spaces or vice versa. Another thing is if you alternate single quotes with double ones according to the rule you know, and put dots with commas separately.
Separately taken into account clarity and readability of the decision. At all conferences in the world, it is said that the work of a programmer consists of 80% of reading someone else's code. Even schoolchildren pass through coding books - from their curators and each other. So this criterion had considerable weight. There were works in which there were no variables longer than one character - please do not do so. Very pleased with the comments of the participants - 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 was a huge plus in karma.
Correct solution:
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: Event Calendar
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 that you like. For example, the front-end conference schedule in 2019.
The calendar should look like a list. There are no other design requirements. Make it possible to set event reminders for 3, 7 and 14 days. After the first download with the Internet, the calendar should open and function offline.Useful resources
Front End Conferencing Schedule:
confs.tech/javascript?topics=javascript%2Bcss%2Bux
Service workers:
developer.mozilla.org/en/docs/Web/API/Service_Worker_API/Using_Service_Workers
developers.google.com/web/fundamentals/primers/service-workers
Notifications API:
developer.mozilla.org/en/docs/Web/API/Notifications_API
The third task was the most interesting to check, because there were a lot of solutions, each with his own. We checked how the candidate handles unfamiliar technologies — whether he is able to research whether he is testing his decisions.
Criteria
Rolled up calendar . Yes, it still needed to impose. There were those who understood the condition too literally and did not insert a single line of CSS code. It didn’t look very impersonal, but if everything worked, the scores did not decrease.
Get a list of events from the source . This task is not on the layout, so the list of events sewn into it was not counted. You can always cancel the conference, transfer it, add a new one. So it was necessary to receive data from the outside and render the layout already on the basis of the received JSON. It was important to get 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 considered a plus.
Registration service service without errors and work offline after the first download. Here is an example of a service worker with schedule caching on the first boot. Details about service workers, their capabilities and ways of working with them (strategies for working with the cache, working offline) can be found here .
The ability to set a reminder so that it really worked after 3, 7, 14 days. It was necessary to understand the Notifications API, the link to which was directly in the task. We did not wait for any concrete implementation of checking whether the time had come for pushing. Any working option was accepted: storage in localStorage, IndexDB or periodic polling by a service worker. You could even make a push server (here's an example ), but it would not work offline. It was equally important to get a push after the page was closed - and opened after some time. If the reminder "died" simultaneously with the closure of the page, the decision was not counted. Cool, when the guys thought about the inspectors and made it possible to get a push right now - not to wait for 3 days.
The ability to bring the icon to the desktop (PWA). We checked the presence of the file manifest.json with the correct icons. Some guys made this file (or left it generated in CreateReactApp) - but they didn’t add the right icons. Then, when trying to install, an error like “need another icon” occurred.
Code Style and Project Structure . As in the second task, we looked at a single code style (even if it did not coincide with ours). Some guys screwed up the linter is great.
Errors in the console . If there was an indicator right in the console that something was wrong and the participant did not pay attention to it, then we shot points.
Results
Funny in the decisions of the participants:
- One questionnaire contained the following text: “A programmer friend helped to assemble the react-application. I threw him with questions like what and why, he told. I liked it very much, I want to know more about it. ” We were wholeheartedly supporting this profile, but unfortunately, the candidate’s friend didn’t really help him 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. :)
- Another candidate in the comments of the first line of the file solution.js 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 have surprised their current professions: one of them is a medical examiner, and the other is a medical university student.
It turned out an interesting distribution of the success of assignments. With the first task, the participants coped on average by 60%, with the second - by 50%, and the third turned out to be the most difficult and it was completed on average by 40%.
At first glance, the tasks look complicated and time consuming. The reason is not that we want to weed out as many candidates as possible. While studying, students are faced with real challenges - to make a chat, Yandex.Music for children, or Yandex.Poloda for weather-dependent people. For this you need a starting base.
I remember when I saw my introductory task in SRI two years ago and thought that I would never solve it. The main thing at this moment is to sit down, carefully read the conditions and start doing it. 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 references to service workers and Notifications API on MDN. Students who studied the contents of the links coped without difficulty.
I really want this article to be read by candidates who plan to enter the SRI in the future, could not enroll in the Minsk School, or begin to do any other test task. As you can see, to do quite real. You just need to believe in yourself and listen to all the prompts of the authors.
Source: https://habr.com/ru/post/454584/
All Articles