Como evitar ser contratado por empresas candidatas às histórias do DailyWTF? [fechadas]

Estou lendo os arquivos do Daily WTF e, especialmente, as histórias sobre empresas relacionadas à TI que têm uma abordagem completamente errada do desenvolvimento de software, o trabalho de um desenvolvedor etc.

Algumas histórias são totalmente horríveis: uma empresa não possui uma rede local por motivos de segurança, outra possui um servidor de controle de origem que só pode ser acessado pelo gerente , etc. Acrescente a ela todas as histórias sobre gerentes que não conhecem qualquer coisa sobre seu trabalho e tomar decisões estúpidas sem ouvir ninguém.

O fato é que não vejo como saber se você será empregado dessa empresa durante uma entrevista. É claro que, às vezes, um entrevistador conta coisas estranhas que dão a você uma idéia de que algo dá muito errado com a empresa (no meu caso, o último gerente disse que eu deveria trabalhar 100% do meu tempo na Área de Trabalho Remota, conectada a uma rede antiga e antiga). slooooow, porque "evita que várias pessoas modifiquem o mesmo código fonte" ; talvez eu deva explicar o que é o SVN).

Mas na maioria dos casos, você não conseguirá obter informações suficientes durante a entrevista para obter a imagem exata de uma empresa.

Então, como evitar ser empregado por esse tipo de empresa?

• Pensei em pedir para ver alguns documentos, como guia de documentação ou diretrizes de estilo de código . O problema é que eu moro na França, e aqui, a maioria das empresas não possui esses documentos e, nos raros casos em que esses documentos existem, estão desatualizados, mal escritos, nunca são usados ​​ou o forçam a faça coisas que não fazem sentido .

• Também pensei em pedir para ver como os programadores realmente funcionam . Mas ver que eles têm telas duplas ou "mobília moderna e moderna de peidos" não significa que eles não tenham pessoas tomando decisões estranhas, tornando impossível trabalhar lá.

Você já esteve nessas situações? O que você tentou? Funcionou?

Lembre-se de que as entrevistas são uma via de mão dupla. Faça perguntas abertas que avisam que eles sabem o que estão fazendo. E aprenda a "ler nas entrelinhas" ao avaliar suas respostas. Por exemplo:

Como vocês garantem que o software que você está escrevendo não seja ruim? (reformulado para algo mais "apropriado" se você é chato)

Boa resposta: "Usamos testes de unidade, temos um departamento de controle de qualidade e revisões de código".

Não precisa ser isso. A pessoa que você está entrevistando também não precisa ter a mesma resposta que eu dei. Você está olhando apenas para garantir que a empresa valorize o código que escreve até certo ponto e não vá empurrá-lo para fora da porta com um abandono imprudente.

Resposta ruim: "Bem, pretendemos fazer mais daquelas coisas de 'teste de unidade'. Nós apenas não chegamos a isso"

Novamente, o foco é menos nos testes de unidade e mais na atitude do entrevistador em relação ao problema. Geralmente, "sabemos que precisamos, apenas não o fizemos" é uma bandeira vermelha. Isso significa uma das várias possibilidades:

1. Seus colegas de trabalho serão preguiçosos.
2. A gerência não dá tempo para usar o processo adequado.
3. Seus colegas de trabalho não são inteligentes o suficiente para entender os testes de unidade.

Nada disso é bom (mas alguns são piores que outros).

Descreva o processo que sua empresa usa para adicionar um recurso (da decisão de que o recurso é necessário para enviá-lo ao cliente).

Boa resposta: "Os executivos decidem que um recurso é uma boa idéia e consultam os programadores para ver como é fácil de implementar. Os programadores e a equipe técnica decidem sobre uma arquitetura e a implementam. . "

Resposta ruim: "Os empresários dizem aos programadores o que devem fazer e o fazem".

Como acima, a resposta em si não é tão importante quanto a atitude. A boa resposta indica que o lado comercial e o técnico trabalham juntos para criar um produto. A resposta incorreta indica que o gerenciamento vê os programadores como datilógrafos pagos em excesso.

Em resumo , lembre-se de fazer as perguntas certas durante a entrevista. E lembre-se de que respostas específicas não são tão importantes quanto a atitude por trás dessas respostas. Por fim, não esconda nada . Fazer perguntas difíceis indica que você está realmente interessado no trabalho e que pensa que é bom o suficiente para ser um pouco exigente sobre quem o empregará.

Você poderia dar a eles o teste Joel:

1. Você usa o controle de origem?
2. Você pode fazer uma compilação em uma única etapa?
3. Você faz construções diárias?
4. Você tem um banco de dados de bugs?
5. Você corrige bugs antes de escrever um novo código?
6. Você tem um cronograma atualizado?
7. Você tem uma especificação?
8. Os programadores têm condições de trabalho silenciosas?
9. Você usa as melhores ferramentas que o dinheiro pode comprar?
10. Você tem testadores?
11. Os novos candidatos escrevem código durante a entrevista?
12. Você faz testes de usabilidade no corredor?

Mantenha seu currículo circulando por um mês ou mais depois de ser contratado e, se as coisas não estiverem boas, não tenha medo de aproveitar outra oportunidade. As empresas costumam ver o seu emprego como estágio por um período de tempo, porque querem ter certeza de que você trabalha tão bem quanto você entrevistou. É justo que você faça o mesmo se as coisas realmente estiverem no nível diário da WTF.

Vou assumir a posição pessimista e não tradicionalmente engenheira sobre isso.

Você não pode.

Toda empresa, sem exceção, é candidata a histórias diárias da WTF. Isso ocorre porque cada pessoa, sem exceção, não importa qual seja sua profissão e qual seja sua experiência, pode ser uma estupidez em alguns aspectos de sua vida profissional escolhida.

Sim. Isso inclui você, a pessoa que está lendo isso. (Se você não acredita que isso se aplica a você, acho que acabamos de encontrar uma de suas áreas de incompetência ...)

Talvez você possa tentar ver as coisas de maneira diferente.

Ser contratado por uma empresa que está nos holofotes do The Daily WTF é uma oportunidade para você mostrar como pode resolver problemas. Enormes problemas.

Você pode ver essas dificuldades como oportunidades .

Em vez de usar o Joel Test para avoidempresas, use- improveas.

O que poderia ser mais emocionante do que isso?

Se você entrar na companhia com seu cavalo branco, como Napoleão, dizendo que eles estão todos errados, você será expulso muito rapidamente.

A oportunidade é que você será capaz de fazer propostas construtivas , apoiadas em fatos e referências . Se feito como descrito na frase anterior, você será proposto a cuidar disso na maior parte do tempo (essa é a oportunidade). Em muito poucos casos, você será ignorado.

Lembre-se de que qualquer entrevista é uma via de mão dupla. O empregador está tentando determinar se você é um bom candidato. Da mesma forma, você deve tentar determinar se vale a pena trabalhar para a empresa. Pergunte a um monte de perguntas. Descubra o que é importante para você e pergunte sobre isso. Pergunte aos entrevistadores o que eles gostam e o que não gostam na empresa.

Além disso, eu apóio a recomendação do outro pôster para fazer o teste de Joel .

Até um gerente psicótico megalomaníaco pode dirigir uma equipe que passa no teste Joel. Como eles reagem quando os prazos não estão sendo cumpridos? O CIO se reporta ao CEO ou CFO? Isso pode lhe dar uma idéia da importância da TI em uma empresa que não é de software.

Por que a posição está disponível? Eles têm muita rotatividade?

Procure maneiras de ver se os programadores estão sobrecarregados. Ninguém teve férias em vários meses a um ano? Você não pode derrotar uma empresa que distribui férias, mas ninguém sente que pode aguentar.

Você pode ajustar más práticas de teste e sistemas de controle de código. Não pode curar loucura.

Aqui está o que eu faria se fosse você:

• tente obter a possibilidade de entrevistar um ou mais programadores da empresa e pergunte a eles qual é o dia típico de seu trabalho. Pode ser difícil perguntar se eles não fornecem, mas uma empresa que fornece isso é uma grande vantagem no meu livro
• pergunte a eles como um novo recurso é desenvolvido, normalmente, e como o trabalho é compartilhado entre programadores.

Ambas as perguntas acabam sendo a mesma coisa, feitas de maneira diferente para pessoas diferentes. Pontos importantes:

• Como são resolvidas as divergências sobre questões técnicas na equipe
• Como o trabalho é compartilhado entre os desenvolvedores
• Como os bugs são atribuídos às pessoas
• Como você toma a decisão de projetar internamente, terceirizar e fornecer as prateleiras?
• Como você julga o fracasso / sucesso do projeto

Isso em complemento ao teste de Joel. Observe que não há resposta "certa": depende do que você está procurando sozinho, que tipo de empresa você está procurando, que tipo de empresa é (por exemplo, uma startup terá menos chances de pagar pelo melhores ferramentas em comparação com as da Fortune 500). Se a pessoa não puder responder a essa pergunta, isso é quase definitivamente um mau sinal: provavelmente eles nem sequer pensaram sobre esses problemas.

Há uma série de coisas óbvias e com a devida diligência que você pode fazer, como fazer algumas perguntas sobre o processo delas, ou tentar conversar ou até mesmo trabalhar brevemente com outro desenvolvedor. Por melhor que seja, também é facilmente falsificável - mesmo os piores gerentes geralmente sabem o que dizer sobre sua metodologia (saber o que dizer sem entender o "porquê" é o que os torna maus gerentes em primeiro lugar, certo ?) e a maioria dos programadores não vai querer falar mal da empresa para um possível contrato - por que arriscar voltar para alguém por um milhão de entrevistados que passa pelo sistema? (em uma empresa doentia onde as críticas são desaprovadas ... isso pode ser um risco real)

No entanto, você pode ver coisas mais subjetivas - os gerentes parecem cheios de chavões ou honestos? Parece um ambiente saudável?

Qual é a qualidade das perguntas e o conhecimento de seus entrevistadores - este é o processo pelo qual todos os seus funcionários passaram, lembre-se. Eles estão fazendo perguntas estúpidas? Pergunta do tipo RH? As perguntas de codificação são fáceis demais?

Como outros já disseram, as entrevistas são uma via de mão dupla ....

Mas há um fator psicológico sutil aqui, que eu acho que muitas pessoas não fazem bem: ser intimidado a aceitar um emprego ruim. Isso é mais um problema para os jovens, mas todos somos vulneráveis ​​a ele.

Eu acho que muitas pessoas pensam que você não pode realmente mudar o comportamento corporativo de baixa qualidade; por isso, sentimos muitos sentimentos ruins ao decidir aceitar uma oferta de emprego. Parte da psicologia aqui também é a relação de poder entre empregador e empregado - especialmente em uma economia ruim ou competitiva - parece que eles têm que dar muita margem de manobra, mesmo diante de alguns cheiros bastante ruins - como Joel Testes, etc.

Tão eficazmente, o que estou dizendo é: muitos de nós aceitam empregos, SABENDO que serão empregos do DailyWTF. O truque é ser mais exigente, aprofundar os entrevistadores - e simplesmente não aceitar trabalhos ruins, a menos que você esteja absolutamente desesperado. Existe um equilíbrio, é claro, mas vale a pena examinar seus sentimentos ao decidir se uma oferta de emprego na mesa é uma WTF ou não. É fácil convencer-se de que você está apenas sendo "muito exigente e inflexível", quando, na realidade, está ignorando um genuíno mau cheiro de trabalho.