Hoje, um novo conjunto foi aberto na
Escola Yandex de Desenvolvimento de Interface, em Moscou. De 7 de setembro a 25 de outubro, ocorrerá a primeira etapa do treinamento. Estudantes de outras cidades poderão participar remotamente ou pessoalmente - a empresa pagará pela estrada e acomodação no albergue. Segundo, é a etapa final que dura até 3 de dezembro, e só pode ser concluída pessoalmente.
Meu nome é Julia Seredich, escrevemos este post junto com Sergey Kazakov. Nós dois somos desenvolvedores de interface no escritório de Yandex em Minsk e formamos o SRI dos últimos anos.
Na ocasião da abertura do registro em Moscou, publicamos uma análise das tarefas de ingresso na Escola anterior - aqui em Minsk.
Se rastrearmos o histórico das tarefas de SRI, testamos, ano após ano, três habilidades importantes para um programador:
- Layout. Todo desenvolvedor deve ser capaz de escrever. Não acontece que você tenha o tio Seryozha que digitou para toda a equipe e só escreva scripts. Portanto, cada aluno deve mostrar como ele sabe escrever.
- Javascript Se o assunto fosse limitado à tipografia, não teríamos uma escola de desenvolvimento de interface, mas uma escola de layout. A bela interface dobrada precisa ser revivida. Portanto, sempre há uma tarefa em JS, mas às vezes também é uma tarefa em algoritmos - nós os amamos muito.
- A solução de problemas é talvez a principal habilidade do desenvolvedor. Tudo está mudando muito rapidamente na criação de interfaces. É como Lewis Carroll: "Você precisa correr o mais rápido possível para permanecer no mesmo lugar, mas para chegar a outro lugar, precisa correr duas vezes mais rápido". Todos os dias nos deparamos com novas tecnologias - é necessário contar com elas e ser capaz de entendê-las. Portanto, na terceira tarefa, propusemos entender as tecnologias com as quais um desenvolvedor iniciante geralmente não está familiarizado.
Na análise de cada tarefa, falaremos não apenas sobre o procedimento correto, mas também sobre erros comuns.
Tarefa 1: Portfólio
A primeira tarefa foi realizada pelo designer da Yandex.Coleções Alexei Cherenkevich, que sabe escrever, e seu colega no serviço, o designer de interface Sergey Samsonov.
Condição
Crie um site de portfólio: conte-nos sobre você, seu trabalho e expectativas da escola. O site deve corresponder ao layout proposto o máximo possível (links para layouts: 1000 px , 600 px , 320 px , especificação ). Estamos interessados apenas no layout, portanto, não use JavaScript.
Ao verificar, levaremos em conta:
- tamanhos de preenchimento, precisão de cores, estilo de fonte, tamanho do tamanho;
- layout semântico;
- a presença de vários estados de elementos: exibição de botões e links quando você passa o mouse, realça os campos de entrada ativos, etc;
- compatibilidade entre navegadores (verificada nas versões mais recentes de navegadores populares).
A vantagem será:
- uso de soluções CSS modernas: flexbox, grid, etc;
- layout adaptativo;
- uso de pré e (ou) pós-processadores, montagem, minificação, otimização do código de saída;
- Validação de formulário HTML, botão de upload de arquivo estilizado.
A tarefa é bastante volumosa, para que você possa pular o que não funcionará. Isso diminuirá um pouco a pontuação, mas você ainda poderá demonstrar seu conhecimento. Após a conclusão, envie-nos dois links - para o portfólio e o código-fonte no GitHub.
Os layouts propostos na tarefa não eram apenas telas para dispositivos móveis, tablets e desktops, mas também com uma especificação verdadeira.
Para adicionar o máximo de objetividade possível ao resultado do teste da primeira tarefa, havia muitos critérios para esse teste.
Critérios
Site concluído . Isso parece óbvio, mas alguns caras perderam completamente alguns blocos - ou queriam economizar tempo ou não conseguiram. O layout pode ser dividido condicionalmente em quatro telas principais: a tela principal com um avatar, um bloco com uma lista de expectativas do SRI, um bloco com um portfólio e um bloco com informações de contato. Eles podem ser feitos em seções ou simplesmente usando uma div, o principal é que todos os quatro blocos estejam disponíveis.
Layout de layout correspondente . O designer fez uma especificação separada (incluindo cores, tipografia, estados dos botões, etc.) para facilitar para os candidatos. Abaixo, havia uma dica sobre o recuo e os recursos da primeira tela. Muito satisfeito com os caras que levaram em conta todos os desejos do designer: por exemplo, a primeira tela deveria ter ficado não menos que a altura da janela de exibição.
Layout adaptável - é quando a interface não é apenas composta, de modo que em três resoluções tudo era pixel por pixel de acordo com o layout. Nos estados intermediários, o layout também não deve desmoronar. Alguém esqueceu de limitar a largura máxima do contêiner e puxou tudo para 1920 pixels, alguém mexeu com os planos de fundo, mas no geral os candidatos fizeram esse trabalho bem.
Layout semântico . “Quantas vezes eles disseram ao mundo” que o link deve ser emoldurado como <a>, o botão deve ser emoldurado como <button>. Felizmente, a maioria dos candidatos cumpriu esse requisito. Nem todo mundo reconheceu a lista à espreita nas expectativas do SRI, fazendo-a usar tags div, mas não é tão assustador. Houve um candidato que inseriu todas as tags semânticas que ele apenas conhecia - onde era necessário e onde não era necessário. Por exemplo, em vez de uma lista, <seção> e <artigo>. Ainda, semântica - trata-se de entender a composição da sua página e o objetivo de cada bloco (a maioria fez aqui), bem como sobre o uso de pré e / ou pós-processadores (poucos o fizeram aqui, embora isso também tenha importância) - less e scss foram mais frequentemente conectados) .
Controle deslizante de trabalho . Na tarefa, escrevemos que JS não pode ser usado. Aqui, a capacidade de resolver problemas foi testada - o controle deslizante pode ser feito usando os conectores <input> e <label for = "# id">. Toda a magia acontece no nível do seletor # button-N: marcado ~ .slider-inner .slider-slides. Quando clicamos em uma das caixas de entrada, ela entra no estado marcado. Podemos usar isso e atribuir a conversão desejada ao nosso contêiner com slides: transform: translate (-33%). Veja a implementação do slider
aqui .
Listas suspensas . Tudo se resumia a <input name = "accordion" type = "radio"> e a um seletor semelhante: .accordion-item input: selected ~ .accordion-item__content. Veja a implementação
aqui .
A presença dos estados: hover ,: active e: focu * . Um ponto muito importante. O conforto dependia dele durante a interação com a interface. O usuário deve sempre receber feedback sobre suas ações. Este item foi verificado ao longo da interação com o questionário. Se eu clicar no botão "Ligue para mim" e visualmente nada aconteceu (mesmo que a solicitação tenha sido enviada) - isso é ruim, porque clicarei nele novamente e novamente. Como resultado, dez pedidos serão enviados e voltarei a ligar dez vezes. Não se esqueça de que não há mouse em dispositivos móveis - o que significa que não deve haver um foco. E mais uma coisa que não dizia respeito àqueles que concordavam com o ponto da semântica. Se seu controle não for um elemento interativo, quando você passar o mouse sobre ele, o cursor permanecerá padrão. Parece muito desarrumado, mesmo que você tenha prescrito uma resposta ao passar o mouse. Não subestime o cursor: ponteiro.
Animações É importante que tudo o que acontece com os elementos da reação seja suave. Não há nada instantâneo na vida; portanto, a presença de transições em foco e ativa foi suficiente para tornar a interface mais agradável. Bem, aqueles que animaram o slider e as listas geralmente são bem-sucedidos.
Usando a mais recente tecnologia . Muitos usavam flex, mas ninguém concluiu a tarefa usando a grade. Um item contado se o flex foi usado corretamente. Se em algum lugar, devido a essas mesmas flexões, o layout estava se separando - infelizmente, você não recebeu pontos adicionais.
Validação do formulário . Tudo o que era necessário era adicionar o atributo necessário a cada formulário de entrada. Adicionamos pontos àqueles que validaram o campo de email como email.
Estilização do botão de upload de arquivo . Esperamos ver vários dos seguintes itens: <input type = "file" id = "file" name = "file" class = "inputfile" /> e <label for = "file"> Selecione um arquivo </label>. Além disso, era necessário ocultar a entrada e estilizar a etiqueta. Existe outra maneira comum - fazer uma entrada transparente e colocá-la em cima do botão. Mas nem todos os navegadores permitem estilizar <input type = ”file”>, e essa solução não pode ser chamada totalmente de navegador cruzado. E é semanticamente mais correto criar um rótulo.
Compatibilidade entre navegadores . Verificamos que está tudo bem, nas duas últimas versões dos navegadores modernos (sem o IE, os participantes tiveram sorte), bem como no Safari nos iPhones e no Chrome nos andróides.
Pelo contrário, obtivemos pontos se alguém usasse JS ou Bootstrap: ambos fizeram a tarefa toda sem sentido. Além disso, os participantes do Bootstrap não apenas receberam menos, mas também perderam muitos pontos pela semântica e pelos elementos implementados.
Aqueles que marcaram seu site em algum lugar da Internet não obtiveram uma vantagem específica - mas os inspetores ficaram muito felizes quando não precisaram baixar os repositórios e executá-los localmente em seu computador. Então, isso serviu como uma vantagem no karma.
A primeira tarefa foi muito útil principalmente para o aluno. Aqueles que não aceitamos agora têm um resumo resumido - você pode orgulhosamente anexá-lo a todas as respostas ou colocá-lo nas suas páginas gh.
Tarefa 2: Rota de Transporte
O autor da tarefa é Denis Balyko, chefe do grupo de interfaces de pesquisa.
Condição
Você tem um mapa do céu estrelado. Ele mostra o nome de cada estrela, bem como a distância dela a outras estrelas em segundos de luz. Implemente a função solução, que deve receber três argumentos: um objeto no qual as chaves são os nomes das estrelas e os valores são as distâncias das estrelas (no tráfego de mão única no espaço), bem como os nomes dos pontos inicial e final do caminho - início e término, respectivamente. A função deve retornar a menor distância entre o início da estrela e o final da estrela e o caminho ao longo do qual é necessário percorrer.
Assinatura da função:
const solution = function(graph, start, finish) {
Entrada de amostra:
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';
Saída de amostra:
{ distance: 90, path: ['start', 'A', 'D', 'finish'] }
Nota: a estrutura da solução está na pasta src /, coloque sua solução em solution.js.
A verificação da segunda tarefa foi a mais automatizada e objetiva. A maioria dos caras imaginou que era necessário implementar o algoritmo de Dijkstra. Aqueles que encontraram sua descrição e implementaram o algoritmo em JS são ótimos. No entanto, ao verificar a tarefa, encontramos muito trabalho com os mesmos erros. Pesquisamos na Internet por fragmentos de código e encontramos um artigo de onde os participantes escreveram o algoritmo. É engraçado que muitas pessoas tenham copiado o código do artigo junto com os comentários do autor. Esse trabalho recebeu uma pontuação baixa. Não proibimos o uso de nenhuma fonte, mas queremos que a pessoa se aprofunde no que escreve.
Critérios
Os principais pontos foram atribuídos para os testes. Às vezes, era evidente que os caras estavam confundindo o repositório, renomeando pastas e os testes caíram simplesmente porque não conseguiram encontrar os arquivos necessários. Este ano, tentamos ajudar esses caras e devolvemos tudo para eles. Mas no próximo ano planejamos mudar para um sistema de concursos, e isso não será perdoado.
Também havia critérios manuais "humanos". Por exemplo - a presença de um único estilo de código. Ninguém reduziu os pontos por usar tabulações em vez de espaços ou vice-versa. Outra questão é se você alternar aspas simples com aspas duplas de acordo com uma regra conhecida e colocar ponto e vírgula separadamente.
A clareza e a legibilidade da solução foram levadas em consideração separadamente. Em todas as conferências em todo o mundo, eles dizem que o trabalho do programador consiste em 80% da leitura do código de outras pessoas. Até crianças em idade escolar passam por uma revisão de código - com seus curadores e entre si. Portanto, este critério teve um peso significativo. Havia trabalhos em que não havia variáveis com mais de um caractere - por favor, não faça isso. Os comentários dos participantes ficaram muito satisfeitos - com exceção daqueles que eram idênticos aos comentários de Stella Chang.
O último critério é a disponibilidade de autotestes. Eles foram adicionados apenas por algumas pessoas, mas para todos isso se tornou uma enorme vantagem no karma.
A decisão correta:
const solution = function(graph, START, FINISH) {
Tarefa 3: Calendário de Eventos
Foi preparado pelos desenvolvedores de interface Sergey Kazakov e Alexander Podskrebkin.
Condição
Escreva um mini calendário para exibir a programação. Você pode fazer qualquer programação que desejar. Por exemplo, a programação das conferências front-end em 2019.
O calendário deve parecer uma lista. Não há outros requisitos de design. Torne possível definir lembretes de eventos por 3, 7 e 14 dias. Após o primeiro download com a Internet, o calendário deve abrir e funcionar offline.
Recursos úteis
Agenda de conferências front-end:
confs.tech/javascript?topics=javascript%2Bcss%2Bux
Trabalhadores do serviço:
developer.mozilla.org/en/docs/Web/API/Service_Worker_API/Using_Service_Workers
developers.google.com/web/fundamentals/primers/service-workers
API de notificações:
developer.mozilla.org/en/docs/Web/API/Notifications_API
A terceira tarefa foi a mais interessante de testar, porque havia muitas soluções, cada uma com a sua. Verificamos como o candidato lida com tecnologias desconhecidas - se ele sabe investigar, se testa suas soluções.
Critérios
O calendário inventado . Sim, ele ainda precisava ser maquiado. Havia quem entendesse a condição muito literalmente e não inserisse uma única linha de código CSS. Não parecia muito pessoal, mas se tudo desse certo, os pontos não diminuíam.
Recuperando uma lista de eventos de uma fonte . Como não é uma tarefa de digitação, a lista de eventos costurados nela não foi contada. Você sempre pode cancelar a conferência, reagendar e adicionar uma nova. Portanto, era necessário receber dados de fora e renderizar o layout já com base no JSON recebido. Era importante de qualquer forma (usando o método de busca ou XMLHttpRequest) obter os dados. Se uma pessoa adicionou um polyfill para busca e marcou sua escolha no leia-me, isso contou como um plus.
Registrando um trabalhador de serviço sem erros e trabalhando offline após a primeira inicialização.
Aqui está um exemplo de trabalhador de serviço com cache de agendamento na primeira inicialização. Detalhes sobre profissionais de serviço, seus recursos e formas de trabalhar com eles (estratégias para trabalhar com o cache, trabalhar offline) podem ser encontrados
aqui .
A capacidade de definir um lembrete para que ele realmente funcione após 3, 7, 14 dias. Era necessário entender a API de notificações, cujo
link estava diretamente na tarefa. Não esperamos nenhuma implementação específica para verificar se chegou a hora de pressionar. Qualquer opção de trabalho foi aceita: armazenamento no localStorage, IndexDB ou pesquisa periódica por um trabalhador do serviço. Você pode até criar um servidor push (eis
um exemplo ), mas ele não funcionaria offline. Foi igualmente importante dar um empurrão depois que a página foi fechada - e aberta depois de algum tempo. Se o lembrete "morreu" ao mesmo tempo em que a página foi fechada, a decisão não contou. É legal quando os caras pensam nos inspetores e aproveitam a oportunidade agora - para não esperar três dias.
A capacidade de criar o ícone na área de trabalho (PWA). Verificamos o arquivo
manifest.json com os ícones corretos. Alguns caras criaram esse arquivo (ou deixaram o gerado no CreateReactApp) - mas não adicionaram os ícones corretos. Em seguida, ao tentar instalar, ocorreu um erro como "precisa de outro ícone".
Estilo do código e estrutura do projeto . Como na segunda tarefa, analisamos um estilo de código único (mesmo que não corresponda ao nosso). Alguns caras estragaram linters - isso é ótimo.
Erros no console . Se houvesse um indicador diretamente no console de que algo estava errado e o participante não prestasse atenção, então levamos pontos.
Sumário
Engraçado nas decisões dos participantes:
- Um questionário continha o seguinte texto: “Um programador amigo ajudou a montar o aplicativo de reação. Eu lancei a ele perguntas sobre o que, como e por que, ele disse. Gostei muito, quero saber mais sobre isso. ” Apoiamos sinceramente este questionário, mas, infelizmente, o amigo do candidato realmente não o ajudou a fazer uma inscrição em funcionamento.
- Um candidato enviou um link para o GitHub, onde o arquivo RAR estava localizado - é difícil comentar sobre isso de alguma forma. :)
- Outro candidato no comentário na primeira linha do arquivo solution.js admitiu honestamente que copiou o algoritmo.
Recebemos questionários de 76 candidatos e selecionamos 23 deles. Os questionários nos foram enviados não apenas de Minsk, mas também de Moscou, São Petersburgo e até do Tartaristão. Alguns caras se surpreendem com suas profissões atuais: um deles é médico legista e o outro é estudante de uma universidade médica.
Resultou em uma distribuição interessante de sucesso na conclusão de tarefas. Os participantes concluíram a primeira tarefa em média em 60%, a segunda - em 50% e a terceira acabou sendo a mais difícil e foi concluída em média em 40%.
À primeira vista, as tarefas parecem complicadas e demoradas. O motivo não é que queremos eliminar o maior número possível de candidatos. Durante o treinamento, os alunos são confrontados com tarefas reais - para fazer um bate-papo, o Yandex.Music para crianças ou o Yandex.Weather para pessoas dependentes de meteo. Para fazer isso, você precisa de uma base inicial.
Lembro-me de como vi minha introdução ao SRI há dois anos e pensei que nunca poderia resolvê-lo. O principal neste momento é sentar, ler atentamente as condições e começar a fazer. Acontece que as condições contêm quase 80% da solução. Por exemplo, na condição da terceira tarefa (a mais difícil), adicionamos links aos trabalhadores de serviço e à API de Notificações no MDN. Os alunos que estudaram o conteúdo dos links enfrentaram dificuldades.
Eu realmente quero que este artigo seja lido por candidatos que planejam ingressar no SRI no futuro, não puderam ingressar na Escola Minsk ou começar a realizar qualquer outra tarefa de teste. Como você pode ver, é bem possível agir. Você só precisa acreditar em si mesmo e ouvir todas as dicas dos autores.