É aconselhável perguntar sobre as decisões de design tomadas em um produto durante uma entrevista? [fechadas]

Ultimamente, tenho pensado em perguntas para entrevistas e refletido sobre experiências ruins de entrevistas que tive no passado. Uma observação particular é onde perguntei ao entrevistador por que a equipe optou por usar o EJB 3 durante a primavera em seu produto. O entrevistador quase me irritou e gritou: "Como o Spring não é tudo e acaba com todo o desenvolvimento de software Java, você quer esse trabalho ou não?". Em resposta a isso, eu disse a ele que provavelmente não era o trabalho para mim e saí prontamente da entrevista.

Fui informado no início da entrevista que a empresa tinha uma alta rotatividade de funcionários, o produto em que estavam trabalhando foi criado inicialmente no Modula-3 e depois transportado para Perl e, finalmente, para Java. Recebi um livreto de 10 páginas de perguntas técnicas sobre Java, EJB, SQL e JDBC e me fizeram perguntas sobre as pilhas de tecnologia com as quais trabalhei. Quando solicitado a fazer perguntas, achei razoável perguntar-lhes sobre sua pilha de tecnologias e obter respostas razoáveis ​​de volta, para não deixar o entrevistador em chamas.

Pergunta: É uma boa ideia investigar as escolhas arquitetônicas tomadas em uma entrevista? Se não, por que?

Do meu ponto de vista, uma entrevista é um processo de mão dupla. Se os entrevistadores estão testando minhas habilidades técnicas, tenho todo o direito de fazer as mesmas perguntas para:

1) Descubra quais são suas mentalidades e atitudes em relação ao desenvolvimento de software. 2) Determine se a abordagem deles está alinhada com a maneira como eu abordaria problemas desse tipo.

É possível que o entrevistador que ficou com raiva tenha poucas habilidades de entrevista e tenha esquecido que uma entrevista é uma troca de mão dupla. Se me perguntassem isso, eu teria dado uma resposta razoável, mas certamente não teria tentado colocar um entrevistado em um estado de capitulação humilde, em que a cabeça apenas balança para cima e para baixo sem conversar.

Pessoalmente, acho que entrevistar pessoas é quase tão cansativo e estressante quanto ser entrevistado. Mas é porque concordo com você que o processo de entrevista é uma troca de mão dupla.

Não me importo com o quão bom você é, não quero contratá-lo se você não for feliz trabalhando lá. É um jogo caro de jogar. Quero responder a quaisquer preocupações que você possa ter e mostrar a equipe e o produto como são, para que você possa tomar uma decisão informada.

Quando estou procurando emprego, quero trabalhar com alguém que compartilhe essa atitude. E, mesmo que eu suspeite que saiba as respostas para as perguntas, pedirei a elas apenas para ver a reação. A agressão nunca é um sinal de alguém confortável com uma situação.

Eu não minto em uma entrevista, em ambos os lados da mesa, porque eles pensam que estão contratando alguém diferente / indo trabalhar em outro lugar. E espero o mesmo em troca, da pessoa do outro lado da entrevista.

Infelizmente, isso significa que ocasionalmente encontro entrevistas como a que você descreveu. São experiências horríveis? Sim. Saio de lá sabendo exatamente onde a entrevista deu errado? Sim.

Mas estou muito certo de que cada experiência horrível teria sido consideravelmente pior se eu consegui o emprego ou contratou a pessoa errada? Claro que sim.

Sim, não há problema em perguntar se você é realmente curioso e se a resposta importa. Acho que perguntar mostra que você entende que há mais de uma maneira de fazer as coisas e mostra que você está interessado em saber como o software foi escrito.

Dito isto, você deve ter muito cuidado com a forma como formula a pergunta e duplamente cuidadoso com o modo como continua a conversa. É fácil parecer desafiador nas suas decisões. A última coisa que você quer é que o entrevistador acredite que se acha mais inteligente que ele. Se você é genuinamente curioso, pergunte. Se você acha que eles fizeram uma má escolha, fique de boca fechada.

Se eu estivesse na situação descrita na pergunta, em vez de sair, poderia ter dito algo como "oh sim, concordo que a primavera definitivamente não é a solução certa para tudo. Obrigado por me informar um pouco sobre sua arquitetura! Estou sempre procurando informações sobre como escolher as ferramentas certas ". (embora, sua pergunta é estranho - você perguntar por que eles escolheram primavera, e eles escolheram porque era não o ser tudo toda a extremidade?)

Como alguém que frequentemente entrevista pessoas, eu gostaria de receber pessoalmente uma discussão sobre por que escolhas específicas de tecnologia ou design foram feitas, o que faríamos de diferente agora se tivéssemos o luxo de recursos ou estivéssemos iniciando um novo projeto. Eu geralmente via isso como um sinal de alguém que se preocupa com seu ofício e, a menos que seus dogmas e os nossos não sejam compatíveis, eu provavelmente classificaria esse candidato mais do que alguém que apenas responde perguntas técnicas com competência.

Atualmente, estou trabalhando em um projeto para um cliente que tem um legado de algumas decisões arquitetônicas bem-intencionadas, mas mal implementadas, e os candidatos que expressam curiosidade sobre o mundo como ele é e o caminho a seguir, geralmente são os tipos de pessoas com quem gostaríamos de trabalhar. Queremos pessoas capazes de realizar a devida diligência e validação nas decisões de projeto e implementação de nossa equipe. Geralmente valorizamos pessoas que trazem algo para a mesa que não possuímos ou que não temos o suficiente.

Quando sou candidato a uma entrevista, tomo qualquer sinal de hostilidade ou defensividade quando esses tipos de discussões acontecem como um mau sinal, pois uma organização que não é capaz de auto-exame geralmente também está em um pântano tecnológico e de processo que eles são incapazes e provavelmente não estão dispostos a sair do trabalho. Se não vejo motivação para a melhoria contínua da equipe existente, há uma boa chance de não ser feliz lá.

que dormiu com um vendedor da Oracle uma vez e decidiu que todo o desenvolvimento futuro será feito usando os serviços da Web Java 1.4, Oracle ERP e um front-end do Borland C ++ usando componentes de GUI de terceiros descontinuados e preferimos gastar US $ 60.000 por mês obstruindo buracos para manter os clientes de pular de navio, revisitar as decisões e fazer melhorias permanentes que podem gerar novas receitas se tivermos sorte. Não agite o barco, o que há de errado com você? "

Presumindo que você esteja em uma área com outros empregos em tecnologia ou que esteja disposto a mudar, você provavelmente tem o luxo de escolher. Nenhum show é perfeito, mas você quer trabalhar com pessoas que querem trabalhar com você. (Eu me preocupo mais com isso do que com as escolhas tecnológicas específicas na maioria das vezes.) Se algo cheira mal, provavelmente é.

Então sim, pergunte. Quanto mais curiosidade sobre nossos negócios, nosso processo e nosso design, mais provavelmente levarei um candidato a sério. Mas como não trabalho em uma loja Blub, não posso dizer se isso ajudará você a conseguir um emprego no Blub. Só posso dizer que funcionaria para você se você quiser trabalhar com outras pessoas que se preocupam com o ofício.

Pergunta: É uma boa ideia investigar as escolhas arquitetônicas tomadas em uma entrevista? Se não, por que?

É absolutamente bom, eu consideraria positivo.

Se o seu entrevistador não consegue lidar com isso, isso diz muito sobre eles - não você.

Eu ficaria preocupado se um júnior NÃO estivesse interessado em decisões de design, isso mostraria uma falta de curiosidade / interesse na área de assunto e não exibisse nenhum desejo de melhorar a si mesmos.

Eu sou da mentalidade de que é essencial . Trabalhei em muitos empregos com decisões absurdas de design, porque ninguém sabia nada melhor, não queria aprender, ou havia um mandato da gerência para usar o que o CEO leu em uma revista / viu on-line / tinha alguém diga a ele que era a "próxima grande novidade" sem considerar alternativas. Esses empregos eram todos lugares miseráveis ​​para se trabalhar.

Você não deve necessariamente criticar uma decisão de design, a menos que seja algo que cuspa em face do senso comum ou apenas pareça uma conversa maluca, mas é comum questionar coisas que parecem "erradas" para descobrir se há um motivo legado ou algo que veio que facilitou a necessidade de usar uma abordagem não-ortodoxa.

Fazer perguntas como essa também tem o efeito de avaliar o interesse da empresa em melhoria e competência. Como alguém acima disse, uma coisa é se você receber uma resposta como (eu não sei Java, mas uso o .NET, então usaremos exemplos do .NET) Quando escrevemos o aplicativo, não havia ORMs maduros, por isso usamos procedimentos armazenados com uma camada de gateway de dados. Gostaríamos de mudar para o Entity Framework no futuro e outra coisa totalmente para obter uma resposta como Apenas usamos os procedimentos armazenados. O Entity Framework parece assustador e pode exigir trabalho para refatorar, e não podemos refatorar nada, porque o CEO tem uma lista completa de novos recursos nos quais ele deseja que trabalhemos, e se passarmos o tempo olhando para o Entity Framework, ele nos demitirá. por perder tempo. Um indica entendimento e desejo de melhorar, o outro indica um ambiente medíocre na melhor das hipóteses, onde todos fazem o mínimo necessário para se esquivar.

Uma empresa que se ofende com você questionando suas decisões ou querendo discutir por que eles escolheram usar o Produto A em vez do Produto B está jogando com suas mãos e mostrando que eles não querem um pensador livre, mas um drone que não questionará, e é provável que não seja o tipo de empresa para a qual qualquer desenvolvedor competente deseja trabalhar.

resposta: É uma boa idéia perguntar sobre a tomada de decisões arquitetônicas. Mas você precisa ter cuidado ao fazer essas perguntas.

Simplificando: você deve perguntar " Como você escolheu a tecnologia X em vez da tecnologia Y? ".

Você deseja expressá-lo de forma a comunicar que geralmente está interessado no processo de tomada de decisão dentro da equipe. Ninguém vai querer rever todas as decisões herdadas que a empresa já tomou com um candidato.

Quando você pergunta " Por que você escolheu a tecnologia X em vez da tecnologia Y? ", Pode parecer que você discorda da decisão deles (o que é aceitável ... mas pode ser considerado hostil) ou que deseja se gabar de quanto conheça as tecnologias em questão (o que seria irritante para qualquer um), apesar de suas boas intenções.

Gosto de pedir a um entrevistador que me conte sobre uma decisão fracassada de design que ele tomou e o que foi feito a seguir. Isso fornece algumas boas informações:

1. Se o chefe não pode admitir nenhum erro de forma ou falha temporária, é provável que você não queira trabalhar para esse chefe.
2. Você pode dizer como a empresa lida com uma situação estressante.

Pode não ser popular, mas eu sempre tenho um grande respeito pelos gerentes que reconhecem que um projeto falhará e o matará para parar de desperdiçar dinheiro, ou que algo está indo na direção errada e precisa ser morto ou reiniciado .

Por fim, se você está falando sobre satisfação no trabalho, a tecnologia (idioma / plataforma / compilador / o que for) não importa tanto quanto as personalidades envolvidas e o ambiente de trabalho.

Alguns anos atrás, eu estava em uma entrevista e me fizeram várias perguntas técnicas sobre uma linguagem de programação ... sobre a qual eu não havia me saído bem (60/40 correto / incorreto). A discussão mudou para o projeto que eles tinham em mãos e eu comecei a fazer perguntas sobre o design e, em seguida, apontei alguns problemas e limitações que eles apresentariam.

Me ofereceram o emprego no dia seguinte. Infelizmente, não consegui aceitar por motivos pessoais.

Fazer perguntas sobre design não deve ser um problema se forem perguntas inteligentes, especialmente se você puder relacioná-las aos seus negócios.

Não fiz muitas entrevistas, mas, a partir da sua experiência, concluo:

a) Tudo bem se você quiser tomar uma decisão informada sobre se deseja o emprego;

b) Não está bom se você já decidiu que quer o emprego.

As pessoas podem facilmente se ofender com perguntas benignas sobre suas escolhas. Essa é uma característica muito ruim, mas comum.

Aqui estão alguns conselhos

1. Perguntar por que eles escolheram alguma solução existente pode ser uma pergunta ruim, porque provavelmente a equipe de desenvolvimento não teve chance de mudar ou escolher.
2. Além disso, a equipe provavelmente já sabe por que a tecnologia não foi a melhor escolha
3. Mas, infelizmente, a última coisa que qualquer equipe de desenvolvimento precisa é de pessoas que tentam mudar a arquitetura ou as opções de questionamento feitas há 10 anos - dá a impressão de que sua tecnologia já é coisa antiga e herdada e que essas mensagens na equipe podem deixar os desenvolvedores infelizes sobre a situação atual
4. Assim, em uma entrevista, a última coisa que você deve fazer é dar a impressão de que vai reclamar o tempo todo sobre as escolhas que a equipe não tem controle sobre