# Linhas de código aceitáveis ​​para projetos a serem apresentados ao entrevistador? [fechadas]

Vou me formar em breve e tenho pensado. Tenho alguns projetos / scripts realmente pequenos (~ 100-200 LOC) que fiz no meu tempo livre e os tenho no Github. Eu queria saber se eles são "dignos" o suficiente para serem apresentados aos futuros empregadores? Ou devo incluir apenas aqueles que são grandes (~ 1000 LOC)?

Quando entrevistamos, pedimos isso na entrevista final. Começarei dizendo que o tamanho não importa e depois me qualifico um pouco (nem sempre é assim).

Se eu pedir a alguém para enviar um pedaço de código do qual se sinta orgulhoso e queira marcar seu nome e me enviarem um único arquivo, vou perder a confiança. Em um caso, recebi um arquivo code-behind ASCX longo e não há nada que eu possa ler além de "garoto gosta do código na camada da interface do usuário".

Em outros casos, recebi projetos consideráveis ​​inteiros. Por um lado, isso me deixa mais confiante, mas também me dá muito o que fazer, sem me aprofundar muito.

Mas aqui está o segredo: o código em si não importa que muito. Eu posso fazer buracos em qualquer coisa que você me der. O que importa é como você reage. Não seja argumentativo por causa disso, mas também não concorde comigo por causa disso. Talvez eu não acredite no que estou dizendo, e mesmo que eu o respeite por apoiar seu código de maneira construtiva.

Não é o tamanho do projeto. É a qualidade. Aproveite o tempo para fazer o que é certo, para que valha a pena ser uma peça do portfólio. Desde que o projeto seja suficientemente grande para demonstrar o conhecimento que você deseja transmitir, apenas a qualidade será importante.

Acho que a pergunta depende de como e quando você planeja apresentá-las a um futuro empregador. Eles estão indo para um item de linha em seu currículo ou os empregadores estão pedindo que você faça uma breve descrição de algo que você fez durante uma entrevista?

Para um item de linha no currículo, eu me inclinaria para projetos apenas maiores. Por outro lado, um script menor é algo que você pode descrever para um entrevistador em pouco tempo e o conteúdo completo pode ser apreendido.

No final, depende mais de quão interessante é a coisa que você está mencionando. Se o script faz algo novo e por acaso não precisa de muito código, há um peso nisso.

"Julga-me por meu tamanho, não é?" - Yoda

O que importa completamente é a qualidade. Um projeto impressionante é determinado pela quantidade de coisas que pode fazer e pela complexidade das coisas que pode fazer, e isso é tudo o que importa no que diz respeito aos resultados finais.

Se o seu projeto tiver 1.000 linhas, das quais o mesmo recurso de 100 linhas de código foi copiado 10 vezes com pequenas modificações a cada vez, você parecerá um mau programador. Você parecerá um péssimo programador porque não conseguiria criar algo bem . Você falharia em manter seu projeto em manutenção, legível, gerenciável e escalável.

Basta criar coisas realmente grandes coisas assim . Não há necessidade de considerar o comprimento.

Pessoalmente, não acho que o #LOC seja o fator determinante. Em vez disso, acho que deve ser a criatividade, a complexidade e o problema que o projeto resolve que deve determinar os exemplos de código que você envia. A maioria dos empregadores não deseja ler linhas de código apenas para encontrar um trecho que comprove que você entende algoritmos complexos e similares. Se você é capaz de produzir projetos que exibem suas habilidades sem muito peneirar, acho que, em última análise, é uma qualidade mais impressionante do que a quantidade de linhas de código. Dito isto, ter o link para um projeto grande é útil se eles puderem compilar o projeto e garantir que ele esteja funcionando. No entanto, tudo isso mostra realmente a sua capacidade de escrever um programa que separe adequadamente as preocupações.

Tamanho não importa (como em LOC) realmente. Está (quase) em correlação direta com o idioma (mais vs menos linhas para a mesma coisa), portanto, seria injusto julgar qualquer coisa com base nisso.

Eu classificaria o projeto como grande ou pequeno, com base no número de recursos, interesse pessoal para mim e no número de usuários que ele ajudou a resolver um problema (esse deveria ter sido o primeiro da lista).

Codificar é como esculpir - não se trata de escrever mais, é de tirar o que não é necessário.

O trabalho de um programador não é produzir linhas de código; o trabalho é, em vez disso, descobrir, de todas as massas de códigos indesejados que poderiam ser escritos, qual é o conjunto menor e mais limpo que resolverá um problema específico.

Se um de seus projetos mostrar a menor solução possível, mais simples e mais limpa para um problema, use-a como referência. Se não, não.

Nunca me pediram para fornecer exemplos de código a um entrevistador. Normalmente, as empresas que querem ter certeza de que sabe pensar e codificar fazem um exame. Na entrevista técnica, você pode ser solicitado a escrever um pequeno algoritmo, mas a maioria das entrevistas técnicas que fiz para desenvolvedores ou para mim em discussões.