Thread by @GubnunBR

Como fazer a entrevista técnica de LeetCode?

Já fui entrevistador em muitos processos seletivos em BigTech/FAANG, e comecei a olhar vários patterns do que os outros entrevistadores mais se importam nos candidatos. Segue o fio 🧵
#bolhadev cc: @sseraphini @wmsbill @hugaomarques

Como disse na minha thread de ontem, saber a questão é 70% da entrevista, existem os outros 30% que não tem muito a ver com a questão, mas sim com outros aspectos técnicos que os entrevistadores olham. E é MUITO importante você “gabaritar” esses 30%, pq ele pode ser um fator…

decisivo na balança. As vezes você não “gabarita” a questão, talvez agarrou na solução, demorou, precisou de dicas, ou não fez o algoritmo mais eficiente. Então dos 70%, vamos supor que vc ganhou “50%”, os 30% que falo nessa thread provavelmente vai ser o fator decisivo em…

ganhar a offer ou não. Essas dicas não são sobre nenhuma empresa em específico, mas é uma observação geral do que outros entrevistadores mais se importam, e coisas que eu vejo eles “deduzindo” pontos dos candidatos no processo.

Então eu fiz um checklist de coisas pra fazer quando eu entrevisto, pra cobrir o máximo dessas coisas importantes possíveis, afinal você não sabe que tipo de entrevistador vai pegar e você quer fazer uma “cobertura de terreno” pra agradar o máximo possível.

Então vamo lá, os steps são os seguintes, vou entrar em cada um deles em detalhes:

1. Questões de clarificação
2. Força Bruta + Análise Big O (tempo e espaço)
3. Solução Otimizada
4. Pseudo-código alto nível
5. Código
6. Debug
7. Test Cases
8. Perguntas finais

1. Questões de Clarificação

Nessa etapa o entrevistador vai te dar uma questão, NÃO IMPORTA o quão ÓBVIA ela seja pra você, você pergunta no mínimo 2 ou 3 perguntas pra clarificar o problema. Muitos entrevistadores vão dar um problema mais em aberto e esperam que voce…

Clarifique a questão, isso é um sinal pra ele que você sabe pegar os requisitos e não simplesmente “vai e coda”, sem entender exatamente qual o requerimento. Perguntando questões de clarificação você ta evitando tomar um flag com relação a isso.

Vou dar um exemplo extremamente simples pra ilustrar.

Pergunta: “Inverta uma string”

Você: “Bom antes de ir pra solução, gostaria de clarificar algumas coisas…”

Tem várias coisas que você pode perguntar até pra uma questão simples dessa.

a) In-Place ou retorna uma cópia
b) String cabe na memória ou precisa de alguma lógica de streaming pro HD ou Network?
c)Casing e espaços em branco continua o mesmo?
d)ASCII ou Unicode?
e) Se for pra retornar uma cópia, eu aloco no heap direto ou recebo um alocador da aplicação?

f) Tem que ser thread-safe? Ou alguma outra thread pode pedir pra inverte a mesma src string ao mesmo tempo?
g) Você quer uma solução single-threaded?

E por aí vai, obviamente pra qualquer questão, tem muitas perguntas que você pode fazer.

Só quis ilustrar aqui, que mesmo pra pergunta mais básica possível, vc pode fazer perguntas. Então olhe suas questão, pense em 2~3 perguntas que você ache a mais relevante e FAÇA elas. É tbm uma oportunidade pra você mostrar seu conhecimento e fazer perguntas relevantes.

Quando você tiver feito suas perguntas, vc fala algo do tipo: “Bom, acho q tenho uma idéia geral do problema, estou pensando em ir pra parte do algoritmo, a não ser que você veja algo mais importante aqui que mereça alguma clarificação”

Repare que você não está dizendo: “Ah tah, entendi, bora resolver”. Você ta mostrando consciência que existem muito mais perguntas que você pode fazer, e dado o interesse de tempo, você esta pensando em prosseguir. Isso da a possibilidade pro cara te dar um sinal,

caso você não tenha perguntado a pergunta que ELE quer q você pergunte.

Parte 2) Força Bruta + Ánalise Big O

A primeira coisa que vc vai fazer é pensar na maneira mais simples de resolver o problema, geralmente uma maneira simples pode vim na sua cabeça de estalo, você vai tentar falar alto e escrever na tela, em linguagem natural…

a solucão, exatamente o que você pensa. Algo do tipo: “Bom a primeira coisa que eu posso pensar, talvez vamos ver como otimizar depois, é (agora escreva na tela) criar uma nova string e percorrer a string original de traz pra frente, a complexidade de tempo aqui seria

O(n) e de espaço O(n)”. Agora você fala: “Deixa eu tentar ver se tem como otimizar isso”. Nessa parte você está dando pro entrevistador que você já tem uma solucão e só esta pensando em algo melhor, ao invés de ficar mudo esse tempo todo e o entrevistador

não ter nem idéia de onde está o seu pensamento. Daí vamos pra terceira etapa:

3) Solução otimizada

Aqui existe um fork, você vai pensar uns 2~3 minutos em uma solução melhor, tente pensar alto pro entrevistador ver seu raciocínio.

Se você chegar no final de alguns minutos e não ver como melhorar, você fala algo do tipo: “Olha, eu posso continuar pensando em uma solução melhor, ou a gente pode codar essa solução que eu tenho e tentar otimizar depois, você quer que eu continue pensando em algo melhor?”.

Aqui você ta tentando fazer um probe na cabeça do entrevistador: Ele realmente QUER algo mais otimizado? Ou sua solução inicial na cabeça dele já esta ok? Se ele realmente QUER algo melhor, ele vai falar pra você continuar pensando

Ou seja, na cabeça dele, provavelmente sua solução inicial ia ser um fail pra entrevista. Mas muitas vezes esse NÃO é o caso, e você nao quer ficar perdendo tempo em uma solução ótima, se aquele cara vai te passar com a solução que você já tem.

O tempo aqui é precioso, e você nao quer perder tempo a toa. Por isso essa pergunta pra fazer um probe na cabeça dele.

A outra opção desse fork é se você realmente achou um algoritmo melhor. Daí você escreve de novo o algoritmo em linguagem natural:

“Eu posso fazer dois indices, um corre pela frente, outro por tras da string, fazendo o swap in-place e parando ao chegar no meio. O tempo seria O(n) e espaço O(1)”.

Ih cabou meu limite de tweet, continua…

De novo vc pergunta se essa é uma solução satisfatória, em caso positivo vc segue pro próximo step.

4) Pseudo-código alto nível

Esse step é pq já vi varios entrevistadores falando: “Ah a pessoa foi pro código direto, sem fazer um pseudo-código”

Então esse step é pra se defender contra esses entrevistadores, vc pergunta: “Deu pra entender a minha solução em linguagem natural ou vc prefere que eu faça um pseudo-código antes de ir pro código?”. De novo um probe,

90% dos entrevistadores vão falar que entendeu e pra ir pro código, então você pega e vai. Tempo é precioso e eu tbm prefiro ir direto pro código, se ele falar que quer pseudo-código, vc escreve.

Parte 5) Código

Aqui vc codifica a sua solução, mas FALE os steps que você ta fazendo em voz alta, pro entrevistador te seguir, você não quer “perder ele” na sua solução ou ele achar que foi confusa.

Parte 6) Debug / Dry Run

NUNCA saia do código e fale “acabei”, “é isso” e espere o entrevistador verificar. Imediatamente depois do passo 5, vc fala que vai debugar e fazer um dry-run do código. Nessa parte, você NÃO vai fazer algo alto nível!!!

Você faz igual um debugger, pega um input, escreve cada variavel sua e vai passando no código e dando update nos valores, até chegar ao final. E valida que funciona para aquele input, se encontrar algum bug você vai lá e concerta.

Se o seu Dry-Run passou, vc fala: “Ok, funcionou pra esse input, eu tava pensando em escrever alguns test cases”.

Aí vc move pra parte 7) Casos de Teste

Aqui é importante, você sai escrevendo casos de testes que sejam relevantes, nunca fale “acabei”, espere o entrevistador falar: “Ok, ta bom de testes”. Se ele não falar, depois de escrever uns 5~7 você fala: “Bom, posso continuar pensando em mais testes ou posso fazer outro debug

com um desses testes que eu escrevi”.

Aqui você ta basicamente perguntando se já esta bom, ou se o entrevistador quer mais testes. Você não quer falar que “acabou” com os testes, pq sempre tem algo a mais pra testar.

Se o entrevistador ver algum bug que você nao pegou, ele provavelmente vai escolher um teste que falha e pedir pra você rodar. Se não, pode ser que ele já esteja satisfeito e a entrevista acabou.

Parte 8) Perguntas finais

Em empresa americana, é MUITO comum o entrevistador deixar 5 minutos pra você fazer perguntas pra ele. É cultural isso e é ESPERADO que você faça alguma pergunta.

Não deixa essa oportunidade passar e faça qualquer pergunta interessante. Oq ele gosta mais da empresa? Com oq ele trabalha? Talvez vcs achem algum tópico de interesse em comum que vai dar uma impressão legal ao entrevistador.

É isso, thread gigante. Talvez teria sido melhor gravar um vídeo de Youtube pra isso, quem sabe eu faço depois. Mas espero que a thread tenha ajudado alguém ☺️