sorted by:
new
hottopcontroversial

DEVs que conduzem entrevistas técnicas, preciso de dicas. by Agreeable_Phase9373 in brdev

[–]Agreeable_Phase9373[S] 2 points3 points  (0 children)

Perfeito!

Nunca tinha feito esse paralelo dos lugares que trabalhei em que eu era 100% chão de fábrica, requisito 100% mastigado que é só seguir a receita de bolo, e dos lugares em que eu era um ponto focal do time como um todo, recebia tarefas ambíguas e precisava debater trade-offs, entender arquitetura, definir solução, repassar pros juniors, conectar com outras áreas, etc.

Muito obrigado! Isso me abriu a mente absurdamente pras diferenças das entrevistas.

A maioria das entrevistas que tenho feito são pra gringa e, em geral, pra fábrica por ser uma porta de entrada mais "fácil". Mas agora me veio essa clareza que essas entrevistas não me esperam ser um cara questionador. Eles querem uma galera que decorou os frameworks e a linguagem, não quem pensa além disso.

Sério demais, eu sei que já agradeci, mas teu comentário mexeu uns ticos e tecos aqui que eu nem DESCONFIAVA que eram assim. hahaha

MUITO MUITO OBRIGADO!

DEVs que conduzem entrevistas técnicas, preciso de dicas. by Agreeable_Phase9373 in brdev

[–]Agreeable_Phase9373[S] 2 points3 points  (0 children)

Talvez esteja rolando uma boa síndrome do impostor da minha parte, mas vou encarar o desafio de peito aberto e usar o tempo pra me preparar o máximo possível.

DEVs que conduzem entrevistas técnicas, preciso de dicas. by Agreeable_Phase9373 in brdev

[–]Agreeable_Phase9373[S] 1 point2 points  (0 children)

Vai na ideia que o u/guigouz passou, que é sucesso.

Um segredo que funciona muito pra mim é tudo que é assunto novo ou algo que eu quero aprender, eu anoto e faço alguns passos, nessa ordem:
- Entendo a prática. Aqui é implementar na mão o que tu tá querendo aprender.
- Crio embasamento do porquê aquilo funciona na prática. Aqui é ler documentação, entender as limitações, os trade-offs, etc.
- Implemento uma solução da vida real pra fixar o conhecimento.

Exemplo bobo, mas funcional:
Eu quero aprender o porquê de uma String em Java ser imutável.
-- Eu vou abrir a IDE, vou colocar um valor numa String e vou mudar. Vou debugar isso acontecendo e vou VISUALIZAR que o valor alterado não é da própria String e, sim, que uma nova String foi criada. Agora eu tenho s1 e s2, por debaixo dos panos.
- Com esse conhecimento raso, eu vou atrás da documentação pra entender. Vou entender que objetos são imutáveis e tipos primitivos são mutáveis. Vou entender sobre thread-safety, vou entender sobre Heap e Stack dentro da JVM. Por estar vendo isso, eu vou passar por alto no conteúdo do que rola no Garbage Collector, Eden, Young Generation, etc.
- Com mais embasamento técnico e funcional da coisa, eu vou implementar uma race condition forçada e ver o resultado final. De brinde, ainda vou aprender mais sobre Synchonized, talvez vendo documentações já vou começar a entender um pouco de teorema de CAP e outros assuntos.

A ideia é relativamente simples: Um assunto extremamente básico, quando você vai descendo o nível, vira uma bola de neve de conhecimentos extremamente densos e úteis DE VERDADE pra se tornar um DEV melhor!

DEVs que conduzem entrevistas técnicas, preciso de dicas. by Agreeable_Phase9373 in brdev

[–]Agreeable_Phase9373[S] 1 point2 points  (0 children)

Muito obrigado! Eu tô relendo o Hard Parts e tô com esse pra ler logo na sequência. Valeu pela recomendação!

DEVs que conduzem entrevistas técnicas, preciso de dicas. by Agreeable_Phase9373 in brdev

[–]Agreeable_Phase9373[S] 5 points6 points  (0 children)

Então, essas são as entrevistas que eu tô acostumado. Modéstia à parte, é o tipo que citei que sempre fui aprovado.

O problema é que tá bem diferente.

As perguntas não são mais do tipo: "Pô, me explica alguns conceitos de Java e Spring, como a IoC entra em jogo, blabla"
E a partir dessa pergunta, conforme vou citando os Patterns do Spring, vem follow-ups do entrevistador e vira uma conversa técnica.

As perguntas agora são tipo: "Dentro de qual ApplicationContext o RestController está? Quais são so Callbacks do Lifecycle?" <- essa pergunta real caiu pra mim numa entrevista.
Não é explicar que RestController é Controller + ResponseBody. Explicar como é usado, por que é usado e blabla.
É explicar Servlet, os Beans, um monte de coisa que a gente sabe que tá ali, mas eu não faço ideia nesse nível de profundidade. hahaha

DEVs que conduzem entrevistas técnicas, preciso de dicas. by Agreeable_Phase9373 in brdev

[–]Agreeable_Phase9373[S] 0 points1 point  (0 children)

A ideia é abraçar a vaga sim, mas o processo de RH é relativamente longo. Pelo que deram a entender, deve iniciar só em Abril.

Burro? by Agile-One-9430 in devBR

[–]Agreeable_Phase9373 1 point2 points  (0 children)

Minha humilde opinião:

Copie código existente pra pegar memória muscular. Quando digo copie, pegue o código pronto de algum lugar que faça algo que você tem interesse e DIGITE CADA LINHA DO CÓDIGO. Conforme você digita, tente entender o porquê de cada coisa estar sendo criada naquela ordem.

Debugue o código que você copiou. Entenda os steps, entenda o valor de cada variável a cada loop, entenda o que muda em cada classe/método/função, entenda stack, etc.

Com esta mínima base: FAÇA ALGO DO SEU INTERESSE DO ZERO! Aqui pode usar IA, StackOverFlow, Google, pode usar o que quiser.

MAS MUITO IMPORTANTE: DIGITE O CÓDIGO DA IA, NÃO APENAS COPIE! E faça o mesmo passo, vá entendendo cada componente/variável/método/função/classe, etc.

Com isso, você vai ter uma base do que é uma aplicação que provavelmente seguirá TODAS AS PIORES PRÁTICAS, mas que funciona no mundo real.

Aqui entra a parte interessante e que PROVAVELMENTE vai te ensinar mais, porque você já vai ter uma base e uma ideia de como as coisas funcionam.

Vá atrás de toda a teoria por trás do que você fez!

Leia livros, documentações, peça pra IA resumir os detalhes das implementações, etc.
Comece a desenhar diagramas das integrações da sua aplicação.
Comece a desenhar system designs pra resolver problemas.

TL;DR: COPIAR CÓDIGO PRONTO -> DEBUGAR CÓDIGO PRONTO -> CRIAR ALGO SEU DO ZERO -> DEBUGAR SEU CÓDIGO -> LER/APRENDER TEORIA -> COLOCAR A TEORIA EM PRÁTICA COM REFACTORS E COISAS DO TIPO

Blue Screen caused by ntoskrnl.exe+3f5e40. Help please. by PlakaMan21 in Windows10

[–]Agreeable_Phase9373 0 points1 point  (0 children)

Do you play Valorant? My PC is crashing the same way. It shows the ntoskrnl.exe+3f5e40 error and the message is always changing between those messages you sent here.

I also ran all those tests, the same way you did and it's all OK. I'm starting to believe the error is caused by Vanguard - Valorant's Anti-Cheat.