Autor: Luiz Ricardo (Página 4 de 16)

Problemas com “merge” no JPA?

java_ee

Muitos desenvolvedores enfrentam grandes dificuldades em trabalhar com JPA (Java Persistence API). Vejo que a maioria dessas dificuldades tem raiz na falta de compreensão de certos detalhes do funcionamento do JPA.

Analisarei neste artigo um caso que gera muita confusão, que é o uso do método merge().

Leia mais

Boas empresas, boas condições de trabalho

Stressed+out

Boas empresas dão boas condições de trabalho a seus funcionários. Ótimas empresas dão ótimas condições de trabalho.

Isso não tem nada a ver com mérito dos empregados ou mesmo com alguma causa por melhores condições de trabalho. Estamos falando de produtividade e qualidade.

Neste artigo abordarei algo que afeta diretamente todos os profissionais de TI, principalmente desenvolvedores, ainda que não se restringe à esta categoria: hardware.

Leia mais

Curso de Bootstrap, jQuery e Web Standards na Fatec Sorocaba

Nos últimos dois sábados (11 e 18 de Abril de 2015) ministrei o curso Bootstrap, jQuery e Web Standards, uma breve introdução às tecnologias e boas práticas envolvidas no desenvolvimento do front end de páginas web, na Faculdade de Tecnologia de Sorocaba.

curso-bootstrap

Para este curso não preparei uma apostila ou apresentação teórica, mas uma série de exercícios práticos onde cada participante pôde construir sua própria página e seus próprios scripts, que vão desde eventos simples até manipulação do HTML e animações.

Ainda estou aprendendo a ministrar aulas e cursos. Há quem diga que para ensinar basta ter disposição. Concordo, mas estou aprendendo que existe uma grande diferença entre simplesmente transmitir conhecimento e ser um mestre, no sentido de realmente transmitir os princípios do ofício. Como sempre, apliquei uma pesquisa rápida e anônima para obter feedback. Consegui melhorar um pouco em relação a pesquisas anteriores. 😀

O guia de atividades junto com a resolução de todos os exercícios está disponível no meu Google Drive.

Fique à vontade para usar o material como desejar sob a mesma licença Creative Commons deste blog e de todos os meus materiais. 🙂

Linguagens de Programação de alto e baixo nível, quais as diferenças?

Há alguns dias surgiu uma pergunta muito interessante no Stack Overflow em Português sobre o que faz uma linguagem ser considerada de alto ou baixo nível.

Abaixo estão algumas de minhas reflexões sobre o tema.

Uma imagem vale mais do que mil palavras

baixo-alto-nível

Abstração computacional

Pensando numa abordagem para diferenciar linguagens de alto e baixo nível do ponto de vista de quem está programando, o nível da linguagem é proporcional ao quanto você gasta pensando em resolver o seu problema (alto nível) ou em resolver problemas relacionados aos cálculos computacionais (baixo nível).

Por exemplo, considere os “comandos” a seguir:

  1. Mova o texto “ABC” para a posição de memória 123, copie todos os caracteres para o fluxo aberto que aponta para a posição 456 do disco.
  2. Gravar o texto “ABC” no arquivo “doc.txt”
  3. Atualize o nome do cliente com o valor “João”

O item #1 é certamente o que possui mais baixo nível. Em relação a ele, o item #2 é de mais alto nível.

Porém, temos o item #3, que é de mais alto nível que todos. Em relação a ele, o item #2 é de mais baixo nível.

Quantidade de camadas de abstração

Desde que os computadores surgiram há um esforço para tornar a sua programação mais fácil. Isso foi feito criando-se novas linguagens e compiladores mais avançados, assim como através de macros, métodos ou objetos que abstraem e automatizam certas tarefas.

Porém, cada vez que adicionamos uma dessas “facilidades”, aumentamos a quantidade de camadas de abstração ou indireção em relação à computação binária.

Por exemplo:

  1. Assembly é uma linguagem que se mapeia praticamente direto para código de máquina, mas ainda assim o programa é escrito em texto antes de ser convertido em binário. Em geral, cada comando assembly consiste em uma instrução ao processador.
  2. C é uma linguagem de mais alto nível, onde cada comando é traduzido pelo compilador geralmente em várias instruções Assembly (ainda que em memória) antes de realmente gerar código binário.
  3. Java e .NET são linguagens ainda de mais alto nível porque cada comando gera uma ou mais instruções de máquinas virtuais, que não é o mesmo que linguagem de máquina. Cada instrução dessas máquinas virtuais precisa ser traduzida, em tempo de execução, para um conjunto de instruções de máquina correspondente à arquitetura da CPU onde o programa está rodando.
  4. No PHP, enquanto linguagem interpretada, cada comando é processado por código previamente compilado em C, geralmente levando à execução de vários trechos de código equivalentes a várias funções C que são mapeadas para inúmeras instruções de máquina.

Vale notar que, em geral, a quantidade de níveis de abstração é proporcional ao quanto o programador fica “longe” do hardware, mas nem sempre isso é diretamente proporcional.

Suba o nível

Independente da linguagem, programadores devem programar em alto nível sempre que possível.

Mesmo que sua plataforma de desenvolvimento permita conversar diretamente com o hardware, a fim de manter a sanidade, um bom programador irá abstrair toda essa complexidade em rotinas de mais alto nível conforme as capacidades da linguagem (funções, método, objetos, módulos, etc.).

Imagine o seguinte código:

notaFiscal = ler_arquivo_nota_fiscal(caminho);
validar_nota_fiscal(notaFiscal);
salvar_nova_fiscal(notaFiscal);

Exceto pelo estilo de codificação, seja Java ou JavaScript, C ou C#, ShellScript ou PHP, qualquer um pode entender o que o código acima faz e implementar os detalhes nas respectivas rotinas.

No fim das contas, não é porque alguém programa em C que necessariamente precisa estar sempre codificando em baixo nível.

Considerações

Não é possível afirmar absolutamente que uma data linguagem é de alto ou baixo nível.

O que poderíamos dizer é que todas as linguagens de programação são de mais alto nível em relação ao código binário (desde que seja humanamente possível ler o código, obviamente).

Além disso, poderíamos ainda afirmar que uma linguagem X é de mais alto ou mais baixo nível em relação à alguma outra linguagem Y considerando o aspecto Z.

Por fim, dentro de uma mesma linguagem, é possível programar em diferentes níveis de abstração. Bons programadores irão subir o nível sempre que possível tanto para aumentar a produtividade quanto para uma melhor qualidade do código.

Se você não existisse, que falta faria?

se-voce-nao-existisse

Você já teve a sensação de que seu trabalho é inútil? Você tem noção do impacto de quando você faz um bom trabalho? E se fizer um serviço desleixado, faz alguma diferença?

No vídeo abaixo o educador, escritor e filósofo Mário Sérgio Cortella nos apresenta uma reflexão bastante interessante sobre o nosso papel no trabalho e na sociedade, da importância do mesmo, ética, dentre outras coisas.

É uma palestra um tanto longa e pode ser cansativa em alguns pontos para os mais apressadinhos, porém garanto que vale a pena.

Um guia prático para passar em entrevistas para desenvolvedor de software

Caso esteja lendo este artigo há poucas horas de fazer uma entrevista, sinto informar que não será de total utilidade. O objetivo aqui é lhe dar um entendimento de como o processo funciona em geral e, assim, dar-lhe a chance de se preparar adequadamente. Desenvolvedores com alguma experiência levarão pouco tempo para absorver as dicas, já os menos experientes precisarão de muito mais.

Sugiro fortemente a leitura do artigo Um guia para você conseguir um bom emprego como desenvolvedor de software como pré-requisito para este, caso não o tenha feito ainda. Evitarei repetir o que está ali, mas muitos pontos são correlatos.

Saiba tudo sobre a vaga

É um erro comparecer a uma entrevista sem informações sobre a vaga.

Claro, existem empresas que contratam desenvolvedores “genéricos” para vagas “genéricas”, ou que somente dão informações durante a própria entrevista. Eu fugiria disso, mas nem sempre estamos em boa posição. Neste caso, meu amigo, você precisa contar um pouco com a sorte. Sem informações exatas, resta preparar-se para os tipos de entrevistas e perguntas mais comuns. Trataremos disto mais adiante.

Idealmente, você deve perguntar ao seu contato com a empresa o máximo de detalhes possível. Por exemplo:

  1. Em qual projeto ou produto você vai trabalhar
  2. A plataforma de desenvolvimento (Java, .NET, Rails, PHP)
  3. Tecnologias utilizadas (Maven, JPA, JSF, Entity Framework, Linq, Heroku, Rails, jQuery, etc.)
  4. O processo de desenvolvimento (waterfall, agile)
  5. Horário e local de trabalho, viagens e outras políticas da empresa

Antes da entrevista você deve revisar alguns pontos centrais relacionados às tecnologias, principalmente as exigidas pela vaga e que você não lida há algum tempo, de forma a responder prontamente a perguntas sobre o tema. Dificilmente você será questionado diretamente ou profundamente sobre tecnologias que a empresa não usa.

Certamente seu desempenho será proporcional à sua experiência e ao quando você se dedicou até o momento, mas revisar sempre ajuda. Digo por experiência própria, pois a pior coisa é ser pego de surpresa e passar a impressão de que você não domina tanto um assunto que, na verdade, você poderia responder como um expert.

Atente para o perfil da vaga

Evite candidatar-se ou mesmo fazer entrevista para algo que esteja fora do seu perfil.

Caso não saiba programar, não tente uma vaga que exija experiência em programação. Eu garanto, você não vai conseguir dar um jeitinho. Também não tente um cargo de liderança se você não tiver experiência o suficiente. Não espere tornar-se gerente de projetos com poucos anos no mercado.

Não há uma regra absoluta quanto a isso, afinal existem pessoas que são realmente subutilizadas, mas se você tentar concorrer a uma vaga superior à sua função atual, pelo menos evite que o salto seja muito grande.

Após pesquisar um pouco sobre a vaga, determine se você tem experiência ou pelo menos vivência e conhecimentos suficientes para exercer a função. Assim você evita perder seu tempo e o tempo do entrevistador.

Talvez você ache que, uma vez participando da entrevista, eles podem lhe encaixar em um cargo menor. Em raras ocasiões isso pode até ocorrer, mas em geral, a impressão negativa que um candidato inadequado causa é pior.

Saiba tudo sobre o processo seletivo

Procure saber como é um fluxo do processo seletivo para a vaga e a duração de cada fase. Não tenha medo ou receio de questionar seu contato e até algum colega que já trabalhe na empresa sobre o processo seletivo.

Não somente é importante estar tecnicamente preparado, mas estar mentalmente preparado para os diferentes tipos de entrevista é essencial.

A maioria das empresas começa com uma entrevista com alguém do departamento Recursos Humanos, seguida de uma ou mais entrevistas técnicas com desenvolvedores e gerentes.

Quanto ao conteúdo, algumas incluem desafios de programação, testes de lógica, teste ou conversação em inglês e, pasmem, redação. Acredite, é aleatório e vai do gosto do recrutador.

Mais uma vez, evite surpresas. Algumas empresas dividem o processo em dias diferentes, outras vão fazer todo o processo todo de uma só vez. Às vezes isso depende da disponibilidade do pessoal. Esteja preparado.

Procure saber quantas e quais tipos de entrevistas você terá de fazer, a duração delas, quanto tempo o processo leva como um todo e quanto tempo você terá para se organizar caso passe na entrevista.

Algumas empresas demandam início imediato após sua aprovação, mesmo sendo contra a lei. Cuidado para não acabar numa situação ruim ou até levar prejuízo. Por exemplo, entenda que se você não cumprir o aviso prévio no trabalho atual, não apenas deixará de receber os dias, mas pagará multa por isso.

Saber sobre tempos e datas também é útil principalmente quando a mudança de emprego envolve também mudança para outra cidade, ou mesmo dentro da mesma cidade.

Não deixe para começar a pensar em tudo isso somente depois que receber uma oferta da empresa, pois em alguns casos a mudança pode se tornar inviável e será tarde demais para remediar. Em outras palavras: você pode perder a oportunidade por falta de atenção.

Saiba tudo sobre a empresa

Faça o que puder para saber como é a cultura da empresa e dos desenvolvedores que trabalham nela.

Diferentes empresas almejam contratar pessoas com diferentes qualidades. Algumas são bem exigentes na parte técnica, outras preferem focar na responsabilidade com o cliente e com o projeto, outras focam em ambos, outras em contratar a mão-de-obra mais barata possível. Isso pode variar de acordo com a vaga, então é uma pesquisa conjunta.

Porém, toda empresa tem um conjunto de valores dominantes, explícitos ou implícitos, com os quais você deve estar alinhado se quiser uma vaga lá.

Por exemplo, algumas empresas possuem sua gerência majoritariamente composta por líderes técnicos. Em geral, eles exigirão pessoas atualizadas com as últimas tendências e boas práticas tanto tecnologicamente como em processos ágeis. A vantagem é que os desenvolvedores são mais valorizados.

Em contrapartida, consultorias e empresas que atuam no segmento financeiro irão exigir um comportamento mais estrito, roupa social e conhecimentos específicos, mas não profundos, das tecnologias que eles utilizam.

Algumas empresas dão um valor muito grande a alguma habilidade específica, nem sempre relacionada à programação. Um exemplo é o Inglês. A GFT (onde trabalho na presente data) leva muito em consideração a proficiência em Inglês. Se for necessário escolher, empresas com projetos internacionais sempre optarão por um analista com Inglês fluente em comparação com outro candidato com competência técnica relativamente superior, mas que não tem Inglês.

Outro exemplo são empresas no segmento financeiro ou contábil. Elas preferem quem tem formação ou experiência em Estatística, Contabilidade ou no segmento bancário.

Mesmo que você não possua a formação ou experiência na área, procure pelo menos se informar um mínimo sobre o que a empresa faz e quais são seus clientes. Se não para a entrevista, isso lhe ajudará a entender como a empresa funciona e o que você deve esperar do trabalho.

Conhecer uma empresa é complicado. Comece pelo website, verifique se há relatos sobre ela na Internet. Pergunta a pessoas que trabalham e já trabalharam lá.

Independente do resultado da pesquisa, demonstrar aos entrevistadores que você fez sua “lição de casa” e sabe algo da empresa passa uma impressão bastante positiva. Um candidato que se prepara e sabe onde está indo será muito mais propenso a se adaptar bem do que alguém que age passivamente em relação ao processo.

Preparando o currículo

A melhor forma de fazer um currículo é um tema controverso. Tentarei lhe dar alguns princípios do ponto de vista de quem está lendo.

Não minta!!!

Antes de mais nada, não minta no seu currículo!

Algumas pessoas fazem isso para chamar a atenção e chegar até a entrevista, mas as consequências posteriores podem ser piores. Existem outras formas de chamar a atenção.

Em raras ocasiões você pode sair ileso, mas a pior coisa que pode acontecer é o entrevistador perceber que você mentiu. Se isso for colocado na sua avaliação, é reprovação na certa e possivelmente não haverá segunda chance.

Conversei com vários colegas sobre este artigo e 100% deles afirmaram ou pelo menos concordaram que mentir é a pior coisa que um candidato pode fazer.

Filtre o conteúdo adequado

Destaque suas principais habilidades. Eu certamente gostaria de saber o que você faz de melhor. Isso é verdade principalmente em empresas que possuem várias vagas e o entrevistador precisa identificar em qual delas você se encaixa melhor.

Liste as tecnologias que você domina. Muitas pessoas colocam uma lista infindável das tecnologias ou conhecimentos. Já cometi o erro de listar todas as tecnologias com que já trabalhei. Isso acaba sendo sujeita visual. Além disso o entrevistador vai acabar perguntando sobre algo que você não conhece bem. Destaque o que você conhece mais profundamente, isso lhe dará a vantagem de se mostrar mais seguro e experiente do que quando questionado sobre coisas que você não sabe tão bem.

Descreva suas experiências de trabalho, começando da mais recente, se possível com uma breve descrição dos projetos em que você trabalho, quais tecnologias eram usadas em cada projeto e o seu papel na equipe. Dessa forma é possível ver a sua evolução como desenvolvedor e saber com o que você tem experiência.

Vale também listar projetos pessoais, desde que tenha alguma relevância. Por exemplo, se você desenvolveu sozinho um sistema de controle de caixa para um mercadinho, isso pode ser um grande feito. Criar uma conta no blogger e configurar um template para um amigo, nem tanto.

Formação acadêmica é importante, principalmente faculdade, pós-graduação, mestrado. Curso técnico em desenvolvimento ajudaria a saber que você tem interesse em software desde cedo. Cursos como da Caelum, Global Code e outros, assim como certificações, ajudam a ver que você está estudando e evoluindo. Só não exagere. Mesmo que você goste de fazer todos os cursos online que vê pela frente, ninguém vai analisar uma página inteira de cursos e vai dar a impressão de que você faz só por fazer. Neste caso, filtro algo em torno dos 5 mais relevantes para aquela vaga.

Valem também links para projetos publicados na web, blog (se for da área), repositórios como o GitHub e até seu perfil no LinkedIn (se estiver atualizado).

Coisas que eu, como entrevistador, não gostaria de ver são:

  • Frases comuns artificiais
  • Muitos erros de português
  • Nomes de tecnologias escritas de forma errada, pois demonstra pouca familiaridade
  • Sua experiência juvenil trabalhando no McDonalds
  • Cor, Raça, Credo, Foto
  • Curso de Word, Excel e PowerPoint
  • Tipo sanguíneo

Você deve ter pego a ideia. 😉

Tamanho

O ideal seria que seu currículo não tivesse mais do que duas páginas.

É claro que algumas pessoas tem mais experiência do que as outras. Se for maior do que isso, que seja conteúdo relevante e não enrolação.

Em todo caso, reúna todas as informações importantes na primeira página. Deixa aquela sua lista imensa de cursos online para a última página, por exemplo.

Para o bem ou para o mal, tenho o hábito olho o currículo todo do entrevistado em detalhes antes e depois da entrevista, mas nem todos os entrevistadores tem tempo ou disposição para isso, dependendo da extensão do documento.

O que vestir

Pergunte. Algumas empresas não tem requisitos, outras possuem um dress code rígido, principalmente no segmento financeiro.

Nunca se vista desleixadamente, pois é horrível chegar num lugar bonito com gente arrumada e chamar a atenção por estar mal vestido. Mesmo em ambientes mais descontraídos, causar uma boa impressão inicial pode ajudar.

Só não exagere. Terno e gravata num dia de verão com 40 graus vai lhe fazer suar todo e pode ser pior do que uma roupa mais fresca.

Tome conta da sua identidade online

Cuidado com sua imagem na web. Particularmente, eu procuro evitar qualquer tipo de preconceito e creio que a maioria dos entrevistadores faz o mesmo. Mas se por acaso alguém descobrir que você publica todos os dias imagens passando a ideia de “odeio meu trabalho”, provavelmente isso vai manchar sua reputação.

Procure construir uma reputação online, ainda que minimalista, participando de fóruns, ajudando outras pessoas, compartilhando código, publicando artigos, etc.

Pode ser que não vejam isso, mas os melhores profissionais vão olhar e pode fazer uma diferença enorme.

Entrevista com o RH

Um ou mais funcionários do Recursos Humanos irão lhe entrevistar. É de praxe a não ser em empresas muito pequenas que não tem um setor de RH. Neste caso, pode ser até que o dono ou um dos sócios da empresa faça a entrevista pessoalmente.

Em geral, esta será a parte mais fácil, por assim dizer. Sua capacidade técnica não será testada. Você apenas precisa demonstrar, bem por cima, que tem o perfil de desenvolvedor e que é uma pessoa normal. Pessoas claramente sem nenhuma afinidade com computadores, que mentiram no currículo e alguns tipos de psicopatas sociais geralmente não passam desta fase. 😉

Apenas seja sincero e calmo. Você simplesmente está conhecendo um (possível) colega de trabalho. Psicólogos e recrutadores são pessoas normais e quase sempre tem boa vontade, acredite! Eles também são funcionários e conhecem os pontos positivos e negativos da empresa.

No caso de ser um sócio ou dono da empresa, aproveite para conhecê-lo e saber um pouco do que o espera no dia-a-dia.

Não tenha medo de fazer perguntas. Pessoas inseguras (como eu mesmo em várias ocasiões) ficam com receio de perguntar detalhes sobre a empresa, a vaga, benefícios, condições de trabalho, como se fosse algo secreto e só o entrevistador tivesse direito a saber coisas sobre você.

Profissionais experientes e seguros geralmente sabem o que querem. Eles acabam perguntando mais porque querem comparar o possível novo emprego com o atual e os anteriores. Mesmo que você só tenha trabalhado em uma empresa, há algumas coisas que você pode usar com critério. Vou esboçar algumas ideias:

  1. Benefícios oferecidos como plano de saúde e dental. É importante saber se há custo adicional, coparticipação, etc. Isso faz muita diferença na hora de comparar se o salário está bom ou não.
  2. Estacionamento ou vale transporte. Comece a pensar como vai se locomover até a empresa, estacionar e o custo envolvido em tudo isso.
  3. Alimentação. A empresa oferece vale refeição e/ou alimentação? Tem cozinha?
  4. Ambiente de trabalho. Você vai ter uma mesa própria? Vai trabalhar na própria empresa, em algum cliente? É permitido o uso de fones de ouvido?
  5. Equipamento. Vai usar notebook ou PC? Existe a possibilidade de ter um monitor extra?
  6. Internet. Quais são as políticas e restrições de uso? Há empresas que bloqueiam até o Google.
  7. Viagens. Há necessidade de viajar ou se deslocar dentro da cidade para clientes? Como isso funciona?
  8. Equipe. Você vai ter uma equipe fixa ou vai trabalhar em vários projetos ao mesmo tempo? Quem será o seu superior direto a quem deve reportar? Qual é a hierarquia da empresa?
  9. Horário de trabalho. A empresa permite flexibilidade de horário? Como funcionam o ponto e o banco de horas?
  10. Estudo. A empresa possui convênios com universidades e escolas caso você queira continuar estudando? Ela incentiva você a obter certificações?
  11. Comunidade local. A empresa é engajada com a comunidade local? Ela incentiva ou promove palestras e cursos nas faculdades e escolas locais?
  12. Plano de carreira. Qual é a perspectiva de crescimento? Há avaliação de desempenho? Com que frequência?

Dinâmica de grupo

Devido ao elevado número de candidatos, é prática comum nas empresas fazer a dinâmica de grupo. Isso significa avaliar vários candidatos de uma só vez e fazer uma pré-seleção daqueles que entrarão efetivamente para o processo seletivo.

Não vou entrar em detalhes sobre as origens e sobre a teoria das dinâmicas de grupo, até porque a maioria das pessoas que as conduzem não tem a menor ideia.

O importante aqui é se mostrar uma pessoa comunicativa e esclarecida.

Certa ocasião questionei um colega sobre qual era o critério dele para selecionar as pessoas durante uma dinâmica de grupo. Ele disse que não havia um critério objetivo e que o resultado dependia muito do andamento. Basicamente, ele colocava um tema controverso para ser discutido pelos participantes e analisava a reação. Candidatos sem opinião ou que tentavam se impor sobre os demais eram os primeiros desqualificados.

Num caso em específico, houve um rapaz que não deixa os outros falaram e colocava-se como a voz da razão. Ele foi o primeiro a ser desclassificado. Portanto, este tipo de entrevista filtra bem pessoas com distorções sociais que podem ser um empecilho ao ambiente de trabalho.

Testes genéricos

Em algum momento, testes de lógica e até redação podem ser aplicados.

Em geral, quem não colou na escola e na faculdade deve dar conta desta fase facilmente. Mas se você tem deficiências de escrita ou lógica, sugiro trabalhar isso de alguma forma. É algo que vai lhe marcar pelo resto da vida.

A escrita é fundamental para seu sucesso profissional, seja você um guru da programação ou totalmente sem experiência. O gerente, cliente ou colega mais compreensivo do mundo ficará com uma impressão negativa ao receber um e-mail cheio de erros ortográficos, algumas vezes incompreensível.

Minha sugestão é: leia livros de verdade. Nada de Harry Potter ou Turma da Mônica! E comece a prestar atenção no que você escreve. Colocar ponto de interrogação nas perguntas é um bom começo. 😀

Inglês

Teste de Inglês escrito

Em minha experiência o teste mais comum em entrevistas para TI é, de longe, o de Inglês. Muitas vezes você pode se deparar com três ou quatro perguntas, algumas de múltipla escolha, outras dissertativas. Em alguns casos uma redação.

Se você tem um mínimo de Inglês, revise algum material para reaquecer suas memórias e evitar perder tempo durante a entrevista. Minha sugestão é passar longe dos materiais de cursos e ler algumas páginas de um livro de verdade. Treinar um pouco a escrita também pode ajudar. Revise pelo menos as estruturas básicas de frases mais comuns.

Conversação em Inglês

Em vagas que exigem Inglês avançado ou fluente você provavelmente vai ter que fazer uma ou mais entrevistas conversando em Inglês. Mesmo quando não é uma exigência, você pode ser questionado sobre o seu nível de Inglês, pois dependendo disso a empresa pode lhe alocar em projetos nacionais ou internacionais. Estar preparado pode fazer uma grande diferença em sua carreira.

A conversação pode ser feita com alguém do RH ou com um técnico. Quanto à parte do RH, prepare-se para perguntar básicas sobre sua profissão, seu dia-a-dia, sua cidade, etc. A parte técnica cobrirei num tópico mais adiante.

Treine a audição e a fala como puder. Uma forma que algumas pessoas usam é assistir seriados como CSI Miami sem legenda, pois a estrutura das sentenças é relativamente mais clara e formal comparando com outros programas.

Para a fala, o que funcionou para mim foi ler livros em Inglês em voz alta, consultando sempre um dicionário com os fonemas ou algum dicionário online com áudio para conhecer a pronúncia das palavras “novas”.

A importância do Inglês

Como provavelmente você já deve ter ouvido até da sua avó, saber Inglês é muito importante hoje. Talvez você esteja cansado de ouvir isso, mas nunca precisou de verdade. De qualquer forma, tentarei lhe convencer de que vale a pena investir nisso. Você até pode viver normalmente sem conhecer esse idioma, mas talvez nunca imagine o que está perdendo.

Os principais fóruns de programação do mundo são em Inglês. Embora tenhamos aqui o Stack Overflow em Português, você está perdendo de interagir (ainda que virtualmente) com muitos dos melhores desenvolvedores ao redor do mundo.

Além disso, há um mundo de informações lá fora que não chega até nosso idioma ou demora muito, e quando chega é resumido ou mal traduzido. Novas tecnologias, linguagens e livros são quase sempre publicadas em Inglês. É preciso surgir interesse de uma comunidade inteira ou demanda de mercado para uma empresa alguém dar início à tradução.

No mínimo, você poderia estar assistindo a palestras e aulas gratuitas no YouTube para se aperfeiçoar e conhecer o que os outros estão fazendo nas melhores empresas. Google, Facebook, Amazon e outras grandes empresas possuem conferências onde falam sobre assuntos técnicos e como funciona sua infraestrutura. Você poderia estar recebendo informação diretamente da fonte e aprendendo com os melhores do mundo.

Não ter Inglês para conversação pode fazer você perder grandes oportunidades. Um dos exemplos mais gritantes são as viagens internacionais. A empresa onde trabalho já enviou dezenas e dezenas de pessoas para projetos em toda a Europa, África do Sul e Estados Unidos. Muitos colegas que nunca haviam tido tal experiência, mas que estudaram e aprenderam Inglês suficiente, conseguiram aproveitar tais oportunidades. Você nunca sabe quando vai surgir algo assim para você.

Entrevista técnica

A entrevista técnica pode ser feita de várias formas e geralmente depende da cultura da empresa ou, no caso de empresas pequenas, do gerente ou dono.

Vou lhe apresentar algumas das mais comuns nos próximos tópicos.

Bate-papo técnico

O modelo mais comum de entrevista técnica que vejo consiste num bate-papo sobre o background e a experiência do entrevistado.

É importante você se preparar para explicar em detalhes os projetos em que já trabalhou, principalmente o atual e o anterior, qual foi o seu papel em cada um deles, quais tecnologias utilizou e o máximo de detalhes sobre o uso dessas tecnologias.

Tome muito cuidado ao dizer que conhece algo se você não conhece de verdade. Se você trabalhou em um projeto com JSF, mas nunca usou a tecnologia diretamente, não coloque no currículo. Simples assim. Se usou a tecnologia superficialmente, apenas seguindo instruções dos colegas, deixe isso claro. Enfim, evite uma impressão negativa. É melhor surpreender o entrevistador do que decepcioná-lo.

Destaque no seu currículo e durante a entrevista as tecnologias que você domina e tem mais familiaridade. Dessa forma, o entrevistador será mais propenso a fazer perguntas para as quais você sabe a resposta. Parece óbvio, mas dificilmente vejo um currículo que realmente reflete o conhecimento do profissional.

É importantíssimo entender que o objetivo do entrevistador ao fazer perguntas é explorar os seus conhecimentos sobre tecnologia. É comum você ficar nervoso como se estivesse num tipo de prova. Esqueça isso, você não está na diante daquele professor onde só há uma resposta certa e outra errada.

Por exemplo, uma pergunta muito comum que fazemos é algo como:

Você já trabalhou com SOAP ou REST? Pode me dizer quais seriam as vantagens e desvantagens de cada um?

Dependendo do nível da resposta é possível saber não só o quanto a pessoa conhece essas tecnologias, mas ter uma compreensão geral da profundidade e maturidade do candidato. Note que essa pergunta pode ser feita com qualquer coisa:

Você já trabalhou com JDBC ou JPA? Pode me dizer quais seriam as vantagens e desvantagens de cada um?

Você já trabalhou com Struts ou Spring MVC? Pode me dizer quais seriam as vantagens e desvantagens de cada um?

Você já trabalhou com jQuery ou JavaScript puro? Pode me dizer quais seriam as vantagens e desvantagens de cada um?

Para responder bem a uma pergunta dessas, limite-se ao que você sabe. O que não souber, deixe isso claro. Em nenhuma hipótese invente algo ou afirme que uma das duas opções é absolutamente superior à outra. Reconhecer os próprios limites é uma virtude.

Certa vez, ao ser questionado sobre porque nunca havia usado JDBC, um candidato respondeu que era uma tecnologia ultrapassada. Isso foi pior, muito pior, do que dizer “não sei”, “não gosto”, “não tive a chance”, “não precisei”, etc. Na verdade, ele demonstrou um conhecimento superficial sobre o assunto.

Outro ponto importante é não ter medo de dizer que você não conhece algo ou não sabe responder a uma pergunta. Simplesmente diga que você não teve a oportunidade de trabalhar com determinada coisa.

Outro erro comum, principalmente dos mais inexperientes, é dizer que tem o conhecimento acadêmico ou simplesmente que “já viu isso na faculdade”. Só para reforçar: jogue fora essa mentalidade do MEC! Diplomas, cursos e aulas não valem de nada se você não aprendeu a fazer algo útil. Ao invés de dizer “vi isso na disciplina X”, explique o que você realmente fez naquela disciplina.

Por exemplo, durante faculdade desenvolvi um módulo de um ERP web em PHP para uma disciplina específica. Mesmo não sendo uma experiência dentro do mercado, é muito melhor mencionar isso do que dizer “tive aulas de estrutura de dados na linguagem X”.

É claro que estou assumindo até aqui que você realmente executou esses trabalhos. Lembre-se de que projetos não terminados, ou que ficaram na mão de seus colegas e você só “participou” não contam em nada. A realidade pode ser cruel para quem achou que bastaria o diploma e o sucesso seguiria facilmente.

Algo que pode ajudar bastante é conversar sobre tecnologia com seus colegas, dar treinamentos para estagiários ou até aulas em cursos técnicos. Conheço excelentes profissionais, mas que tem muita dificuldade em expressar o conhecimento de forma organizada. Também tenho essa dificuldade, mas desde que comecei a me dedicar a organizar aulas, apostilas e palestras, além de explicar conceitos para os colegas, melhorei imensamente.

Desafio de programação

Outro tipo de entrevista técnica consiste num desafio de programação. Isso significa, em geral, usar lápis e papel ou até uma lousa para codificar uma solução para um problema simples.

Bons programadores não devem ficar presos a uma IDE. Se você nunca programou assim, repense sua carreira!

Além disso, bons programadores geralmente já programaram bastante o suficiente de forma que a sintaxe é algo natural para eles, assim como o Português. Ok, é isso é um pouco de exagero. 😉

De qualquer forma, é importante às vezes tentar fazer esse tipo de desafio. Escrever código, embora seja muito mais lento do que usar um teclado e uma IDE, o ajudará a pensar melhor sobre o que você escreve, afinal um erro significa apagar com borracha e refazer.

Os problemas a serem resolvidos podem ser diversos. Podem pedir que você implemente um algoritmo de ordenação qualquer, por exemplo.

Quase sempre você é livre para usar a linguagem que desejar, até pseudo-código, desde que resolva o problema.

Uma forma de treinar seu músculo mental solucionador de algoritmos é através de alguns sites que possuem desafios de programação. Um exemplo é o Code Chef. Você pode entrar em uma série de desafios, escolher a linguagem e testar sua solução. Ele vai lhe avisar se a solução está certa ou errada, você pode olhar as soluções já postadas e há um ranking para você comparar o desempenho da sua solução.

Do meu ponto de vista, poucas empresas aplicam corretamente o desafio de programação. Eu o considero um critério muito importante. Ver outro programando revela a sua intimidade com o código e como ele desenvolve o raciocínio. Pena isso não ser tão comum, de forma que muitos ficam assustados diante de tal desafio.

É bom lembrar que a dificuldade do desafio de programação varia conforme a exigência da empresa. Empresas como Google, Amazon e Facebook são conhecidas por exigir que você crie algoritmos que sejam soluções perfeitas e, ainda por cima, faça a análise da complexidade de tempo e espaço da solução. Se você não tem ideia do que isso significa, pesquise bem antes de sequer pensar em entrar para uma empresa desse porte.

Desafio de design

Outro tipo de desafio é sobre design orientado a objetos. O entrevistador pode pedir para você modelar algo usando UML, porém não exigindo uma sintaxe estrita.

Um exemplo comum deste tipo de entrevista é pedir para você modelar um cliente de e-mail. Outro é você criar uma hierarquia de classes, por exemplo, usando meios de transporte.

Este tipo de entrevista não é tão comum no Brasil, portanto você só vai precisar se preocupar com isso se estiver tentando algumas das empresas mais difíceis.

Além dos conceitos de Orientação a Objetos e UML básica, os requisitos para este tipo de entrevista são domínio de design patterns (Padrões de Projetos), alguma vivência em modelagem (acredite, experiência faz diferença nas decisões que você toma) e uma boa pitada de criatividade.

Entrevista técnica em Inglês

Não há nada possível de ser feito para aprender Inglês em poucas horas ou dias. No entanto, você pode se preparar para uma conversa técnica lendo algum material em Inglês sobre as tecnologias que você mais conhece.

A entrevista em Inglês pode consistir apenas num trecho da entrevista técnica normal. Neste caso, o entrevistador vai lhe perguntar se você está confortável para falar Inglês e, se você concordar, vai chavear a língua e lhe fazer alguma das perguntas planejadas.

Numa entrevista que fiz, o entrevistador pediu para eu explicar a arquitetura de uma aplicação que havia criado no emprego anterior.

O importante não é ter pronúncia ou gramática perfeitas. Em geral, é aceitável se você conseguir comunicar suas ideias com clareza. Se não lembrar alguma palavra ou termo, não tenha medo de perguntar ou usar analogias para se expressar, sempre em Inglês, é claro.

Entrevista com um gerente ou líder

Dependendo da estrutura da empresa, é comum ter uma entrevista com um gerente ou líder de equipe, o qual pode ou não ter um background técnico.

Neste tipo de entrevista, provavelmente não haverá um aprofundamento na parte técnica, mas o entrevistador vai procurar saber como você lida com situações difíceis, pressão, como organiza seu dia-a-dia, etc.

Para um gerente ou líder, você deve demonstrar pró-atividade, capacidade de resolver problemas e correr atrás do que for necessário.

Como já disse em outro artigo, o gerente ou líder está preocupado em contratar alguém que vai aliviar o trabalho da equipe a não acrescentar mais. Você deve ser alguém que vai contribuir e não atrapalhar, somar e não subtrair, resolver problemas e não causá-los.

Faça anotações das situações mais complicadas por que já passou e avalie como você enfrentou essa situação e o que poderia ter feito de melhor. Esta análise vai ajudá-lo não só na entrevista como pessoa, afinal encarar fracassos passados e sentir vergonha de como você agiu de forma imatura é o primeiro passo para o amadurecimento profissional.

Perguntas ao entrevistador técnico

Durante o bate-papo, você também pode e deve fazer perguntas. Algumas que eu faria são:

  1. Qual é a função do entrevistador (caso ele não tenha se apresentado). Ele é um gerente, desenvolvedor, líder?
  2. Como é o processo de desenvolvimento. Usam Scrum, RUP? Se responderem algo como CMMI ou MPS.BR você já pode esperar que eles vão ter muita burocracia e não realmente um processo de desenvolvimento de software.
  3. Integração Contínua. Eles tem algum nível de automação no desenvolvimento?
  4. Testes. Eles costumam fazer testes unitários ou de integração? Tem algum nível de automação dos testes?
  5. Carreira. Como os desenvolvedores são avaliados? Há plano de carreira?
  6. Equipe. Qual a composição e os papeis comuns nas equipes? Existem DBAs, Scrum Masters, arquitetos? Como é a divisão de atividades?
  7. Ferramentas. Quais as ferramentas estão à disposição dos desenvolvedores? Há flexibilidade para adoção de novas ferramentas?
  8. Tecnologias. Quem define como é a arquitetura dos projetos? Há um padrão da empresa, do cliente ou as equipes tem liberdade de usar as tecnologias mais adequadas em cada projeto?

Algumas perguntas podem ser até repetidas em diferentes entrevistas. Você talvez tenha notado que coloquei perguntas muito semelhantes às da outra lista. Isso possibilita ter visões distintas sobre a empresa.

O quanto falar

Durante a entrevista técnica, seja com um desenvolvedor ou gerente, você deve tentar prestar atenção no quanto você fala. Ao responder as perguntas, não fale de menos, respondendo apenas “sim” ou “não” ou “conheço” ou “ouvi falar”.

Lembre-se de que você não está fazendo o vestibular e para passar deve preencher a bolinha correta. O entrevistador tem o objetivo de identificar seus conhecimentos, a profundidade deles, pontos fortes e fracos.

Ao ser questionado sobre qualquer tecnologia, procure ir sempre direto ao assunto, mas mostre que você sabe do que está falando.

Por exemplo, na pergunta que citei anteriormente sobre SOAP e REST, um comentário significativo seria o seguinte:

Mensagens REST em formato JSON em geral são mais leves em relação ao protocolo SOAP, pois este acrescenta o overhead das tags XML que não fazem parte da mensagem principal.

O parágrafo acima demonstra proficiência nas duas tecnologias sem a necessidade de explicar cada uma delas detalhadamente.

Cuidado com a desorganização

Às vezes pensamos que o processo seletivo é algo de outro mundo, totalmente perfeito e organizado. Ficamos até com receio de cobrar nosso contato na empresa em caso de demora, pois sempre achamos que o problema é com a gente.

Pelo contrário, é comum haver de falhas de comunicação ou até outros imprevistos. Muitos funcionários de RH estão sobrecarregados e podem cometer erros. Eles podem esquecer de algumas coisas.

Não sinta-se acanhado em fazer perguntas e questionar sobre o andamento do processo. Se eles souberem vão lhe responder. Também não tenha medo de cobrar uma resposta, principalmente se você tem necessidade disso, como no caso onde está escolhendo entre dois empregos ou precisa pensar numa mudança para longe.

Mantenha a calma

Em minhas “pesquisas”, estar calmo durante a entrevista é a segunda coisa mais importante, atrás apenas de não mentir.

É difícil dizer algo que vá realmente lhe acalmar, afinal eu também costumo ficar bastante nervoso em entrevistas, mas darei algumas dicas que podem ajudar, algumas repetidas dos tópicos anteriores:

  1. Esteja preparado. Saber que tipo de entrevista, quais tipos de perguntas e o que lhe espera em cada passo ajuda a não ser pego de surpresa e, portanto, a não perder a calma.
  2. Leia sobre o assunto. Ok, você já está fazendo isso agora, não é? Ler sobre experiências de outras pessoas e estabelecer expectativas ajuda. É mais uma forma de descarregar as preocupações da mente e evitar surpresas.
  3. Converse sobre o assunto. Fale com amigos que já passaram por isso, compartilhe suas expectativas e receios. Só cuidado com os “amigos da onça”.
  4. Entenda que você está lidando com humanos. Um problema muito comum é acharmos que o entrevistador é um tipo de deus. Há alguns anos eu mesmo pensava que os entrevistadores eram as pessoas mais inteligentes do mundo, que conheciam todas as tecnologias e sabiam de tudo, afinal a responsabilidade delas é imensa. Embora alguns entrevistadores sejam bons profissionais, eles também são pessoas como eu e você. Entenda que ele não está lá para encontrar seus defeitos, mas suas qualidades.

É irônico que muitas vezes temos bastante facilidade para conversar sobre tecnologia e trabalho com nossos colegas e emperramos diante de um entrevistador. Então, minha técnica predileta é pensar que o entrevistador é só mais um colega de empresa e estou explicando a ele sobre aquele tópico.

Não confunda as coisas

É obrigação do entrevistador ser amigável. Mas sorrir ou balançar a cabeça em concordância com você não significa que a vaga está garantida.

Lembre-se de que o entrevistador não está lá para lhe ensinar ou entrar em debates técnicos. Em determinadas ocasiões, o entrevistador pode lhe apontar algo que você fez de errado, principalmente se você demonstrar um espírito humilde.

Mas se você for do tipo que tem certeza sem estar certo e falar uma besteira muito grande, ele pode dizer “ok” e ir para a próxima pergunta.

Enfim, cuidado para não achar que foi uma entrevista excelente porque o entrevistador não apontou nenhum erro.

Conclusões

Como você já deve ter percebido, este pequeno guia é apenas um breve apanhado de como funcionam os processos seletivos para empregos de desenvolvimento de software que envolvem programação. O objetivo é torná-lo familiar a você, desmistificá-lo, pois quando entendemos como algo funciona é mais fácil perder o medo.

Escrevi isso após bastante reflexão sobre a minha própria carreira, algumas experiências entrevistando candidatos, ministrando cursos e aulas, além de conversas com outros colegas até mais experientes do que eu. Espero que seja útil de alguma forma.

Se você não leu ou não entendeu nada do que está acima, fique com uma coisa:

Conhecer a si mesmo, identificar os próprios defeitos e limitações, refletir sobre como melhorar e estar sempre tomando pequenas atitudes para evoluir como pessoa e como profissional são a regra certa de sucesso.

Sinta-se à vontade para compartilhar suas experiências nos comentários deste blog. Elas podem ajudar outros desenvolvedores! 😀

SQL Server: comparando duas bases de dados com uma query

sql server

Muitos colegas já tiveram a necessidade de comparar duas bases de dados no SQL Server para analisar rapidamente a diferença entre elas.

Como é algo recorrente, estou publicando aqui uma consulta (query) que compara a estrutura de duas bases e destaca tabelas e campos que existem em uma e não na outra, bidirecionalmente.

Bases de exemplo

Imagine que você tem um BANCO_A:

use BANCO_A;
go

create table Person (
    id int primary key identity,
    name varchar(100),
    height numeric(4,1)
);

create table Car (
    id int primary key identity,
    brand varchar(100),
    model varchar(100),
    year int 
);

create table Animal (
    id int primary key identity,
    name varchar(100),
    kind varchar(100)
);

E também um BANCO_B:

use BANCO_B;
go

create table Person (
    id int primary key identity,
    name varchar(100)
);

create table Car (
    id int primary key identity,
    brand varchar(100),
    model varchar(100),
    year float,
    kilometers int
);

create table Pet (
    id int primary key identity,
    name varchar(100)
);

Verificando tabelas adicionadas e excluídas

Para identificar somente as tabelas que foram adicionadas ou excluídas de uma base para outra, use a seguinte consulta:

SELECT T1.TABLE_NAME 'DB1 TABLE', T2.TABLE_NAME 'DB2 TABLE'
FROM BANCO_A.INFORMATION_SCHEMA.TABLES T1 
FULL JOIN BANCO_B.INFORMATION_SCHEMA.TABLES T2 
    ON T1.TABLE_NAME = T2.TABLE_NAME
ORDER BY ISNULL(T1.TABLE_NAME, T2.TABLE_NAME)

Verificando colunas adicionadas e excluídas

Para verificar as diferenças tanto das tabelas como das colunas que elas contém, use a seguinte consulta:

SELECT DB1.TABLE_NAME 'DB1 TABLE', DB1.COLUMN_NAME 'DB1 COLUMN', DB1.DATA_TYPE 'DB1 TYPE',
    DB2.TABLE_NAME 'DB2 TABLE', DB2.COLUMN_NAME 'DB1 COLUMN', DB2.DATA_TYPE 'DB2 TYPE'
FROM (
    SELECT T1.TABLE_NAME, C1.COLUMN_NAME, C1.DATA_TYPE
    FROM BANCO_A.INFORMATION_SCHEMA.TABLES T1 
    JOIN BANCO_A.INFORMATION_SCHEMA.COLUMNS C1 
        ON C1.TABLE_NAME = T1.TABLE_NAME
    ) DB1
FULL JOIN (
    SELECT T2.TABLE_NAME, C2.COLUMN_NAME, C2.DATA_TYPE
    FROM BANCO_B.INFORMATION_SCHEMA.TABLES T2 
    JOIN BANCO_B.INFORMATION_SCHEMA.COLUMNS C2 
        ON C2.TABLE_NAME = T2.TABLE_NAME
    ) DB2
    ON DB1.TABLE_NAME = DB2.TABLE_NAME
    AND DB1.COLUMN_NAME = DB2.COLUMN_NAME
ORDER BY ISNULL(DB1.TABLE_NAME, DB2.TABLE_NAME), ISNULL(DB1.COLUMN_NAME, DB2.COLUMN_NAME)

Executando a consulta dinamicamente

Nos dois exemplos acima, basta trocar BANCO_A e BANCO_B por duas bases que você precisa comparar.

Entretanto, pode ser que você queira criar uma procedure ou rotina que compare duas bases quaisquer.

Para isso você pode executar uma consulta dinâmica usando o comando SP_SQLEXEC. Veja o seguinte exemplo:

DECLARE 
    @BANCO1 NVARCHAR(100) = 'BANCO_A',
    @BANCO2 NVARCHAR(100) = 'BANCO_B',
    @SQL NVARCHAR(2000)

SET @SQL = N'SELECT T1.TABLE_NAME ''DB1 TABLE'', T2.TABLE_NAME ''DB2 TABLE''
    FROM ' + @BANCO1 + '.INFORMATION_SCHEMA.TABLES T1 
    FULL JOIN ' + @BANCO2 + '.INFORMATION_SCHEMA.TABLES T2 
        ON T1.TABLE_NAME = T2.TABLE_NAME
    ORDER BY ISNULL(T1.TABLE_NAME, T2.TABLE_NAME)';

EXEC sp_sqlexec @SQL

Agora basta alterar o valor das variáveis ou receber os nomes das duas bases através de parâmetros.

Duas observações importantes:

  1. O parâmetro da rotina SP_SQLEXEC deve ser do tipo NVARCHAR.
  2. Não tente fazer a concatenação de variáveis e literais diretamente no argumento dessa rotina. Faça isso sempre antes e então passe uma variável como argumento. Não fiz o teste em todas as versões do SQL Server, mas nas que usei deve ser desta forma.

Um guia para você conseguir um bom emprego como desenvolvedor de software

emprego

Quer um emprego para trabalhar com desenvolvimento de software? Quer ser um programador, analista de sistemas ou algo nessa linha? Tentarei ajudá-lo(a) você nesta jornada.

Antes de tudo, porém, adianto que se você quer apenas arranjar um emprego, ou talvez esteja pensando em entrar nessa área porque sua avó disse que é coisa de gente moderna, ou porque viu no telejornal que a área de TI está pagando bem, ou porque você sabe usar o Word e o Facebook e acha que conhece informática, este artigo não é para você.

Tenho feito entrevistas, ministrado aulas em faculdades e trabalhado com diversos desenvolvedores. Com esta experiência, talvez consiga abrir um pouco a sua mente para a realidade do mercado de TI.

Alguns podem ter um choque de realidade, outros podem achar óbvio demais. Mas espero que, em algum grau, você tire algum proveito.

Entenda sua vocação

Ao contrário do que alguns cientistas sociais pregam, as pessoas são particularmente diferentes umas das outras e tem inclinações diferentes. Antes de qualquer outra coisa, é importante saber se você tem a vocação para trabalhar com Tecnologia da Informação. Não é uma tarefa fácil descobrir sua vocação, mas quanto antes você conseguir mais rapidamente obterá o tão almejado sucesso profissional.

Pense que talvez você simplesmente não tenha jeito para trabalhar com TI. Desenvolver software, seja como um programador ou analista, não funciona como em uma linha de produção, onde as coisas fluem de forma automática e basta você decorar onde se encaixam os parafusos e quais os botões certos para apertar.

Você deve gostar e dominar o que faz para ser um bom profissional. Claro que isso pode ser aplicado em qualquer área. 😉

Conheço muita gente que seria mais feliz vendendo côco na praia ou fabricando salgados e doces ao invés de ficar trancado o dia inteiro num escritório com luz artificial e um ar condicionado que ora está fraco, ora está forte demais. Além de passar a maior parte do seu dia na frente de um computador, você terá que lidar com informações abstratas e longe da realidade da maioria das pessoas “normais” (tenho dúvidas se uso aspas ou não…).

Características de um bom programador

Uma característica essencial a quem trabalha com software é a capacidade de concentração. Se você não consegue focar sua mente em uma tarefa por muito tempo, terá dificuldades em entender códigos e processos complexos.

Outra característica é a curiosidade sobre detalhes técnicos. Se para você um computador é uma caixa preta que o assusta quando algo estranho ocorre, terá problemas em conseguir dominar essa “fera” em todos os seus aspectos.

Além disso, mesmo que você tenha uma afinidade com TI, ainda precisa compreender em qual área você se encaixa melhor. Alguns jovens tornam-se especialistas em sistemas operacionais como Linux por sua curiosidade em entender como esses sistemas funcionam. Outros (como foi o meu caso) descobrem uma linguagem de programação qualquer e começam a fuçar todos os comandos para ver o que eles fazem.

Você consegue se identificar com algum desses estereótipos?

Conciliando vocação com a demanda do mercado

Muita gente tem “jeito” para trabalhar com computadores, porém não tem um perfil adequado para as vagas disponíveis.

Embora seja louvável que as pessoas busquem mais conhecimento no que se refere à sua vocação e interesses, também faz-se necessário chegar a um equilíbrio entre o que gostamos e as demandas da vida real.

Para ser um bom empreendedor, você deve compreender muito bem as necessidades e desejos do seu público alvo e adaptar-se. Para conseguir um bom emprego, você deve descobrir as necessidades do seu provável futuro empregador e adaptar-se.

A forma mais simples de fazer isso é olhar as vagas atualmente abertas. Não faça uma busca superficial. Olhe todas as vagas que puder e chegue a um denominador comum de quais tecnologias e perfis profissionais são mais requisitados pelo mercado e que estejam alinhados com a sua vocação.

Assim, direcione seus estudos, seu conhecimento e sua paixão para algo que também lhe dê um retorno profissional.

Por exemplo, hoje Java e .NET são as plataformas mais comumente usadas no mercado brasileiro. Entretanto, muitos dos que gostam de programação e estão por dentro das tendências tecnológicas preferem trabalhar com Ruby on Rails, Python/Django, etc. Mas você deve entender que muitas empresas não têm escolha ou não tem know-how para isso, então você deve ser flexível para trabalhar com as tecnologias “de mercado”, tanto quanto suas tecnologias “preferidas”.

Uma forma de conciliar isso é conhecer as plataformas usadas no mercado, onde geralmente se concentra o investimento financeiro, e usar nossas tecnologias prediletas em projetos pessoais e ferramentas internas, construindo um ambiente de desenvolvimento saudável.

Tenha bons fundamentos técnicos e teóricos

Independente da vocação e das experiências que você tenha, conhecer os fundamentos sobre Orientação a Objetos, protocolo HTTP, gerenciamento de memória, funcionamento dos sistemas operacionais, lógica e algoritmos é essencial para seu sucesso desenvolvendo software.

Algumas pessoas argumentam que a teoria é muito diferente da prática e que essas coisas em geral são ensinadas de forma equivocada. Na verdade, concordo com isso. Porém, como a codificação de um programa consiste justamente em trabalhar com conceitos abstratos, esta é uma das poucas áreas onde a teoria pode se aproximar muito da prática, desde que o desenvolvedor realmente entenda os conceitos que está aplicando.

Tenha experiência prática

Se você não tem experiência em programação, e com isso quero dizer tempo programando de verdade, sem contar algum estágio muito básico, cursos ou aulas em laboratório, então dedique-se a desenvolver algo por conta e a participar de desafios de programação.

Assim como andar de bicicleta ou dirigir, teoria não basta para ser um bom programador. Quanto mais quilômetros rodados, mais qualidade e eficiência terá o código que você cria, e maior será seu valor no mercado de trabalho.

Uma enorme vantagem da área de desenvolvimento de software é que apenas com seu computador pessoal e internet é possível aprender e ter algum contato com praticamente qualquer tecnologia. Então sem desculpas! É claro que, em contrapartida, acaba sendo também uma exigência que os novatos na área já tenham algum nível de contato com as tecnologias.

Encare a realidade

A realidade é que provavelmente você é um programador bem ruim.

Como ter certeza disso? Responda a si mesmo: quantos softwares você já entregou ao cliente final e os deixou plenamente satisfeitos?

Algumas empresas procuram apenas por pessoas que já tenham entregue software de qualidade para o cliente ou, como dizemos, já tenham colocando bastante código em produção.

Ao programar apenas para si mesmo, você nunca vai encontrar seus erros. Há relatos de sistemas desenvolvidos durante meses com “altos padrões de qualidade”, mas que não resistiram ao primeiro clique do usuário.

Somente tendo suas habilidades confrontadas e questionadas por pessoas mais experientes, desenvolvedores e usuários, você pode vir a ser um bom programador.

Converta-se da sua mentalidade MEC

Se você quer mesmo conseguir um bom emprego, numa boa empresa, não espere que lhe ensinem tudo o que você precisa saber. Seja ou torne-se capaz de correr atrás do conhecimento sozinho.

Já vi muita gente reclamar que a faculdade tem uma grade ruim, o professor não ensina direito, a empresa não oferece cursos de aperfeiçoamento. Embora tudo isso seja muito bom e útil alguns para dar algum impulso inicial, nenhuma iniciativa será capaz de automatizar o seu aprendizado.

Você não pode depender de professores, chefes ou colegas para realizar seu trabalho, ou vai ficar somente com as piores vagas, enquanto outras pessoas mais proficientes ficarão com as melhores.

Faça uma lavagem cerebral em si mesmo. Esqueça diplomas, certificados, cursos. Isso não vale de nada. O que conta é o que você realmente sabe fazer.

Torne-se desejável

Ter vocação e habilidades técnicas não basta. Para obter um bom emprego você deve ser alguém que as pessoas queiram perto de si. Note o destaque no verbo querer.

Se você não possui nenhuma área de destaque, é uma pessoa difícil e os outros precisam suportar você, é mais um peso do que uma ajuda, dá mais trabalho aos outros do que os alivia, então isso precisa mudar!

Torne-se desejável para as empresas

Não, não quero que você seja como um cachorrinho que faz tudo o que a empresa pede. Tornar-se desejável significa ter algo que elas querem e que fariam elas pagarem para ter você no quadro de funcionários.

A grade questão é: o que as empresas procuram? Isso varia.

Empresas pequenas tem um quadro de funcionários enxuto e precisam entregar mais código por desenvolvedor. Nem sempre a qualidade é a melhor, mas os sistemas precisam atender no mínimo às demandas essenciais dos clientes da empresa. Além disso, empresas pequenas não tem recursos para realizar treinamentos extensivos ou custear um funcionário que não dá um retorno mais imediato.

Empresas grandes tem mais recursos para arcar com empregados menos produtivos e treinamentos, mas ainda assim, você deve chamar atenção suficiente ser chamado para a entrevista, demonstrar proficiência em alguma tecnologia e saber se virar de alguma forma.

Em geral ter experiência em tecnologias específicas e conhecimentos específicos é o principal ponto para qualquer vaga. Porém, como já foi mencionado anteriormente, você não precisa ter necessariamente trabalhado numa empresa para conhecer essas tecnologias. Se você for ser capaz de demonstrar que consegue produzir algo útil, tendo trabalhado talvez em projetos pessoais ou com amigos, de forma que tenha conhecimento pleno do seu funcionamento, isso será suficiente.

Enfim, você deve ter no seu currículo algo que demonstre sua vivência com programação e tecnologias específicas, não apenas uma lista de siglas que você ouviu seu professor falar ou já esbarrou em algum projeto, mas não tem domínio algum.

Torne-se desejável para seus colegas

Muita injustiças ocorrem nas entrevistas e cada entrevistador tem seu jeito próprio. Alguns não tentam realmente achar os pontos fortes do entrevistado, outro ficam com o ego inflado por terem o poder de decisão nas mãos e acabam desprezando pessoas boas. Acontece, mas não se apegue a isso.

Um princípio praticamente universal que pode lhe direcionar neste aspecto é pensar como se estivesse do outro lado. Se você estivesse se entrevistando, o que o levaria você a se contratar? Você é alguém com quem os outros gostariam de trabalhar?

Não há uma norma absoluta de como ser ou tornar-se alguém bom para se trabalhar. Você simplesmente é.

Nesse ponto, certamente há diferentes opiniões. As pessoas tem exigências diferentes. Alguns chefes são mais exigentes, outros mais compreensivos. Alguns colegas gostam de ajudar os novatos, outros nem tanto. Mas num ponto todos eles convergem: eles amariam um colega que os aliviasse da sua carga trabalho atual e de precisar saber detalhes técnicos desnecessários.

Você consegue dar conta da parte técnica de um projeto ou pelo menos no que se refere às suas atividades? Ou sempre precisa de ajuda para fazer qualquer coisa e os outros precisam despender muito tempo entendendo o seu trabalho?

Você dá trabalho ao fazer o seu trabalho?

Muita gente pense que, ao ser contratado, a empresa lhe deve o salário, uma séria de obrigações e ainda é obrigada a lhe ensinar como trabalhar. Bem, até certo ponto isso pode ser verdade. Mas é esperado que você retorne algo em contrapartida, contribuindo para o trabalho que precisa ser feito.

No entanto, o que muita gente não enxerga é que muitas vezes ela dá mais prejuízo do que lucro para a empresa.

Façamos uma conta simples. Você entra como desenvolvedor júnior na empresa ganhando 1.000 reais. Seu chefe, que ganha 4.000 reais, gasta duas horas do dia dele entre lhe passar atividades, tirar dúvidas, cuidar da burocracia no que se refere a você. Caso você não seja produtivo o suficiente, seria melhor ele usar as duas horas que ele gasta com você para fazer o seu trabalho e a empresa ainda economizaria o seu salário e impostos.

Estudos relatam que programadores com o mesmo nível de experiência podem ter diferenças de produtividade num fator de 10, o que significa que algumas pessoas produzem 10 vezes mais do que outras. Portanto é de se esperar que uma hora do seu chefe, líder ou colega vale muito mais do que a sua.

E as coisas podem ficar ainda piores. Se fizermos uma média de quantos bugs cada programador costuma introduzir por linha de código, certamente os mais novatos ficarão com os maiores índices. E código mal feito também custa dinheiro, porque cedo ou tarde alguém vai ter que perder tempo para arrumá-lo. O problema é que correção de bugs e refatoração de código custam muito tempo e dinheiro.

Portanto, se você produz código de baixa qualidade, ninguém vai querer lhe passar tarefas e você vai ficar como aquele que é o último escolhido para o time de futebol. No entanto, se o seu código não causa dor de cabeça para seus colegas e líderes, então você será sempre um dos primeiros escolhidos para os projetos.

Tiramos daqui duas lições:

  1. Valorize as oportunidades que lhe dão, pois um júnior é quase sempre um investimento e não lucro para a empresa.
  2. Ninguém em sã consciência (a não ser o Governo, talvez) vai manter um funcionário numa posição de forma que dê prejuízo, que seja um empecilho para a empresa e não contribua para o bom andamento das atividades.

Se você mais dá trabalho aos outros do que elimina trabalho, vai ter dificuldades em encontrar um bom emprego. Não adianta conhecer todas as APIs e linguagens do mundo se isso efetivamente não resolve o problema de alguém.

Por outro lado, se você é alguém que resolve as coisas, sabe se virar, consegue tirar o peso dos ombros dos chefes e colegas, então será mais do que bem-vindo em qualquer equipe ou empresa.

Habilidades técnicas não bastam

Vocação, conhecimento técnico e um perfil desejável são fundamentais. Entretanto, algo impeditivo na vida de muitas desenvolvedores está na falta de bons relacionamentos profissionais, dificuldade em se expressar e comunicar.

Você precisa melhorar suas habilidades sociais. Isso deve ser feito em dois níveis, pelo menos.

Tenha contato com outros desenvolvedores

Ter uma rede de amizades é essencial para o aprendizado como profissional e decisivo para saber onde estão os bons emprego. Não tenho uma estatística exata, mas posso afirmar categoricamente que, de todos colegas que tive em todas as empresas que trabalhei, 99% deles estudaram ou trabalharam juntos anteriormente.

As indicações não apenas ajudam a colocar pessoas dentro das empresas devido ao conhecimento antecipado do perfil do funcionário, mas também faz com que o candidato tenha um pré-conhecimento da empresa em que pretende trabalhar.

Um amigo lhe diz que trabalhar na empresa X é legal, logo seu interesse em trabalhar para X será automaticamente maior do que para Y ou Z, afinal você conhece um pouco sobre a empresa.

Da mesma forma, seu amigo lhe indica na empresa como alguém que ele conhece. Embora você ainda tenha que passar normalmente pelo processo seletivo, se os entrevistadores tiverem que escolher quem vão entrevistar dentre 100 candidatos, é muito mais lógico que eles confiem na indicação de um conhecido do que em currículos recebidos pela internet de pessoas desconhecidas.

Indicação não significa contratar pessoas menos qualificadas para trabalhar. Pelo contrário, consiste em indicar pessoas qualificadas de forma muito mais direta e eficiente, afinal há um conceito de que “bons programadores em geral tem como amigos outros bons programadores”.

Não que é impossível quebrar essa barreira. Às vezes o RH funciona como deveria. Às vezes.

Saiba comunicar-se com programadores e não programadores

Programadores geralmente não tem dificuldades em comunicar-se com programadores. Mas programadores também são gente, então habilidades sociais são necessárias. Você deve saber explicar suas atividades, tecnologias, aquilo que você sabe. Se você não consegue passar algum conhecimento para novatos ou explicar o seu numa entrevista, será impossível que os outros olhem dentro de você e vejam que você é um bom programador.

Por outro lado, gerentes não técnicos, funcionários de RH e outras pessoas que você encontrará pelo caminho não vão se impressionar pela sua “nerdice”. Além de conhecer bem a parte técnica, você deve saber se comunicar com pessoas que não são da área.

Nesse aspecto, uma mentalidade abstrata pode funcionar bem. Sempre que conversar com essas pessoas, ao invés de falar em “techenês”, procure sempre usar analogias com coisas cotidianas para explicar o que você faz. Isso demonstra que você tem segurança e ainda é capaz explicar coisas complexas de forma simples para pessoas que não dominam o assunto.

Seja persistente

Não é agora que vou começar com mensagens positivistas. Quando falo sobre persistência, estou me referindo a um aspecto bem prático.

Explico: é comum ser rejeitado ao concorrer para uma vaga.

Pode ser que você (ainda) não tenha o perfil adequado para aquela vaga ou empresa. Pode ser que, justamente naquela ocasião, outro candidato mais qualificado tenha surgido. Pode ser que seu desempenho não tenha sido ideal. Talvez você pisou na bola justamente em um tópico importante para o entrevistador. O entrevistador pode ter sido injusto.

Mas saiba que é muito comum pessoas serem chamadas tempos depois da entrevista, quando pensavam não ter mais chance. Também acontece de se fazer uma nova entrevista alguns meses depois e conseguir o emprego.

Então, se você quer conseguir um emprego numa determinada empresa, não desanime se não for chamado para entrevista ou não passar logo na primeira tentativa. Tudo pode ser uma questão de ocasião e oportunidade. A paciência e a persistência desempenham um papel fundamental.

Um erro comum, que eu mesmo já cometi, é mandar o currículo para o e-mail padrão do RH da empresa. Ao não ser respondido, assumi que eles não tinham vagas ou não queriam me contratar. Poucos meses depois. um head hunter contratado por essa mesma empresa encontrou meu currículo no LinkedIn e me chamou para uma entrevista. O que mudou nesse tempo? Absolutamente nada. O e-mail para o RH simplesmente deve ter sido ignorado. Se tivesse insistido, talvez conseguisse o emprego meses antes.

Conclusões

Não existe fórmula mágica para conseguir um emprego, ainda mais um bom emprego.

Espero que tudo o que eu disse até agora não tenha soado abstrato ou superficial, mas lhe tenha feito enxergar algo novo.

Estudar o que o mercado demanda, através da análise das empresas e das vagas, geralmente é um bom começo. A partir disso, estabeleça suas próprias metas e se esforce para chegar lá. Não se esqueça também de fazer contatos com empresas e profissionais para manter sua rede de networking.

Cada aspecto mencionado neste artigo não deve ser abordado de forma isolada. Ser um bom técnico é importante, mas não garante um emprego. Ter alguém para fazer indicação é muito bom, mas se você não tiver bons conhecimentos ou não souber expor suas habilidades a situação pode ser constrangedora para você e para quem lhe indicou.

Aliás, pense duas vezes antes de pedir para alguém lhe indicar para uma vaga. Não espere conseguir um emprego somente por questão de amizade. E se a pessoa se negar a fazer a indicação, não fique triste ou indignado. Pode ser que ela saiba que você não ter o perfil necessário e, se isso for verdade, ambos podem ter a reputação abalada.

Uma ideia melhor é perguntar a seus amigos se eles acham que você tem o perfil para a vaga e, com humildade, indagar o que poderia fazer para vir a ter esse perfil.

Construir um bom perfil profissional, ter bons conhecimentos e uma boa reputação não é algo que se faz em poucos meses. Talvez você leve alguns anos, mas nunca vai se arrepender.

Para resumir tudo: se você quer um bom emprego, precisa antes ser um bom funcionário, empregado e colega, com o qual os outros gostariam de trabalhar.

Jericho Selector, a.k.a jQuery for Java

CSS3

I’m pleased to announce the first stable release of Jericho Selector.

Jericho Selector is an extension to the known library Jericho HTML Parser that allows you to select elements from an HTML document just like you do with jQuery, using CSS selectors.

Why Jericho? Different from jsoup, it allows you to modify the document keeping the original formatting. Other libraries rewrite the entire document. Anyway, I like to have a choice! 😉

Jericho Selector is completely free. It uses MIT license.

How to use

Jericho Selector is available at Maven Central Repository, so you just need to add the following dependency to your project:

<dependency>
    <groupId>br.com.starcode.jerichoselector</groupId>
    <artifactId>jericho-selector</artifactId>
    <version>1.0.1-RELEASE</version>
</dependency>

Import the static method $ that is the entry point for Jericho Selector:

import static br.com.starcode.jerichoselector.jerQuery.$;

Then you can query HTML elements just like jQuery:

$(html, "p.my-text")

What has been done

Before implementing Jericho Selector, I had to implement a full CSS parser. In order to do that, I created another library called parCCSer. It was based on the official W3C CSS3 specification and covers almot all of the specification, except some details that are valid only in the context of a browser and also something related to UTF-8 support that I considered not entirely necessary. It’s also under MIT license.

Jericho Selector then uses the object tree generated by parCCser, as the Jericho HTML Parser API, to query the HTML document elements given a CSS selector.

All implementitions are covered by unit testes above 90%, without taking in account excepcional cases that the plugin are not able to analyse.

What is coming

In the next weeks I aim to add some fluent API features to Jericho Selector, similar to jQuery, so you can make some operations using lambdas, for example. Methods like closest, parentsUntil, find, each are my priorities.

Another point to improve is the performance. Specific selectors can be optimized using cache or specific Jericho HTML Parser methods like getAllElementsByClass.

What you can do

Report any problem and suggest new features!

Souce code

You can get check out the source code from GitHub account:

https://github.com/utluiz/jericho-selector/

Jericho Selector, ou jQuery para Java

CSS3

É com grande satisfação que venho anunciar a publicação da primeira versão estável (stable release) da biblioteca Jericho Selector.

O Jericho Selector é uma extensão para a conhecida biblioteca de leitura e manipulação de HTML Jericho HTML Parser que permite selecionar elementos de um documento HTML ao estilo do jQuery, ou seja, utilizando seletores CSS.

Por quê Jericho? Diferente do jsoup, por exemplo, ele permite alterar documents HTML mantendo a formatação original. Outras bibliotecas reescrevem o documento inteiro. De qualquer forma, eu gosto de ter opções! 😉

Jericho Selector é totalmente livre, sob a licença MIT.

Como usar

O Jericho Selector está disponível no Repositório Central do Maven, então basta configurar o seu projeto com a seguinte dependência:

<dependency>
    <groupId>br.com.starcode.jerichoselector</groupId>
    <artifactId>jericho-selector</artifactId>
    <version>1.0.1-RELEASE</version>
</dependency>

Depois, faça a importação do método estático $ que pode ser usado como ponto de entrada para uso do Jericho Selector:

import static br.com.starcode.jerichoselector.jerQuery.$;

Então você poderá realizar consultas da seguinte forma:

$(html, "p.my-text")

O que foi feito

Antes de iniciar a implementação do Jericho Selector, tive que implementar um interpretador (parser) completo de seletores CSS. Para isso, implementei outra biblioteca que chamei de parCCSer. Ela foi baseada na especificação oficial do W3C para CSS3 e cobre praticamente todos os aspectos da especificação, exceto alguns detalhes que se aplicariam apenas no contexto de um navegador e também algo relacionado a suporte de caracteres UTF-8. Ela também está sob a licença MIT.

O Jericho Selector então utiliza a árvore de objetos gerada pelo parCCser, assim como a API do Jericho HTML Parser para consultar os elementos de um documento HTML com base em um dado seletor.

Todas as implementações possuem cobertura em testes unitários de mais de 90% do código, sem contar os casos excepcionais que o plugin de cobertura não consegue analisar.

O que precisa ser feito

Nas próximas semanas pretendo adicionar ao Jericho Selector funcionalidades de uma API fluente, análogas ao jQuery, para que seja possível realizar operações com os elementos recuperados usando lambdas e outros recursos. Métodos como closest, parentsUntil, find, each são meus primeiros alvos.

Outro ponto a melhorar é o desempenho da biblioteca. Alguns seletores específicos podem ter sua execução otimizada utilizando cache ou métodos específicos do Jericho HTML Parser como getAllElementsByClass.

O que você pode fazer

Reporte qualquer problema e sugira novas funcionalidades!

Código-fonte

Confira o código e maiores detalhes na minha página do GitHub:

https://github.com/utluiz/jericho-selector/

Página 4 de 16

Creative Commons O blog State of the Art de Luiz Ricardo é licenciado sob uma Licença Creative Commons. Copie, compartihe e modifique, apenas cite a fonte.