Pergunta de entrevista para Desenvolvedor Frontend

Como você construiria um formulário de cadastro cujos erros de validação sejam realmente úteis, inclusive para usuários de leitor de tela?

O que o entrevistador está avaliando, como estruturar sua resposta e um exemplo falado que você pode adaptar.

Resposta rápida

Use labels de verdade ligados aos inputs, valide no blur e no envio em vez de a cada tecla, e coloque cada mensagem de erro ao lado do seu campo com aria describedby apontando para ela mais aria invalid no input. No envio, mova o foco para o primeiro campo inválido ou para um resumo dos erros. Mantenha as restrições e os tipos nativos para teclados de celular e preenchimento automático funcionarem, e nunca sinalize erro só com cor.

Por que os entrevistadores perguntam isso

Formulários são onde falhas de acessibilidade custam dinheiro de verdade, então esse é um teste prático e não uma pergunta de valores. O entrevistador quer ouvir sobre associação programática entre erro e campo, gestão de foco no envio e comportamento de live region, coisas que ferramentas automáticas não checam. Também revela se você valida de um jeito que irrita usuários, como mostrar erro de email antes de a pessoa terminar de digitar.

Como estruturar sua resposta

  • Comece pela semântica nativa: labels, tipos de input, required.
  • Dê a regra de tempo de quando a validação dispara.
  • Explique o vínculo programático entre input e mensagem de erro.
  • Descreva o tratamento de foco num envio que falha.

Exemplo de resposta

Exemplo falado, em primeira pessoa

Começo nativo, porque a maior parte vem de graça: um label de verdade com atributo for, o tipo de input certo para o celular mostrar o teclado certo, atributos de autocomplete para gerenciadores de senha funcionarem, e required onde se aplica. Sobre o tempo, valido um campo no blur e tudo no envio, nunca a cada tecla, já que dizer a alguém que o email é inválido enquanto ela ainda digita é só ruído. Depois que um campo foi marcado como inválido, aí sim revalido conforme a pessoa digita, para o erro sumir assim que for corrigido. Cada mensagem fica logo abaixo do seu input, e o input recebe aria invalid true e aria describedby apontando para o id da mensagem, que é o que faz um leitor de tela anunciar o erro quando o foco chega ali. Num envio que falha, movo o foco para o primeiro campo inválido, ou para um resumo curto de erros no topo com links para cada campo se houver vários. E erros nunca são só cor; há texto e ícone, porque uma borda vermelha sozinha não significa nada para muita gente.

Vai encarar essa entrevista em breve? O GhostPilot escuta a sua chamada ao vivo, identifica a pergunta no instante em que ela é feita e coloca uma resposta estruturada na sua tela em tempo real. Teste na sua próxima entrevista simulada ou pegue um Session Pass de $29, sem assinatura, para a hora da verdade.

Veja como funciona

Perguntas de acompanhamento que você pode esperar

  • Quando você usaria uma live region aqui, e quando ela seria irritante?
  • Como você trataria um erro do servidor que chega depois do envio?
  • Como você testa isso sem um leitor de tela disponível?

Mais perguntas para Desenvolvedor Frontend

Seu entrevistador vai fazer a própria versão desta. Cole a descrição real da vaga no Question Predictor gratuito e receba as 20 perguntas que essa vaga tem mais chance de fazer, com o que cada uma está de fato sondando.

Prever minhas perguntas

Ensaie as perguntas difíceis antes que elas apareçam

Pratique com um copiloto ao vivo e depois entre pronto. Um Session Pass de $29 te leva até o fim da entrevista, sem assinatura e sem amarras.

Instalar o GhostPilot