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().
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.
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.
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. 🙂
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.
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:
- 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.
- Gravar o texto “ABC” no arquivo “doc.txt”
- 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.
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:
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.
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.
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.
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.
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.
É 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:
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.
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.
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.
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.
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.
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.
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:
Você deve ter pego a ideia. 😉
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.
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.
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.
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:
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.
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. 😀
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.
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”.
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ê.
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.
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.
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.
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.
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.
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.
Durante o bate-papo, você também pode e deve fazer perguntas. Algumas que eu faria são:
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.
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.
À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.
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:
É 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.
É 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.
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! 😀
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.
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)
);
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)
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)
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:
SP_SQLEXEC deve ser do tipo NVARCHAR.
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.
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…).
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?
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.
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.
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.
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.
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.
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!
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.
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?
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:
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.
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.
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.
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.
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.
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.
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.
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")
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.
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.
Report any problem and suggest new features!
You can get check out the source code from GitHub account:
É 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.
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")
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.
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.
Reporte qualquer problema e sugira novas funcionalidades!
Confira o código e maiores detalhes na minha página do GitHub:
Acompanhe minhas respostas no Stack Overflow em Português.
O blog State of the Art de Luiz Ricardo é licenciado sob uma Licença Creative Commons. Copie, compartihe e modifique, apenas cite a fonte.