Feeds:
Posts
Comentários

Archive for setembro \14\UTC 2011

Quantas vezes, em uma entrevista de emprego, você realmente fez perguntas para saber em qual tipo de empresa você está entrando para trabalhar? Perguntas que te dêem uma boa noção do nível de flexibilidade e liberdade que você terá, para que, depois de 6 meses ou 1 ano, você não esteja se arrependendo profundamente de ter recusado outra proposta ou mesmo saído do antigo emprego. Infelizmente, é impossível saber realmente se o ambiente de trabalho é bom ou não, porém quanto mais perguntas você fizer, mais informações você terá para analisar se deseja realmente trabalhar na empresa ou não. Afinal, os entrevistadores fazem diversas perguntas para, entre muitas coisas, diminuir o risco de contratar a pessoa errada para o cargo. Então por que você não deveria fazer o mesmo?

Sempre comece com perguntas mais técnicas, até porque essas deverão provavelmente entrar no decorrer da entrevista caso a conversa com o entrevistador esteja fluindo bem. Abaixo algumas perguntas e os motivos pelo qual você deve faze-las:

– Utilizam metodologias ágeis (Scrum, XP, Kanban)?

Motivo: Se não utilizam nenhuma metodologia ágil, pode se preparar para alguns desses problemas: trabalhar com escopo fechado e muita correria no final do projeto; briga do que estava acordado no contrato e o que foi entregue; código com pouca qualidade; muita burocracia; falta de melhoria contínua do ambiente de trabalho/forma de trabalho; entre outros problemas.

– Utilizam projetos open source? Se sim, quais? A empresa contribui com esses projetos?

Motivo: Se não utilizam projetos open source, normalmente, você vai trabalhar com versões de softwares desatualizadas, pois os cabeças das empresas compram softwares “corporativos” que custam muito dinheiro, porém só os atualizam quando estes deixam de ter garantia do fornecedor.

– Quais linguagens a empresa utiliza (além é claro da que você já sabe que vai trabalhar)? Existe flexibilidade de utilizar novas linguagens de acordo com o projeto?

Motivo: Saber se existe a possibilidade de trabalhar com linguagens que se adequam melhor para resolver certo tipo de problema; mesmo que essa linguagem não seja “mainstream”.

– Quais versões dos softwares XXX (servidores de aplicações, bancos de dados, etc) que utilizam?

Motivo: É claro que nem todos os softwares da empresa vão ser a última tecnologia do mercado, pois é muito difícil que isso seja uma vantagem para a empresa; mas você também não vai querer ficar trabalhando com um monte de softwares desatualizados que vão dificultar seu dia-a-dia.

– Quanto à parte de testes (unitários, de integração, de regressão), qual a porcentagem de cobertura aceita por projeto?

Motivo: Aqui é onde você descobre a qualidade que a empresa tem no desenvolvimento dos seus sistemas. Se os sistemas não possuem testes ou a cobertura dos mesmos é muito baixa, se prepare para muita dor de cabeça.

– Como funciona o processo de evolução/melhorias dos sistemas? Existe um planejamento de atualização?

Motivo: É importante saber se a empresa se preocupa com a evolução dos seus sistemas e não somente com o desenvolvimento dos mesmos, porém se a qualidade dos testes for baixa, é quase certo que os sistemas terão muitos “remendos” e muitas “gambiarras”. Mas caso exista uma boa cobertura de testes, não será um grande problema atualizar versões de bibliotecas, frameworks ou mesmo a versão da linguagem usada para desenvolver o sistema.

– Possuem ambiente de integração continua? Qual o nível de automatização/integração? 

Motivo: Importante saber se a empresa está engatinhando, caminhando, ou correndo no quesito desenvolvimento de software. É uma boa notícia se a empresa utiliza um servidor de integração contínua, pois a grande maioria não utiliza. E se utiliza, é interessante saber qual o grau de avanço nessa área (como está a integração com o sistema de controle de versão, com os servidores para deploy, com as ferramentas de tracking, etc).

– Como são tratados/resolvidos os débitos técnicos dos projetos?

Motivo: Se a empresa não se preocupa com os débitos técnicos no decorrer do desenvolvimento, os problemas vão crescendo e acabam virando uma bola de neve. Onde trabalho atualmente, usamos entre 10 e 20% do tempo de cada iteração na melhoria dos sistemas (seja refactoring, atualização de bibliotecas, mudança de arquitetura/tecnologia, etc).

– Qual a atual arquitetura do(s) sistema(s) que vou trabalhar? Por exemplo: clusters, load balancing, webservices, MOMs, etc.

Motivo: Essa pergunta é muito importante para você saber se tem alguma tecnologia que você não gosta e que vai ter que utilizar e também para começar a estudar alguma dessas tecnologias caso ainda não saiba (não é porque você não conhece 100% das tecnologias que a empresa utiliza que eles vão deixar de te contratar).

– Os sistemas legados estão desenvolvidos em quais linguagens/frameworks/plataformas? Vou trabalhar/dar manutenção diretamente neles?

Motivo: Praticamente todas as empresas possuem sistemas legados antigos que são utilizados até hoje. Mas é importante saber quais as proporções da “bomba” e parar para pensar se você está afim de trabalhar com tal tecnologia.

– Existe equipe de QA? Se sim, são gerados estatísticas de problemas, qualidade, quantidade de releases antes do projeto ir para produção, etc? 

Motivo: Muitas empresas possuem equipes de QA. Se a empresa possui equipe de QA, é interessante saber se são pessoas que sentam na frente do computador e ficam “batendo a mão no teclado” na hora de inserir dados em uma tela de cadastro, por exemplo; ou se é uma equipe de QA que vai ajudar os desenvolvedores, extraindo informações importantes sobre a qualidade de cada iteração, como por exemplo: informações de quantidade e tipo de bugs nos sistemas mesmo antes de ir para produção, ajudando assim a equipe a compreender os problemas e melhorar o próprio desenvolvimento. Se não possui equipe de QA, alguém faz esse trabalho?

– Como funciona a parte de homologação e produção? Trabalham com RCs? Quem cuida desses ambientes? Como é o processo para enviar o projeto para homologação e produção?

Motivo: Importante saber o nível de burocracia dentro da empresa para colocar um sistema em produção, pois acredite, em muitas empresas, até mesmo colocar o sistema em homologação é um verdadeiro parto. Pode parecer coisa boba, mas é justamente o excesso de burocracia que acaba cansando no decorrer do seu dia-a-dia dentro da empresa.

– Sistemas em produção, normalmente entram no ar quando (durante a semana, final de semana, de dia, a noite)? Downtime de quanto tempo normalmente?

Motivo: Muito importante saber como serão suas noites e finais de semana trabalhando nessa empresa. Se a empresa trabalha com iterações curtas, mas não entra nada em produção durante o horário de trabalho normal, isso pode ser um problema ou não (depende da sua disponibilidade).

– Existe flexibilidade para instalar utilitários/aplicativos no ambiente local ? Exemplo: posso escolher o S.O., a IDE, etc?

Motivo: É interessante saber se você vai poder trabalhar com o software que você é realmente produtivo ou vai precisar se adaptar ao software que a empresa usa. Isso é algo que normalmente não se tem muita flexibilidade dentro das empresas (a não ser que seja uma startup), mas as que dão total flexibilidade estão realmente um passo à frente.

– Quais softwares são utilizados para transferência/atualização de conhecimento (wiki, intranet, etc)?

Motivo: Interessante saber, pois fica bem mais fácil buscar as primeiras informações, sobre, por exemplo, a arquitetura de um sistema, ou quais os passos para configurar softwares internos, etc. Isso mostra organização.

 

…e algumas perguntas que devem ser feitas com cuidado, pois alguns entrevistadores podem levar para o lado negativo da coisa.

– Quantidade de Horas Extras (HE)? Trabalham com banco de horas?

Motivo: Importante saber, pois se a quantidade de HE é muito grande e rotineira, pode ter certeza que esse emprego vai te consumir bastante e você vai acabar perdendo coisas importantes, como sua vida, familia, amigos, lazer, etc. Quanto ao banco de horas, é bom saber antes para não virar motivo de briga depois.

– Existe horário flexível ? Roupa de trabalho?

Motivo: Interessante saber, pois pode fazer muita diferença no seu dia-a-dia dentro da empresa ou não. Algumas pessoas gostam de chegar e sair mais cedo; outras, não. Algumas pessoas se incomodam de trabalhar de terno e gravata; outras, não. Tudo depende do seu estilo de vida e o que te incomoda.

– Existe limitação ao uso da internet?

Motivo: Pode parecer brincadeira, mas algumas empresas não liberam internet para desenvolvedores, principalmente se forem consultores. Se o entrevistador falar que, no seu caso, não é liberado o uso de internet, agradeça a oportunidade e vá embora. Simples assim.

– Empresa libera e/ou paga conferências ou cursos? Possui biblioteca de livros técnicos?

Motivo: Interessante saber se a empresa investe tempo/dinheiro nos funcionários, ou seja, em você! Essa é uma pergunta para se fazer na hora em que os benefícios estiverem sendo discutidos.

 

Pense e coloque como questão algo que te incomoda no emprego atual ou já te incomodou muito em algum emprego anterior. Não fique esperando que você tenha “sorte” de entrar em uma empresa e não passar por alguma situação indesejada novamente. Na hora da entrevista, lembre-se: questione! 😉

Read Full Post »

Faz um tempo que venho acompanhando o desenvolvimento da nova spec JSR 343 – Java Message Server 2.0. É a primeira vez que acompanho o desenvolvimento de uma especificação e apesar de ser um processo “burocratico”, estou achando bem interessante e aprendendo bastante também. Primeiro, faz você perceber como é difícil desenvolver uma nova especificação e a implementação de referência sempre mantendo a compatibilidade com o código da versão anterior (caso a JSR seja uma atualização). E outro ponto interessante é a integração entre as JSRs, pois como dependendo das decisões tomadas, essas afetam outras JSRs, existe então todo um processo de “negociação” entre os líderes das JSRs; que é uma coisa que acontece também quando você trabalha em empresas grandes com sistemas que trocam informações/interagem com vários outros.

Porém a parte mais bacana é que você entende realmente porque algumas decisões sobre a JSR  foram tomadas. Além é claro de ficar sabendo das últimas novidades sobre essa que você está acompanhando.

Realmente aconselho o pessoal que trabalha com Java a acompanhar o desenvolvimento de uma JSR, cujo o assunto seja do seu interesse.

JCP – Java Community Process

Read Full Post »