HTML e CSS são difíceis de entrevistar por alguns motivos:
Eles são muito básicos, comparados, por exemplo, a uma linguagem de programação,
Eles dependem muito do contexto do trabalho. Exemplos:
Se você criar uma escala do Google, sites extremamente rápidos e otimizados, as pessoas que entrevistar para o trabalho não poderão ignorar o que são sprites CSS.
Se você criar sites válidos para XHTML W3C, deverá garantir que os candidatos saibam a diferença entre XHTML 1.0 e XHTML 1.1 ou para quais são os atributos obrigatórios <img/>etc.
Se você criar sites terríveis e cheios de hacks, pergunte às pessoas que entrevistar sobre como elas irão fazer tal ou qual hack, como elas servem CSS diferente para diferentes navegadores, etc.
etc.
Se for um trabalho puro de HTML e CSS, a pessoa terá que trabalhar com designers, por um lado, e desenvolvedores, por outro. Eles precisam conhecer HTML e CSS, mas o que é muito mais valioso é a capacidade de interagir com essas pessoas e entender as necessidades dos designers, os requisitos dos desenvolvedores e as restrições de HTML e CSS.
Por exemplo, eles precisam saber como estruturar seu HTML de tal maneira que seria fácil para um desenvolvedor JavaScript adicionar interatividade posteriormente.
Você pode começar com algumas perguntas básicas:
Qual é o seu navegador favorito?
Se a pessoa responder "Internet Explorer", pare a entrevista imediatamente: você não precisa de alguém assim.
Não eu estou brincando. A resposta é irrelevante. Em vez disso, você pode perguntar o seguinte:
Conte-me sobre as ferramentas de depuração que você usa no seu navegador favorito.
Primário usando o Chrome, trabalho diariamente com as Ferramentas do desenvolvedor. Essas ferramentas me permitem:
Veja os pedidos feitos a partir de uma página,
Estude o tempo necessário para carregar uma página e os recursos relacionados, especialmente a pesquisa de DNS, os tempos de espera e recebimento,
Estude os cabeçalhos dos elementos enviados, bem como o indicador de cache,
Veja o DOM e estude como os seletores de CSS são aplicados,
Também uso o YSlow, que me serve como uma lista de verificação para otimização de um site que exige alta escalabilidade. O YSlow também é uma boa ferramenta para determinar se o servidor está configurado corretamente (enviando cabeçalhos corretos, etc.).
No Firefox, eu uso o Firebug, a ferramenta muito semelhante às Ferramentas do desenvolvedor do Chrome. As ferramentas de desenvolvedor também estão disponíveis em novas versões do Internet Explorer e também permitem que eu mude para as visualizações de compatibilidade do IE7 ao IE10. Esse último recurso é muito útil, pois sem ele, eu seria obrigado a instalar várias máquinas virtuais apenas para testes herdados ou a usar muito mais frequentemente os serviços pagos, como o Litmus .
Por favor, explique-me sobre o que <dl/>é a tag? Qual foi o uso pretendido para esta tag? Como é usado na prática? O que você acha desse uso estendido?
Aqui, você deseja que a pessoa possa explicar que <dl/>é para dicionários, associando uma chave <dt/>, com um ou vários valores <dd/>,. Embora o uso primário dessa tag tenha sido puramente relacionado à semântica, na prática foi amplamente utilizado para substituir tabelas, um bom exemplo sendo o PHPBB3. Isso é bom quando as tabelas estão atrasando a renderização da página, mas deve ser usada com cautela: não apenas as tabelas ainda são adequadas em muitos casos para melhor descrever os dados, mas também pode haver outros meios, como os comuns listas, para descrever o conteúdo sem usar <dl/>.
Qual é a diferença entre layouts fixos e fluidos? Quais são os prós e os contras de cada um?
O layout fixo possui larguras predefinidas dos elementos. Os elementos de um layout fluido dependem da largura da página.
O layout fixo facilita o design da página, especialmente quando há muitos gráficos de largura total. Mesmo sem gráficos, ainda é mais fácil, porque você se importa apenas com um caso preciso. Por exemplo, sendo Programmers.SE um site de layout fixo, a coluna que exibe as perguntas e as respostas sempre tem o mesmo tamanho. Se um layout fluido fosse usado para esta coluna, isso criaria um problema: em telas pequenas, o texto seria ilegível, porque as linhas seriam muito curtas, enquanto em telas grandes as linhas seriam extremamente grandes, portanto o texto seria ilegível também.
O problema com o layout fixo é que ele funciona bem para algumas resoluções mais usadas, mas falha mais ou menos em todo o resto. Torna-se especialmente importante desde a adoção de monitores amplos e muito grandes e o crescente uso da Internet em dispositivos móveis pequenos.
O layout fluido ajuda nisso, mas o design é mais difícil de fazer para esse site. Em alguns cenários de projetos mal gerenciados, isso pode levar a invasões de HTML e CSS, páginas grandes, baixa manutenção e, durante o desenvolvimento, custos mais altos e prazos perdidos.
Em uma página com um layout fluido, como você pode evitar a situação em que uma coluna de texto se torna muito grande para ficar legível?
Você pode limitar a largura de uma zona de texto usando a max-widthpropriedade
O que você acha desse pedaço de código <p color="Red" align="Center">Text here</p>:?
O trecho de código possui uma falha para misturar a lógica da apresentação dentro do HTML. A lógica de apresentação deve ser colocada no CSS por vários motivos:
- Ajuda a separar as preocupações e o código limpo, o que significa manutenção mais barata posteriormente,
- Torna os estilos reutilizáveis de página para página, o que (fora das preocupações de manutenção) ajuda a garantir que você esteja usando os mesmos estilos em todo o site,
- Ajuda a reduzir a largura de banda, pois os arquivos CSS serão armazenados em cache.
Após algumas perguntas básicas como essa, você pode fazer outras mais complicadas:
Como você evita a duplicação de cores ou fontes em CSS, quando essas cores ou fontes são aplicadas a vários elementos que não podem ser direcionados por um único seletor? Existem desvantagens?
Você faz isso usando pré-processadores CSS, como Sass ou LESS. Eles permitem definir cores, fontes e outras partes do estilo dentro de variáveis que você pode usar posteriormente em seus estilos.
As desvantagens dos pré-processadores CSS são:
Às vezes, eles precisam alterar o fluxo de trabalho de desenvolvimento e implantação para ter o código CSS atualizado no navegador,
Eles são conhecidos apenas por alguns desenvolvedores, o que torna mais difícil para uma nova pessoa ingressar ou manter o projeto posteriormente,
Não existem IDEs bons e rápidos para Sass ou LESS, e a integração nos IDEs mais populares é bastante decepcionante.
Dê-me um exemplo de um hrefvalor de uma imagem que esteja na CDN, pois essa imagem é exibida em um site que pode ser acessado por HTTP e HTTPS.
Como o HTTPS precisa que todos os recursos chamados também estejam no HTTPS (caso contrário, um aviso de segurança será exibido ao usuário em muitos casos), não é possível especificar o link como http://cdn.example.com/image.png. Para vincular corretamente à imagem, //cdn.example.com/image.pngdeve ser usado; o navegador será anexado previamente http:ou https:dependendo do contexto.
Como o tamanho das páginas e o número de solicitações em um site não podem ser otimizados e o conteúdo não pode ser alterado nem o AJAX adicionado, como você dá a impressão ao usuário de que o site é mais rápido? O que isso envolve da perspectiva do HTML?
Se o HTTP 1.1 for usado, a página poderá estar em pedaços . Isso significa que as primeiras partes aparecerão mais rapidamente, dando a impressão de que o site é mais rápido do que na realidade. A codificação de transferência fragmentada é impossível no HTTP 1.0, o que significa que não há nada a fazer nesse caso.
Ser capaz de veicular o conteúdo em blocos requer, da perspectiva do HTML, reordenar os elementos, colocando os mais críticos na parte superior do arquivo (o que não significa que eles precisariam aparecer na parte superior da página). Por exemplo, em um site de comércio eletrônico, quando o usuário deseja ver os detalhes do produto, o primeiro pedaço pode conter os <head/>detalhes do produto. O próximo pedaço pode conter os elementos principais, como o logotipo do site, o menu principal, os direitos autorais etc. Por fim, o último pedaço pode conter a seção "Pessoas que compraram este também compraram", os comentários e as classificações do produto, o "Compartilhar no Facebook" etc.
Por fim, você pode pedir ao candidato para trabalhar em um cenário do mundo real. Pode ser qualquer coisa, como a mais fácil abaixo, para os cenários complexos em que a pessoa precisa lidar com sprites de CSS ou outras técnicas avançadas de otimização, com inconsistências no navegador etc.
Por favor, você pode criar uma página XHTML com duas zonas: a esquerda, com uma lista, e a direita, com texto. Duas zonas são separadas por uma linha vertical, que se estende da parte superior até a parte inferior da página. Como lista e texto com tamanho variável, não é possível prever qual terá a maior altura. Você não pode usar <table/>s.
Na verdade, é bem simples, mas mostra se a pessoa tem o reflexo de pensar em altura. Um candidato inexperiente criará a float:leftzona e a border-left:solid 1px #ccc;zona, mas esqueça de adicionar a borda à zona esquerda e estendê-la para que duas bordas fiquem no mesmo local.
