[quote=Rodrigo.Rocha][quote=Alexandre Saudate]Não estou falando dele resolver o problema da empresa, e muito menos fazer isso de graça. Estou apenas dizendo que ele deve ser capaz de provar isso, de preferência, custando o mínimo possível - ou seja, não tendo que encarar uma entrevista, que também tem um custo pra empresa.
Geralmente, os profissionais provam isso através de sua experiência / indicações. Mas não é o caso de um iniciante.
[]'s[/quote]
Publicar alguma coisa no github != provar que vc é capaz de alguma coisa.[/quote]
Acho que o github é uma espécie de portfólio, num ultimo recurso acredito sim que contratante visualize a metodologia que o programador utilizou.
particularmente estou investindo em um projeto pessoal, apostando nisso…
[quote=Rodrigo.Rocha][quote=A H Gusukuma]
Para um programador experiente, basta dar uma olhada no projeto e vai notar vários aspectos para fazer uma avaliação do autor.
Participar de projetos open source também ajuda o candidato.
[/quote]
Por exemplo?
[/quote]
Padrões de projeto, boas práticas, falhas, erros, domínio da linguagem, conceitos básicos, thread-safe, …
[quote=moisesnt]
Acho que o github é uma espécie de portfólio, num ultimo recurso acredito sim que contratante visualize a metodologia que o programador utilizou.
particularmente estou investindo em um projeto pessoal, apostando nisso…[/quote]
[quote=Rodrigo.Rocha][quote=moisesnt]
Acho que o github é uma espécie de portfólio, num ultimo recurso acredito sim que contratante visualize a metodologia que o programador utilizou.
particularmente estou investindo em um projeto pessoal, apostando nisso…[/quote]
[quote=Rodrigo.Rocha][quote=moisesnt]
Acho que o github é uma espécie de portfólio, num ultimo recurso acredito sim que contratante visualize a metodologia que o programador utilizou.
particularmente estou investindo em um projeto pessoal, apostando nisso…[/quote]
[quote=Rodrigo.Rocha][quote=A H Gusukuma]
Padrões de projeto, boas práticas, falhas, erros…[/quote]
Se seu projeto não resolve nenhum problema vc falhou como programador. Não importa o quão elegante é seu código, nem quantos design patterns usa.
[/quote]
Acho que o amigo foge muito do foco, estamos falando em avaliar um candidato a programador/desenvolvedor.
Como eu disse, isso não é produtivo.
O fato de você fazer uma observação ou uma frase correta, não leva a deduzir que esteja correto no todo.
Por falar nisso, conhece o livro: “Como Vencer um Debate Sem Precisar Ter Razão”, Schopenhauer?
[quote=Rodrigo.Rocha]Como avaliar candidato é um assunto interessante sem dúvida, mas o tópico continua sendo sobre a dificuldade de encontrar emprego.
Você conhece alguém que arrumou emprego por que escrevia código “elegante”?[/quote]
Só por isso não, mas também por isso sim.
[quote=Rodrigo.Rocha][quote=Alexandre Saudate]
Se você fosse contratar alguém aparentemente sem experiência, o que você faria? Comece desde a seleção de CV’s. [/quote]
Analisaria a formação do candidato e seus projetos.[/quote]
[quote=Alexandre Saudate][quote=Rodrigo.Rocha][quote=Alexandre Saudate]
Se você fosse contratar alguém aparentemente sem experiência, o que você faria? Comece desde a seleção de CV’s. [/quote]
Analisaria a formação do candidato e seus projetos.[/quote]
E que projetos um iniciante teria?[/quote]
Quando checa muita coisa sem lógica acaba dando inconsistência…
[quote=A H Gusukuma]Como eu disse, isso não é produtivo.
O fato de você fazer uma observação ou uma frase correta, não leva a deduzir que esteja correto no todo.
Por falar nisso, conhece o livro: “Como Vencer um Debate Sem Precisar Ter Razão”, Schopenhauer?
[/quote]
Não sei se entendi o que está dizendo. O seu problema é com a observação do Alexandre Saudate que programadores são resolvedores de problemas ou com o fato de serem avaliados pelo tipo de problema que se interessam em resolver (ao invés de outros atributos subjetivos como “qualidade do código”)?
[quote=Rodrigo.Rocha][quote=A H Gusukuma]Como eu disse, isso não é produtivo.
O fato de você fazer uma observação ou uma frase correta, não leva a deduzir que esteja correto no todo.
Por falar nisso, conhece o livro: “Como Vencer um Debate Sem Precisar Ter Razão”, Schopenhauer?
[/quote]
Não sei se entendi o que está dizendo. O seu problema é com a observação do Alexandre Saudate que programadores são resolvedores de problemas ou com o fato de serem avaliados pelo tipo de problema que se interessam em resolver (ao invés de outros atributos subjetivos como “qualidade do código”)?[/quote]
Não, quem trabalha em TI tem que ser um “resolvedor de problema”, essa é sua principal característica.
E “qualidade do código” apesar de alguns aspectos subjetivos, hoje temos muito conhecimento acumulado para avaliar objetivamente, não se engane.
A citação do livro foi por outro motivo, só me ocorreu.
[quote=Rodrigo.Rocha][quote=A H Gusukuma]Como eu disse, isso não é produtivo.
O fato de você fazer uma observação ou uma frase correta, não leva a deduzir que esteja correto no todo.
Por falar nisso, conhece o livro: “Como Vencer um Debate Sem Precisar Ter Razão”, Schopenhauer?
[/quote]
Não sei se entendi o que está dizendo. O seu problema é com a observação do Alexandre Saudate que programadores são resolvedores de problemas ou com o fato de serem avaliados pelo tipo de problema que se interessam em resolver (ao invés de outros atributos subjetivos como “qualidade do código”)?[/quote]
Hey, eu não disse que programadores são resolvedores de problemas, eu disse que todo profissional o é. Se um contratador não tivesse um problema a ser resolvido, ele não contrataria alguém pra resolver.
E acho que todo profissional, antes de ser contratado, é avaliado por quem contrata para checagem - se o profissional tem ou não a capacidade (também conhecida como experiência) para resolver o problema.
Somente proponho que o próprio programador pule uma etapa considerada cara (a entrevista) ao elaborar uma espécie de portifólio. Assim, o contratador checa, antes, o que o programador conhece. Assim, consegue dizer se o programador é capaz de resolver os problemas que a empresa precisa que ele resolva ou não.
Uma coisa que um candidato deve ter em mente é que ele é um “produto”, e como tal precisa ser “vendável”. Cabe a ele mostrar porquê o entrevistador deve considerá-lo “comprável”.
[quote=Rodrigo.Rocha][quote=Alexandre Saudate]
Hey, eu não disse que programadores são resolvedores de problemas, eu disse que todo profissional o é. Se um contratador não tivesse um problema a ser resolvido, ele não contrataria alguém pra resolver.
E acho que todo profissional, antes de ser contratado, é avaliado por quem contrata para checagem - se o profissional tem ou não a capacidade (também conhecida como experiência) para resolver o problema.
Somente proponho que o próprio programador pule uma etapa considerada cara (a entrevista) ao elaborar uma espécie de portifólio. Assim, o contratador checa, antes, o que o programador conhece. Assim, consegue dizer se o programador é capaz de resolver os problemas que a empresa precisa que ele resolva ou não.
[]'s
[/quote]
Se for um portfólio de projetos prontos pra serem usados, concordo com vc.
Linhas de código no github? nobody gives a shit.[/quote]
Com certeza. Projetos completos, de fim a fim, que explicitam alguns requisitos avaliados pelo programador e que mostrem como ele resolveu. Afinal de contas, é fácil fazer uma ou outra classe que seja robusta. Difícil é fazer um projeto inteiro.
[quote=A H Gusukuma]Uma coisa que um candidato deve ter em mente é que ele é um “produto”, e como tal precisa ser “vendável”. Cabe a ele mostrar porquê o entrevistador deve considerá-lo “comprável”.
[/quote]
Fale por vc. Eu não sou produto e nem estou à venda. Eu resolvo problemas.