Dicas de Recrutamento
Realizo várias entrevistas na ília digital e faço diversas delas com um cara chamado Bruno Almeida.
No começo do ano eu havia criado uma série no Linkedin sobre algumas dicas que passo para todos os candidatos.
Mas acabei vendo que o Linkedin é meio confuso quando tratamos disso como hashtags.
Brunão ficava me falando para criar um artigo para facilitar o acesso a esses pontos, e mandou o famoso se tu não fizer vou escrever e falar que foi eu :).
Vamos então deixar o Bruno sem ter o que postar.
Introdução
Em tempos de confinamento tenho visto muitas pessoas postando códigos semelhantes ao NuBank ou APIs em frameworks como Spring Boot ou ExpressJS com o objetivo de chamar a atenção de recrutadores.
Na ília digital realizo uma série de correções de provas de novos candidatos relacionados a JVM, seja JakartaEE, Java, Spring Framework, Kotlin Gradle, Maven e gostaria de compartilhar com vocês alguns critérios que uso para essa análise.
Um ponto importante a se atentar em épocas como essa em que a demanda aumenta e a oferta diminui, é o como você consegue se diferenciar como candidato, porque fazer uma API com o Spring Framework não é muito diferencial já que existe o Initializr.
Postarei uma série de pontos que analiso nos códigos que recebo, eu falo para cada candidato que vou analisar arquivo por arquivo… geralmente eles não acreditam
Não que eu possa dizer que seguindo essas dicas você terá uma vaga garantida aonde você se candidatar, a ideia é trazer pontos para você melhorar seu código.
Não vou ficar digitando uma dica por dia também, porque muitas das dicas já irei escrevendo
Se você tiver outra dica, pode responder nos comentários
Dica 1: Versione seu código
Na ília digital utilizamos a prática de avaliar os projetos que recebemos como se fosse um Code Review de um projeto real
Versionar seu código em ferramentas como github.com/ ou https://about.gitlab.com/ ajudam muito na análise.
Pode parecer pouca coisa, mas receber um código como zip já te dá um ponto a menos, pois o Git já se tornou um skill tipo o Pacote Oficce há um tempo atrás (acabei de entregar a minha idade, mas há um tempo atrás todos colocavam o Office como skill em currículos).
O Git já foi diferencial, hoje já é um pré-requisito
Dica 2: Utilize o .gitignore
Ainda é comum recebermos projetos em que a pessoa não utiliza o .gitignore
Quando vamos abrir o projeto em uma IDE como IntelliJ, Eclipse ou VSCode é comum aparecer várias pastas para que adicionemos ao versionamento. Pior ainda é aparecer aquele arquivo .DS_Store maroto que a galera do Mac se amarra.
Um bom site para a criação de arquivo .gitignore é o famosíssimo, salve, salve http://gitignore.io/
Basta você digitar a sua stack de desenvolvimento e ele já gera um para você… você pode inclusive adicionar mais de um template
Dica 3: README
Outro dia desses vi esse sensassional post da Diana Regina
Como desenvolvedor de backend e de integrações na ília digital posso falar que já trabalhei com Java, Kotlin Spring Boot, Maven, Gradle, SOA, Oracle SOA Suite, IBM Integration BUS, AWS, Heroku e outras coisas. Não é que nós que estamos avaliando o projeto não saibamos que o comando bootRun ou spring-boot:run executam o Spring Boot no Gradle e Maven, o ponto que estamos avaliando é caso você seja contratado como os outros desenvolvedores do time lidam com o seu código.
Lembre-se que em times multidisciplinares é comum várias pessoas com conhecimentos diferentes trabalhando no mesmo projeto. Caso seu colega não saiba subir o seu projeto ou debugar ele em uma IDE isso dificulta muito as coisas.
Um exemplo que fizemos na ília digital foi trabalhar com Kotlin e Gradle no Android e no backend com Spring Framework. Com isso, nossos desenvolvedores Mobile conseguiam ajudar ao time de backend em Pull Request e Code Review dado que usávamos quase a mesma stack, inclusive JUnit, ficando apenas como diferença o Spring Framework.
Segue outra fonte de Awesome READMEs:
Dica 4: variáveis no gerenciador de build e dependências — Maven
Essa dica vou conseguir ser mais assertivo no Gradle ou Maven nos exemplos, mas vocês podem abstrair para outras linguagens.
A época de versionar dependências nos projetos já passou, hoje, todo mundo utiliza algo como pom.xml ou build.gradle para isso.
Mais importante que só usá-los, é você usar os recursos que eles tem, por exemplo, no Maven:
Quer usar o Swagger adiciona essa linha aqui na tag properties:
<springfox.swagger2.version>2.9.2</springfox.swagger2.version>Após isso, adicione a versão na dependência assim:
${springfox.swagger2.version}Dependências tendem a crescer muito e isso te ajuda a alterar uma sem precisar descer várias linhas de código. Isso é um problema que acho no Maven quando o projeto evolui e possui muitos reports, dependências e plugins
Quer usar uma dependência no Maven que está na sua máquina? adicione isso no properties
<sonar.host.url>${env.SONARQUBE_HOST}</sonar.host.url>Sobre o SonarQube falarei em outro post
Dica 5: variáveis no gerenciador de build e dependências — Gradle
Essa dica vou conseguir ser mais assertivo no Gradle ou Maven nos exemplos, mas vocês podem abstrair para outras linguagens.
A época de versionar dependências nos projetos já passou, hoje, todo mundo utiliza algo como pom.xml ou build.gradle para isso.
Mais importante que só usá-los, é você usar os recursos que eles tem, por exemplo, no maven:
Quer usar o Swagger adiciona essa linha no seu ext no build.gradle: springFoxVersion = “2.9.2”
Após isso, adicione a versão na dependência assim:
implementation “io.springfox:springfox-swagger2:$springFoxVersion”Uma dica fera sobre o Gradle é que ele é escrito em Groovy ou Kotlin, isso te permite fazer algo assim também:
springFoxArtifacts = [‘springfox-swagger2’,’springfox-swagger-ui’]
springFoxArtifacts.each {
a -> implementation “io.springfox:$a:$springFoxVersion”
}
E seus imports ficam bem menores para aquelas várias dependências de um mesmo grupo na mesma versão
Quer usar uma variável no Gradle que está na sua máquina? adicione isso
System.getenv(‘SONARQUBE_LOGIN’)Sobre o SonarQube falarei em outro post
Quer mais dicas de Gradle, já que é pouco difundido? https://gradle.com/training/
Dica 6: Wrapper
Você sabia que para testar seu projeto outros desenvolvedores não precisam baixar algumas coisas?
No caso do Spring Boot acho muito legal a abordagem com os Wrappers gradlew e gradlew.bat em Gradle e mvnw e mvnw.cmd no Maven. Esses arquivos executam os arquivos contidos nas pastas gradle/wrapper e .mvn/wrapper. Não precisa ignorar esses arquivos no .gitignore.
Você pode rodar esses comandos em Sistemas Unix ou Windows como se você estivesse usando o próprio Gradle ou Maven, a diferença é que você não precisa baixar nada, nem configurar variáveis de ambiente. ./gradlew bootRun no Gradle ou ./mvnw spring-boot:run no Maven
Nota mental, acho muito estranho esses arquivos e pastas .algumacoisa que podem ser versionados… para mim tinha que ter uma convenção, “começou com ponto”, gitignore, mas isso é outra discussão.
Ficou curioso com wrappers, mas mesmo assim quer instalar o Java, Scala, Kotlin, Maven, Gradle e outras muitas coisas na máquina?
Passei muito tempo da minha vida sem esse cara, hoje não mais. Para ver a lista de SDKs que ele possui https://sdkman.io/sdks
O SDKMan me ajuda a abstrair a questão de configuração de variáveis de ambiente e trocas de versão de Java da 8 para 11, por exemplo
Dica 7: Testes
Essa eu acho que é uma dica que muitos candidatos esquecem quando vão fazer provas na ília digital.
O problema não é você falar que sabe fazer microservices com Spring Cloud e nos enviar 7 projetos separados. O problema é o único arquivo de testes ser o default do https://start.spring.io/
Testes não são uma opção hoje em dia, e dica: Você não entrega mais rápido sem eles, vai por mim.
Geralmente o pessoal esquece que o tempo em que as coisas voltam antes de entrar em produção conta como tempo de desenvolvimento, ai vem com essa “máxima” que TDD (Testes Depois do Deploy ahahahahaaaaahha just a joke) é mais rápido.
Também não estou defendendo o TDD, mas isso é outra discussão :)
Meu ponto também não é que você cubra 100% do seu código, mas novamente, isso é como eu penso, mas que você comece a fazer e cobrir classes de forma unitária de camadas como service por exemplo, onde estão as regras de negócio
Para isso, use Mocks.
Nas provas de backend AIS não pedimos que a pessoa faça um sistema em 3 dias, pode ser só uma funcionalidade, mas testes não são mais um diferencial
Dica 8: Mais testes
Terminou os testes unitários, quer escrever alguns outros e se diferenciar? Show
Que tal dar uma olhada nesses dois caras aqui?
O ArchUnit consegue testar suas camadas, por exemplo: minha controler não pode chamar classes repositories ou minha service tem que estar no package services.impl
Já o TestContainers consegue subir um container com seu banco preferido ou módulos em Kafka, RabbitMQ dentre outras coisas feras
Dica 9: Apague o que não precisa
Uma coisa é esquecer de ignorar as coisas no projeto com o .gitignore, Dica 2, outra coisa é você versionar aquele teste default que você não usa ou pior, enviar aquela classe fera, o famoso HelloWorldController
Se o desafio que você recebeu não é para fazer um Hello World, não precisa versionar essas coisas para enviar para o avaliador
Como diria aquela frase: um desenvolvedor escreve código, um bom desenvolvedor refatora código, um excelente desenvolvedor apaga código que não precisa
Dica 10: Cuidado ao copiar código
Não me entenda mal, não estou falando que você não pode ter seus projetos base e tornar mais fácil enviar isso para um avaliador, eu mesmo tenho os meus projetos de teste que me ajudam na evolução da stack na ília digital.
Agora, se tu vai mandar seu código para um avaliador, lembre-se de escolher um projeto que encaixe bem no problema.
O enunciado diz faça uma API REST e aparece um sistema mais complexo de manutenção e solução do problema pode ser um ponto contrário a você, porque o avaliador vai te perguntar o porque escolheu aquela solução
Outra dica, cuidado com as coisas escritas, algumas pessoas pegam código de outras e é comum ver classes com outros autores no JavaDoc ou mensagens no properties como:
“Erro na intranet, entre em contato com o administrador do seu departamento pelo ramal …”
Dica 11: Restful
REST já deixou de ser diferencial também. Quando você diz que sabe fazer uma API REST, o que o avaliador está analisando é se você entende isso aqui:
REST, ágil e microservices já se tornaram buzzwords! Não me entenda mal, acredito em cada uma delas em seus contextos, o ponto é que como todo mundo diz que faz, a questão é saber como fazem para não se tornar algo subjetivo e ficarmos naquela discussão: “mas o que é certo para você não é certo para mim” ou “mas o que você chama de microservices não é microservices para mim”. Se você ouve a pessoa falando que sabe REST com microservices porque fez um projeto Spring Boot ou ExpressJS, corre que é “bilada cino”.
Para isso, precisamos de uma fonte objetiva, e no caso do REST temos inclusive uma dissertação
Lembre-se: REST não é SOAP isso te ajuda na modelagem de suas APIs
Lembre-se: não use verbos como “cadastrar” ou “alterar” no path
Dica 12: Restful HTTP Status
Uma dica bem simples de ser implementada é a utilização de HTTP Status. Algumas pessoas esquecem disso e quando todas as rotas retornam 200.
Uma boa dica de como aprender isso, e que me ajuda sempre é esse site aqui
Meu amigo Fabio Felippi, que gosta mais de gatos, me mandou esse:
O mais importante é saber que um POST deveria retornar um 201 e não um 200 se formos seguir as boas práticas, que erros de regras de negócio não deveriam retornar 500
Imagina… em mando um CPF errado e o sistema me retorna 500… já penso, caramba, derrubei o servidor do cara só com um campo errado
Dica 13: Profiles
Caso você siga as dicas do https://12factor.net/ sabe que é uma boa prática separar as configurações por ambiente https://12factor.net/config
Mas mesmo que você crie arquivos como application.properties, application-dev.properties, application-hml.properties e application-prd.properties se lembre de utilizar variáveis para não versionar suas credenciais.
No Spring Boot é bem tranquilo fazer isso mais ou menos assim spring.datasource.username=${DATASOURCE_USERNAME}
O que acontece é que alguns candidato sobem os códigos no https://www.heroku.com/ ou outro provedor de cloud, ponto positivo para vocês, mas esquecem de não versionar essas credenciais, ponto negativo para vocês.
Não que eu faça isso, mas creio que você todos conhecem aquela história do Facebook do cara que foi pedir ajuda para alterar uma coluna no MySQL e passou todas as credenciais, e depois “agradeceu” o pessoal por ter dropado todas as tabelas deles.
Também não estou encorajado os “hackudões”, só estou mostrando a vulnerabilidade que isso pode acarretar
Se o seu projeto está no GitHub, lembre-se disso aqui:
Dica 14: Mappers
Uma boa dica ao se trabalhar com APIs é separar seu modelo de API do seu modelo de persistência. Isso evita a necessidade de anotar uns ignore nas suas entidades para não ir para a API e coisas do tipo, te deixando desacoplado em evoluções de API e evoluções de persistência.
Em soluções que usam a JVM isso pode te trazer uma dificuldade para mapear essas novas entidades… até hoje…
Apresento a vocês o fantástico https://mapstruct.org/ que com uma interface faz quase todo o trabalho para você, ao menos nos cenários mais corriqueiros. Ele gera essas classes em tempo de compilação, o que pode ser avaliado quando comparado com outros caras como https://orika-mapper.github.io/orika-docs/ e outros
Dica 15: Lint (checktyle findbugs pmd spotbugs )
Seu projeto está bonitão, mas que tal você mostrar para o entrevistador que ele não possui más práticas?
Coisas que analisamos na ília digital são magic numbers, complexidade de método, variáveis com nomes estranhos e outras coisas, mas às vezes, uma ou outra coisa pode passar.
Que tal então você trazer para o seu código uma certificadora que ateste isso?
Plugins como https://checkstyle.sourceforge.io / ou https://spotbugs.github.io/ (substituto do FindBugs) e https://pmd.github.io/ te ajudam nisso, e melhoram a chance do entrevistador te dar mais pontos.
Essa dica foi mencionada pelo Anderson Fonseca e mais tarde escrevo a parte 2 dela, de como você pode subir um SonarQube na sua máquina para fazer isso também
Dica 16: SonarQube
Quer impressionar ainda mais o recrutador? Adicione uma pasta no seu projeto com um arquivo como esse: Descreva no seu README, Dica 3: README, como subir um docker-compose com comandos como:
docker-compose -f sonarqube-h2.yml up ou docker-compose -f sonarqube-h2.yml up -d (caso você não queira ver os logs), e derrube a aplicação com docker-compose -f sonarqube-h2.yml down
Configure o SonarQube no Maven ou Gradle. Aponte para o host http://localhost:9000/, o usuário e senha default é admin
A imagem está usando a versão 8.3.1 e você pode inclusive adicionar outros plugins e fazer testes, como por exemplo: você sabia que dá para rodar SonarQube em Salesforce?
Trabalhando em um projeto na ília digital descobri que dá para fazer CI, CD e outras coisas do processo de DevOps
Dica 17: Microservices é buzzword
Como dito anteriormente, não estou questionando microservice só falando que aquilo que a galera tanto reclamou de SOA estão fazendo a mesma coisa com microservice. Parece que o jogo virou, não é mesmo?
Deixa eu explicar melhor, é comum as pessoas falarem de microservice e confundirem isso com um framework, como Spring Boot ou ExpressJS.
Você não vai ter SOA com um ESB instalado, você não vai ter microservice com Spring Framework e você não vai ter DevOps com Jenkins somente! (Polêmica, mas explico os outros pontos em outras dicas)
O ponto é que como a palavra ficou tão batida, a pergunta certa nas entrevistas não é se você sabe microservice, mas como você FAZ microservice.
Dica de ouro, microservice sem testes não existe, então, volte a essas dicas aqui: Dica 7: Testes e Dica 8: Mais testes
Uma fonte muito boa de entender os pormenores, e sem sobra de dúvidas a melhor que eu vi para Spring Cloud foi esse material do Alexandre Aquiles
Você que não gosta de JVM, Java ou Spring Framework, deixe esse seu rancor de lado e atente-se aos princípios de fault tolerance, load balancing, testes, api gateway e outros que também estão muito bem descritos na apostila
Dica 18: DevOps não é Jenkins
Muitas pessoas olham alguns termos como agile ou Scrum e acreditam que instalando o Jira resolveram o problema.
O mesmo acontece com DevOps, DevSecOps, DevBlablaOps, NoDevYesSecSbrabausOps apresentado em alguns artigos
Como em Microservices, estou apenas questionando o que essas palavras se tornaram. cultura é a palavra chave para DevOps, não uma ferramenta qualquer.
Querer “trabalhar com DevOps” e falar para o seu time que você tem tolerância zero a erros, não combina. Os erros são importantes para o aprendizado e constantes aprimoramentos.
Diferente dos posts anteriores, vou continuar em comentários cada instituição que me ajudou e ajuda nessas partes, porque os posts no Linkedin tem um limite de caracteres
Lembre-se também, quando falamos em git, Pull Request, Code Review, gitflow, SonarQube, build, Nexus, DevOps e monitoramento, isso é uma base… existe uma grande chance da sua pipeline ter suas peculiaridades como essa:
Cada desafio vai demandar suas peculiaridades, mas não se esqueça que tecnologia não resolve as coisas sem o negocio e a cultura
Dica 19: Ágil é buzzword
O agile entrou no mesmo rol de palavras de microservices, restful e DevOps, não basta apenas perguntar se a pessoa faz, porque todo mundo diz que faz.
Não me lembro de muitas reuniões em que o candidato não disse que seguia uma ou outra reunião, mas quando algumas perguntas vão sendo feitas, você vai descobrindo coisas tipo o “Scrum tradicional”, não conhece?
“A gente faz o “Scrum tradicional”, nossas dailies demoram 2h, sem retrospectiva”
Atenha-se aos princípios, depois, critique os princípios e melhore.
Para mim é como a galera que diz que vai matar o Java porque ele é legado, e se esquece que a linguagem de hoje vai ser o legado de amanhã.
Mesmo o ágil merece suas críticas, e com certeza daqui a pouco teremos outras coisas para resolverem novos problemas… assim são as coisas… não existe bala de prata, a ideia é ir se adaptando.
Vocês sabiam por exemplo que existe uma galera adotando ausência de estimativas e outras coisas?
O ponto não é fazer como o meu amigo Edinho Moreira disse e seguir o HDD (Hype Driven Development), mas entender as premissas, o que elas ajudam e quando
Dica 20: na minha empresa sou Júnior, Pleno e Sênior
Quando vamos avaliar currículos de pessoa na ília digital sabemos da disparidade de senioridade entre as empresas.
Acontece que em muitos casos, uma pessoa Sênior para uma empresa não é Sênior para outra.
O que avaliamos é basicamente o quanto uma pessoa se conhece de alguns pontos e quanto seria simples evoluí-la em outros.
Por exemplo, pessoas sêniors são cobradas em seus códigos de terem escrito testes, saberem utilizar REST e coisas do tipo. Pessoas Jrs também, mas não com um mesmo rigor de um Jr modelar uma entidade com mais complexidade do que deveria, por exemplo.
Também nos conectamos aos candidatos para realizar o Code Review, a fim de dar um feedback para a pessoa dos pontos que avaliamos.
Nada pior do que fazer uma prova e ficar com aquela dúvida se você foi bem ou não.
Entendemos que a nível de processo existem n situações que podem ocorrer como vagas congelarem ou não existir urgência, porém, a nível de código, um Code Review ajuda a mostrar os pontos de melhoria da pessoa
Dica 21: conheça a empresa a qual você está se candidatando. Não se limite a sua região
Em BSB há uma alta demanda por manutenção em sistemas legados, nada contra, é uma demanda.
Porém, no caso da ília digital, não temos nenhum projeto com JSF, Struts ou JSP — galera do Java, a gente já perdeu essa há algum tempo :(…
Galera do JavaScript vocês fazem isso bem melhor s2s2
Algumas pessoas vem para entrevistas e quando questionadas sobre inovação falam que trabalhariam com o Java 8.
Já estamos chegando no Java 15… a minha dica então, é você não se limitar à sua região como balizador da sua evolução de stack.
Geralmente utilizo São Paulo, Curitiba, Recife como exponentes de inovação por termos empresas como a ThoughtWorks, Sciensa, Sensedia, Movile outras como Red Hat, IBM para me ajudarem a ver isso.
Além disso, TDCs estão espalhados por todo o país assim como meetups.
Além disso, geralmente analiso os empregos no https://stackoverflow.com/jobs ou no próprio Linkedin para saber como está o mercado. Crio tags para ser notificado de vagas com uma dada skill e analiso o que mais pedem
Na ília digital trabalhamos com vários clientes internacionais, segmentados em verticais, o que me ajuda também a ver que Cloud já não é mais inovação
Dica 22: Cuidado com quanto tempo você pode trocar de empresa
Não me entenda mal… não acredito que as pessoas são parte do domínio de uma empresa e devem lealdade a ela o resto da vida… nem com linguagens de programação acredito nisso… a galera vira muito fã boy e não critica o que a sua linguagem faz de ruim… enfim…
Acho que as pessoas são livres para trocarem de empresa quando quiserem… a minha dica é mais sobre uma outra óptica.
Imagina eu te entrevistando, não te conheço direito, ai te pergunto: quando tu poderia vir trabalhar conosco e tu fala hoje ainda.
Por não te conhecer, a primeira coisa que passa na minha cabeça é: poxa… será que esse cara não está em uma entrega de sprint? Será que ele não precisaria repassar algo para o time? E o mais importante, o que garante que ele não vai fazer o mesmo quando receber outra proposta conosco?
Não me entenda mal, não quero que você morra na minha empresa… quero que você evolua o máximo, seja trabalhando para fora de Brasília ou do Brasil. Várias pessoas que passaram pela AIS estão na Suécia, Canadá, Portugal e outros lugares. Pessoas que eu tenho o máximo respeito! Mas que foram honestas com o time e não nos deixaram na mão
Dica 23: Brasília é pequena demais para tu arrumar treta com outras empresas
Essa é para a galera de BSB… todo mundo aqui se conhece… não vale muito a pena você querer sair de uma empresa dando voadora em todo mundo
Ainda que tu esteja certo… as pessoas conversam… nem sempre tu vai ter a chance de explicar o outro lado
Sendo assim… seja o mais profissional possível… não vou falar que isso é fácil, mas na medida do possível, deixe portas abertas
Dica 24: Você tem problemas com as pessoas, você não é a madre Tereza
Em algumas entrevistas perguntamos se a pessoa tem alguma dificuldade em trabalhar com algum tipo de pessoas.
Estou falando isso sobre a perspectiva minha e da minha empresa, não achem que isso é uma máxima, blz?
Ai a pessoa fala que não.
Mano… eu discordo de uma série de coisas que os meus pais falam ahahahahahahah tenho divergências com outras pessoas do meu time… isso é normal :)
O que a gente está querendo saber é como você lida com isso, porque sempre vão haver situações em que vão haver conflitos.
Intermediar e lidar com isso é normal. Errar também é… às vezes nos estressamos com uma situação envolvendo pessoas… o mais importante é aprender com isso e ter uma lição
Dica 25: Ainda sobre versionamento
Que tal então melhor ainda mais seu versionamento de código?
Pessoas como o Leandro Alves e o Touré Holder me mostraram o maravilhoso
Eu consigo fazer meus commits serem mais assertivos. A ideia é que uma pessoa pelo emoji tenha ideia do que o commit se propõe a fazer, para não precisar clicar em commit por commit para analisar
Já usa ele? E que tal os changelogs? Experimente o
A proposta é ter um commit por ação, para não ficar naqueles commits que alteram tudo no projeto e tu já nem controla mais isso depois
Ah… não se esqueça que squash e rebase no git combinam muito com essa abordagem
Dica 26: Shields
Sabia que teu repositório pode ficar bem interessante tendo informações como quantidade de commits, versão de algumas bibliotecas, cobertura, qualidade de código, segurança e outros?
Sabe aquele esqueminha que tu abre em alguns repositórios e não sabe como eles mostram? “Seus problemas se acabaram-se, agora com équio” (entregando a idade de novo)
Experimente integrações como se o seu build quebrou, issues abertas, a linguagem que você usa
Dica 27: Integrações
Sabia que várias ferramentas te oferecem um acesso gratuito desde que o seu código seja Open Source?
Que tal utilizar o https://snyk.io por exemplo para ver a segurança das dependências do seu projeto?
Ou criar pipelines com o https://circleci.com?
E essa, que faz Pull Request quando uma das versões do seu projeto evolui?
Enfim… tem caras muito feras querendo ajudar vocês a fazerem projetos muito feras
Dica 28: Hard Skills são importantes, mas Soft Skills também
Já entrevistei várias pessoas que apresentam códigos interessantes, mas que tem dificuldade em mostrar isso para os outros
Novamente… não dá para conhecer uma pessoa em uma entrevista… não estou pedindo que você seja o influenciador do instagram, só que saiba expor seus pontos.
Entrevistei um cara essa semana para uma vaga de Júnior. O que mais me chamou atenção na postura dele foi que quando fazíamos perguntas para ele, ele ouvia, buscava uma base de conhecimento do que ele já havia vivenciado em sua mente, formulava uma resposta, e então respondia.
Isso demonstra uma postura muito fera, e ele havia começado a entrevista dizendo que era tímido.
Bom… o que as pessoas às vezes não sabem, é que eu também sou… em meu primeiro emprego, por exemplo, eu nem olhava nos olhos das pessoas, mas são coisas que você vai aprendendo e se adaptando
Dica 29: Quem é você
Na ília digital sabemos que uma profissão ou aptidão técnica não definem uma pessoa.
Caso vocês encontrem outro Arthur que goste de JVM, pode ser que não seja eu :)
Então, quem sou eu? Bom… a parte técnica é uma das minhas facetas de um espectro bem vasto, mas eu sou também o cara cristão que gosta de metalcore, Lovecraft, Dostoiévski, corinthiano que gosta de mangás e HQs, que gosta de jogos de tabuleiro, que já dançou tango… enfim… falar tudo de uma vez, talvez me ajude a me conectar com alguns de vocês em alguns pontos… esse é o objetivo da pergunta, porque afinal de contas, nós somos mais do que a linguagem que programamos :)
Dica 30: Você não está concorrendo sozinho
Algumas pessoas podem pensar que isso é um script ou roteiro, que é só seguir e estão contratadas.
Entrevistas de emprego são diferentes de provas do colégio em que se todos tirasse 10 estava ótimo
As pessoas se esquecem que tem outras pessoas concorrendo para a mesma vaga, e que não existem pessoas iguais
Sendo assim, se prepare, tenha exemplos de templates de código para usar facilmente de exemplo
Saiba quem são suas referências nas áreas, e mostre isso para as pessoas. Mostre seus conhecimentos e mostre também suas limitações.
Novamente, falo isso pelas entrevistas que eu faço na ília digital, não por todas as empresas, mas em uma entrevista em que perguntei para um candidato sobre DevOps ele me falou isso eu entendo mais ou menos assim, mas nunca implementei um monitoramento de Microservices. Isso mostra que estou conversando com uma pessoa e não com alguém que quer sempre ter a resposta para tudo, isso me diferencia a pessoa de outras. Isso é transparência
Dica 31: Qual o sentido de explicar como você avalia as provas de backend?
“Kaiba, você acaba de cair na minha carta armadilha”
No final das contas, o ponto sempre foi deixar claro que a disputa em uma entrevista é entre as pessoas entrevistadas.
Se 30 pessoas fizerem a mesma coisa para a mesma prova, elas voltarão ao problema de não se diferenciarem. A dica é explorem novos cenários e se diferenciem
Existem exceções… Já entrevistei pessoas que não poderiam me encaminhar o código dado entregas e coisas do tipo, nesse caso, converso melhor com ela sobre questões envolvendo DevOps e pergunto como ela evoluiria um cenário real, afinal de contas, não conheço uma pipeline perfeita… sempre tem espaço para evoluções, como a análise de dependências em pipelines com o OWASP Dependency Checker ou processos manuais que necessitem de aprovação de POs, enfim…
A pessoa precisa saber que como não verei o seu código, tenho que ter certeza de que ela sabe do que está falando.
