Os pensamentos dizem respeito ao desenvolvimento do iOS, mas, em outras áreas, a situação não é muito diferente.
Mais uma vez, após várias entrevistas, pensei em avaliar os desenvolvedores. A mudança para desenvolvedores “fortes” é claramente visível, equipes inteiras de idosos estão se reunindo. Mas aqui está o problema - há gradação, mas não há critérios claros. Como distinguir um meio de um idoso? O que junho precisa saber para obter um novo título? Você pode escrever outro texto sobre o conhecimento de algoritmos, a capacidade de resolver problemas de forma independente ou pode abordar a questão do outro lado: avaliar não o nível, mas o caminho. A qualidade da solução de problemas ainda é determinada não pela classificação das bolhas e nem pelos anos atrás do monitor.
Então, no começo, todos são iguais. Existe conhecimento básico, nenhuma experiência comercial. Mas, tendo recebido o primeiro emprego, o iniciante começa a se mover por uma das estradas.
Dorminhoco do molde
Copiar e colar domina o mundo, é tolice dizer que ninguém faz isso. Qual é a diferença entre form-sleeper e outros? O fato de ele não fazer mais nada. Existe um algoritmo padrão: uma tarefa típica é a Internet (raywenderlich, medium, stackoverflow, ...) - cópia sem sentido - fechando uma tarefa. O problema é que a tarefa não é analisada e as decisões não são avaliadas. Uma pessoa pode copiar o código por anos e todo o desenvolvimento será reduzido à velocidade da transferência. E se a variedade de tarefas for baixa, a pessoa se tornará mestre em copiar moldes. Nada o impedirá de orgulhosamente se firmar no título de Sênior em 5 anos, embora, se falar objetivamente, seja no máximo o meio.
Praticante
E se Essa pergunta não permite que uma pessoa simplesmente execute a tarefa. E se tomarmos uma solução diferente? E se for adotada uma abordagem diferente? Como isso funciona por dentro? E assim por diante e assim por diante. A curiosidade faz você escrever código, muito código. E com o tempo, a quantidade começa a se transformar em qualidade. O código se torna mais limpo, mais universal, mais escalável. Quando um livro / artigo sobre abordagens de desenvolvimento cai nas mãos de uma pessoa, ele fica surpreso, porque ele mesmo usou tudo isso por um longo tempo.
Teórico
Mesmo assim, mas vice-versa) Se você resolver um problema, por que não ler como ele foi resolvido antes de você? Como tarefa, não é apenas resolver, mas fazer o que é certo. E o teórico estuda a experiência dos erros dos outros para não preenchê-los.
O problema é que o que é descrito são cavalos esféricos no vácuo. Cada desenvolvedor tem todos os três, e o objetivo desses pensamentos caóticos é incentivar a avaliação não por níveis míticos, mas pela proporção de abordagens. E antes de tudo, perguntar quem exatamente é necessário. Se houver um grande fluxo de tarefas simples semelhantes, o dorminhoco do formulário será melhor que os outros. É necessário resolver problemas complexos - eu aconselharia um teórico, será mais fácil para ele estudar pequenos detalhes e entender a essência do processo. Se as tarefas forem complexas e exigirem velocidade, será obviamente necessário um praticante.
Agora um pouco sobre as entrevistas diretas. Não faz sentido pedir algoritmos, SOLID, pedir exemplos de código. Entrevistar e escrever código não são a mesma coisa.
Se você precisar de um teórico, peça que ele leia a última, qual das leituras causou a maior impressão nele. Ou talvez ele discorde de alguma coisa e tenha sua própria visão?
Se você precisar de um médico, pergunte sobre seus projetos. Sobre tarefas interessantes. Sobre as tecnologias e bibliotecas usadas e por quê.
Se você precisar de um dorminhoco, os melhores indicadores serão anos de experiência e uma variedade de tarefas.