Biblioteca

Estou no 6º semestre de Ciência da Computação no Senac SP, com formatura prevista para dezembro de 2027. Na prática, o que mais me marcou até aqui foi construir um projeto de dados de ponta a ponta: análise exploratória, modelo, disponibilização por uma API e publicação com Docker e CI/CD. Também trabalhei com automação usando IA rodando de verdade, não só em ambiente de teste. Fora da parte técnica, treino jiu-jitsu, que me ensinou constância, e estudo italiano por conta própria, o que mostra bem como eu aprendo: sozinho, com rotina. Agora busco um lugar onde eu aprenda com gente mais experiente e contribua com o que já sei fazer.

• Presente: 6º semestre de CC no Senac SP, formatura dez/2027
• Passado: pipeline de dados completo (EDA → modelo → API → Docker → CI/CD)
• Extra: jiu-jitsu (constância) e italiano autodidata (autonomia)
• Futuro: aprender com gente experiente e crescer em tecnologia e dados

• Não recitar o currículo em ordem cronológica — conte uma história curta
• Não passar de 90 segundos
• Não entrar em detalhe técnico profundo: quem entrevista pode não ser da área

Meu principal diferencial é que eu já entreguei coisa funcionando de ponta a ponta, não só exercício de faculdade. Levei um projeto de dados da análise inicial até rodar publicado, com Docker e CI/CD, o que significa que eu já lidei com a parte chata: erro em produção, ambiente diferente, coisa que quebra. Segundo, constância: treino jiu-jitsu há tempo e mantenho estudo por conta própria toda semana, então eu não sou o tipo que começa animado e some. E terceiro, autonomia de aprendizado: estou aprendendo italiano sozinho, sem curso, e é do mesmo jeito que eu aprendo ferramenta nova no trabalho.

• Experiência prática real, projeto ponta a ponta e não só teoria
• Disciplina e constância comprovadas (jiu-jitsu, estudo semanal)
• Autonomia para aprender sozinho (italiano, DataCamp, CS50)

• Não se comparar com outros candidatos ('sou melhor que...')
• Não usar adjetivo solto sem prova: cada qualidade precisa de um exemplo
• Não soar arrogante — você está se candidatando a estágio, o tom é de quem quer aprender

Como qualidade, sou orientado a resultado e aprendo rápido na prática: prefiro colocar a mão e entender fazendo, e isso me fez conseguir entregar coisa que eu nunca tinha feito antes. Como defeito, eu quero entender profundamente antes de agir, e isso às vezes me faz demorar para começar. Percebi isso no projeto de automação que travou por excesso de planejamento. O que faço hoje é me dar um tempo curto e fechado de pesquisa, e depois disso eu testo mesmo sem ter certeza — na prática eu aprendo mais rápido e ainda corrijo o rumo cedo.

• Qualidade: orientado a resultado, aprende rápido na prática
• Defeito real: quer entender a fundo antes de agir
• Correção ativa: tempo curto de pesquisa e depois testa
• Conecta com o exemplo do projeto que travou

• Não dizer 'sou perfeccionista' sem contexto — é o clichê mais queimado
• Não citar defeito que inviabiliza a vaga (não gosto de trabalhar em equipe)
• Sempre mostrar o que você faz para controlar o defeito

Me vejo como um profissional sólido em tecnologia e dados, com mais responsabilidade técnica do que tenho hoje: participando de decisões de solução e não só executando. Não tenho um plano fechado de cargo, porque acredito que essa evolução se constrói na prática, e o caminho depende muito de onde eu conseguir gerar mais valor. O que eu procuro é um ambiente que me desafie de verdade e onde eu continue aprendendo, e é por isso que um programa estruturado como esse faz sentido para mim agora.

• Profissional sólido em dados/tech, com mais responsabilidade técnica
• Evolução construída na prática, sem plano rígido de cargo
• Busca ambiente que desafie e ensine continuamente

• NÃO mencionar planos de Turim, exterior ou EAOAP
• Não dizer 'quero abrir minha própria empresa' — soa como passagem
• Não citar cargo específico e alto demais (gerente em 5 anos)

De três formas. Primeiro, curva de aprendizado curta: eu já sei fazer na prática, então eu não preciso de meses só para entender ferramenta básica. Segundo, eu questiono o processo com respeito: quando algo parece repetitivo ou estranho, eu pergunto o porquê antes de sair mudando, e várias vezes é aí que aparece uma automação simples que economiza tempo. E terceiro, disciplina: eu apareço, entrego e mantenho ritmo, que é a parte que mais faz falta no dia a dia de um time.

• Curva de aprendizado rápida por já ter prática
• Questiona processo com respeito, buscando entender o porquê
• Disciplina comprovada e constância

• Não prometer resultado que você não controla ('vou aumentar a eficiência em X%')
• Cuidado com 'questiono processo': sempre acompanhe de 'com respeito, buscando entender'

Estou no 6º semestre de Ciência da Computação no Senac SP, com formatura prevista para dezembro de 2027, dentro do período que o programa pede. Tenho a certificação do Google em Data Analytics e o CS50 de Harvard, que é um curso bem fundamentado de introdução à ciência da computação. Também fui finalista no Apple Developer Academy, um programa seletivo de desenvolvimento de aplicativos. Fora da parte técnica, tenho inglês B2 pela Cambridge, o que ajuda bastante em documentação e material internacional da área. E além da faculdade, mantenho estudo por conta própria: atualmente estou fazendo cursos de Python na DataCamp.

• 6º semestre de CC no Senac SP, formatura dez/2027 (dentro da regra do programa)
• Google Data Analytics e Harvard CS50
• Finalista do Apple Developer Academy
• Inglês B2 Cambridge
• Estudo contínuo: DataCamp (Python)

• Não incluir itens irrelevantes para a vaga (violino, xadrez) aqui
• Deixar claro que a formatura cai dentro da janela 07/2027 a 12/2030

Porque estágio é o formato em que eu aprendo com quem já tem experiência enquanto ainda estou na graduação, e isso vale muito mais para mim agora do que só acumular tempo de trabalho. Sobre conciliar: a carga de 20 a 30 horas semanais é compatível com a minha grade e eu já organizo minha rotina em blocos entre faculdade, estudo por conta própria e treino. Formo em dezembro de 2027, então tenho tempo de sobra dentro do contrato de 1 a 2 anos do programa.

• Quer aprender com gente experiente ainda durante a graduação
• Carga de 20/25/30h é compatível com a grade
• Formatura dez/2027 cabe folgado no contrato de 1 a 2 anos

• Não deixar dúvida sobre disponibilidade — responda com segurança

No meu projeto de dados, o modelo funcionava bem nos testes mas começou a prever errado depois que subiu. A situação era essa: mesmo código, mesmo dado, resultado diferente. Minha tarefa era achar onde estava a quebra. Eu fui por partes, refazendo o caminho do dado etapa por etapa, comparando o resultado de cada passo entre o ambiente local e o publicado, até perceber que a normalização dos dados não estava sendo salva junto com o modelo — então em produção o dado entrava numa escala diferente da que o modelo tinha aprendido. Corrigi a persistência para salvar o pré-processamento junto e o resultado voltou a bater. O aprendizado foi pensar no pipeline inteiro como uma coisa só, não tratar o modelo como se ele fosse o sistema.

• S: modelo previa certo local e errado em produção
• T: identificar a causa da divergência
• A: investigou o pipeline etapa por etapa, comparando ambientes
• R: normalização não era salva junto com o modelo; corrigiu a persistência
• Aprendizado: o pipeline completo é o produto, não só o modelo

• Não pular o resultado — sempre termine dizendo o que mudou
• Não se perder em jargão: 'a escala dos dados ficava diferente' já explica
• Não atribuir a culpa a outra pessoa

Comecei uma automação de vendas em Python e passei tempo demais desenhando a arquitetura: como separar módulos, como deixar tudo extensível para o futuro. Resultado: a estrutura ficou bonita e o projeto nunca funcionou de verdade, porque eu nunca validei o básico. Assumo que o erro foi meu: quis a estrutura perfeita antes de provar que a ideia funcionava. Mudei o jeito de trabalhar desde então. Hoje eu começo pelo caminho mais simples que entrega o resultado, valido com dado real, e só depois refino a estrutura. Foi exatamente assim que consegui terminar o projeto seguinte.

• Erro concreto: over-engineering antes de validar o básico
• Responsabilidade assumida sem terceirizar a culpa
• Mudança de comportamento clara: simples e funcional primeiro, refina depois
• Prova de que a mudança pegou: o projeto seguinte foi concluído

• Não escolher um 'erro' que na verdade é elogio disfarçado
• Não contar erro grave de conduta (atraso, briga, quebra de confiança)
• Sempre fechar com o que mudou na prática

Eu divido o problema em etapas pequenas que dá para validar uma a uma. Em vez de tentar entregar tudo de uma vez e descobrir no fim que está errado, eu confirmo cada pedaço antes de seguir. Documento o que fiz enquanto faço, porque isso me ajuda a achar o erro cedo e também deixa o trabalho compreensível para outra pessoa. E antes de considerar pronto eu reviso com espírito crítico: testo o caso estranho, olho o que pode quebrar. Foi assim que consegui subir meu projeto sem depender de sorte.

• Divide o problema em etapas pequenas e validáveis
• Documenta o progresso enquanto faz
• Identifica o erro cedo em vez de descobrir no final
• Revisa criticamente antes de considerar pronto

• Não citar metodologia da moda sem ter vivido (não fale de Scrum se não usou)
• Não responder em abstrato: cole um exemplo real no final

Primeiro eu tento entender o que é realmente prioridade, porque nem tudo que é urgente é importante, e quando não está claro eu pergunto em vez de adivinhar. Depois eu corto o escopo para o que entrega valor primeiro: prefiro entregar a parte essencial funcionando no prazo e refinar depois do que entregar tudo pela metade. E aviso cedo se algo não vai caber, porque prazo estourado avisado em cima da hora é o pior cenário para o time. Concilio faculdade, estudo por conta própria e treino há bastante tempo, então essa organização é rotina para mim.

• Confirma a prioridade em vez de adivinhar
• Corta escopo: entrega o essencial funcionando primeiro
• Comunica cedo quando o prazo está em risco
• Prova de rotina: faculdade + estudo + treino em paralelo

• Não dizer 'trabalho bem sob pressão' e parar por aí
• Não dar a entender que vira noite sempre — isso sinaliza má organização

Em um trabalho em grupo da faculdade eu discordei da abordagem técnica que o colega propôs: ele queria uma solução mais elaborada e eu achava que atrasaria a entrega. Em vez de bater de frente, pedi para ele me explicar o raciocínio, porque eu podia estar perdendo alguma coisa. Ele tinha um ponto válido sobre a manutenção do código. Então propus um meio-termo: fazer a versão simples primeiro para garantir a entrega e, se sobrasse tempo, aplicar a estrutura que ele queria. Entregamos no prazo e ele aplicou parte da ideia dele. Aprendi que quase toda discordância técnica melhora quando você pergunta o porquê antes de defender sua posição.

• S: discordância técnica em trabalho de grupo
• T: destravar sem gerar atrito nem estourar o prazo
• A: perguntou o raciocínio dele, reconheceu o ponto válido, propôs meio-termo
• R: entrega no prazo com parte da ideia dele aplicada

• Não pintar o colega como vilão
• Não dizer 'nunca tive desentendimento' — soa evasivo

Eu peguei uma base de dados, estudei o que ela tinha de padrão e construí um programa que aprende com esse histórico para fazer uma previsão. Depois eu transformei isso em um serviço, ou seja, em vez de ficar só no meu computador, outra pessoa ou outro sistema consegue mandar uma informação e receber a resposta de volta. E por fim automatizei a publicação, então quando eu melhoro alguma coisa, essa melhoria é testada e vai para o ar sozinha. Resumindo: saiu de uma planilha de dados e virou uma ferramenta que alguém consegue usar.

• Traduz o pipeline sem uma única sigla
• Fecha com o valor: virou ferramenta usável
• Excelente resposta para entrevistador que não é da área técnica

• Nada de EDA, endpoint, deploy, pipeline nessa versão — esse é o ponto do exercício

Computação em nuvem é usar infraestrutura de terceiros pela internet em vez de manter servidor próprio: você usa a máquina, o banco ou o armazenamento de um provedor como AWS, Google Cloud ou Azure e paga pelo que usar. As vantagens principais são escalabilidade, porque você aumenta ou diminui recurso conforme a demanda, custo, porque não precisa comprar equipamento parado, e agilidade, porque você sobe um ambiente em minutos. Na prática eu já usei essa lógica no meu projeto: empacotei a aplicação em Docker, publiquei a imagem no Docker Hub e configurei CI/CD para que cada alteração fosse testada e publicada automaticamente.

• Definição simples: infraestrutura de terceiros pela internet, paga pelo uso
• Vantagens: escalabilidade, custo, agilidade
• Provedores: AWS, Google Cloud, Azure
• Prova prática: Docker + Docker Hub + CI/CD no projeto próprio

• Não usar jargão sem explicar — quem entrevista pode não ser técnico
• Não listar serviço decorado (EC2, S3, Lambda) sem ter usado
• Sempre fechar com o exemplo prático, é o que te diferencia

Minha linguagem principal é Python, e também já trabalhei com C# e JavaScript. Na parte de dados uso pandas e NumPy para tratamento e análise, e scikit-learn para modelagem. Para colocar as coisas em produção uso FastAPI para expor a solução como serviço, Docker para empacotar e GitHub Actions para automatizar teste e publicação. E no dia a dia, Git e GitHub para versionamento e SQL para consultar dados. Não conheço tudo na mesma profundidade, mas o que está nessa lista eu já usei em projeto de verdade.

• Linguagens: Python (principal), C#, JavaScript
• Dados: pandas, NumPy, scikit-learn
• Produção: FastAPI, Docker, GitHub Actions (CI/CD)
• Suporte: Git/GitHub, SQL
• Honestidade sobre profundidade é um ponto positivo

• Não inflar a lista com coisa que você só ouviu falar
• Não despejar siglas: agrupe por finalidade, como na resposta

O que me atrai na área como um todo é ver um problema virar algo que funciona de verdade, rodando e sendo usado. Infraestrutura especificamente não é o meu foco principal hoje, prefiro ser honesto sobre isso, mas é uma parte que eu já toquei na prática: para publicar meu projeto eu tive que lidar com containers, com ambiente, com configuração de rede, inclusive resolvendo questão de IPv6. E gostei de mexer, porque é a parte que faz o resto existir. Se eu for para essa área, é um terreno que eu tenho interesse genuíno em aprofundar.

• Motivação geral: gosta de ver o problema virar algo funcionando
• Honestidade: infra não é o foco principal hoje
• Contato prático real: Docker, ambiente, rede IPv6
• Interesse genuíno em aprofundar

• Não fingir paixão por infra — soa falso e é fácil de furar
• Não desmerecer a área ('não é bem o que eu quero')
• O equilíbrio é: honesto sobre o foco, aberto e curioso sobre a área

A LGPD é a lei brasileira de proteção de dados pessoais. Na prática ela diz que uma empresa só pode coletar e usar dado pessoal com uma base legal e uma finalidade clara, e que a pessoa tem direito de saber e de pedir correção ou exclusão. Em banco isso é ainda mais sensível, porque o dado é financeiro. Para quem trabalha com dados no dia a dia, isso significa coisas concretas: não sair copiando base de produção para a máquina pessoal, usar dado anonimizado quando dá, e acessar só o que a sua tarefa realmente exige.

• Lei de proteção de dados pessoais: base legal e finalidade definida
• Direitos do titular: acesso, correção, exclusão
• No dia a dia: mínimo privilégio, anonimização, não copiar base para máquina pessoal

• Não recitar artigos da lei — mostre a aplicação prática

Dado estruturado é o que já vem organizado em linhas e colunas, como uma tabela de transações no banco de dados: dá para consultar direto com SQL. Dado não estruturado é o resto: e-mail, áudio de atendimento, imagem de documento, texto livre. Tem muita informação ali, mas precisa de tratamento antes de virar análise. Um data lake é um repositório onde a empresa guarda os dois tipos no formato bruto, sem precisar decidir de antemão a estrutura, e o tratamento acontece na hora de usar. A vantagem é não perder informação; o risco é virar bagunça se não houver organização e catálogo.

• Estruturado: tabelas, consultável com SQL
• Não estruturado: texto, áudio, imagem — precisa de tratamento
• Data lake: guarda o dado bruto, estrutura definida na hora do uso
• Risco real: sem governança vira 'data swamp'

• Não confundir data lake com data warehouse — se perguntarem, warehouse é dado já tratado e modelado para análise

SQL é a linguagem para consultar e manipular dados em banco relacional: é como eu peço para o banco exatamente o recorte que preciso, filtrando, agrupando e somando. JOIN é o comando que junta duas tabelas por uma coluna em comum. Por exemplo, uma tabela de clientes e uma de transações: o JOIN pelo id do cliente me permite ver as transações com o nome do cliente junto. O INNER JOIN traz só quem existe nas duas tabelas, e o LEFT JOIN traz tudo da tabela da esquerda mesmo sem correspondência, o que é útil para achar cliente sem transação nenhuma.

• SQL: consultar e manipular dados em banco relacional
• JOIN: junta tabelas por coluna em comum
• INNER JOIN só o que existe nas duas; LEFT JOIN mantém tudo da esquerda
• GROUP BY + agregação (COUNT, SUM, AVG) para resumo

• Sempre dê um exemplo concreto: cliente e transação explica melhor que definição

Git é o controle de versão: ele guarda o histórico de cada alteração e permite que várias pessoas mexam no mesmo projeto sem sobrescrever o trabalho uma da outra. No dia a dia eu crio uma branch para a alteração que estou fazendo, faço commits pequenos e descritivos, e abro um pull request para que a mudança seja revisada antes de entrar na branch principal. Além de evitar erro, isso deixa rastreável quem mudou o quê e por quê, o que em ambiente corporativo é praticamente obrigatório.

• Controle de versão: histórico e trabalho em paralelo
• Fluxo: branch → commits pequenos → pull request → revisão → merge
• Rastreabilidade importa muito em ambiente corporativo

• Não confundir Git (a ferramenta) com GitHub (a plataforma) — vale deixar claro

Docker empacota a aplicação junto com tudo que ela precisa para rodar: versão da linguagem, bibliotecas, configuração. Isso resolve o clássico 'na minha máquina funciona', porque o container roda igual em qualquer lugar. Diferente de uma máquina virtual, o container é bem mais leve porque compartilha o sistema operacional em vez de simular um inteiro. CI/CD é a automação em cima disso: a cada alteração enviada, uma esteira roda os testes automaticamente e, se passar, publica a nova versão. No meu projeto configurei isso com GitHub Actions, e o efeito prático é errar menos e entregar mais rápido.

• Docker: empacota app + dependências, roda igual em qualquer ambiente
• Container x VM: container é mais leve, compartilha o sistema operacional
• CI: teste automático a cada alteração; CD: publicação automática
• Prova prática: GitHub Actions no projeto próprio

• Explique o benefício antes da sigla: quem entrevista pode não ser da área

Por três motivos concretos. Primeiro, a escala: um banco desse tamanho tem problemas reais de volume de dados e de operação, e isso é o tipo de desafio em que eu aprendo mais rápido. Segundo, a área: tecnologia e dados é exatamente a linha que eu já venho seguindo nos meus projetos, então eu entro contribuindo, não começando do zero. E terceiro, o programa em si: a estrutura de trilhas de formação com a UniBrad e o acompanhamento próximo mostram que o estagiário é levado a sério aqui, e não usado só como mão de obra de apoio.

• Estrutura grande = projetos reais e volume de dados desde o início
• Área de Tecnologia e Dados = continuidade natural do que já faço
• Programa com trilhas (UniBrad) e acompanhamento próximo

• Não falar de salário, benefícios ou estabilidade como motivo principal
• Não usar frase genérica do tipo 'é uma empresa grande e conceituada'
• Não dizer que aceitaria qualquer vaga

O Bradesco é o segundo maior banco privado do Brasil, fundado em 1943 em Marília, no interior de São Paulo, com sede hoje em Osasco. O programa de estágio deste ciclo tem o mote 'Confiança para começar, coragem para transformar', que sinceramente é o que eu busco: entrar com confiança no que já sei fazer e contribuir de verdade. Vi também que o modelo de trabalho é o 3x2, três dias presenciais e dois de home office, variando por área, e que o contrato vai de 1 a 2 anos, com carga de 20, 25 ou 30 horas semanais, o que se encaixa bem com a minha faculdade.

• 2º maior banco privado do Brasil, fundado em 1943 em Marília-SP, sede em Osasco
• Mote 2026: 'Confiança para começar, coragem para transformar'
• Modelo 3x2 (três dias presenciais, dois de home office), varia por área
• Contrato de 1 a 2 anos, 20/25/30 horas semanais
• Processo em etapas: trilha online, vídeo, entrevista, admissional

• Não despejar todos os fatos de uma vez — soa decorado
• Solte um ou dois fatos quando a conversa abrir espaço
• Não errar dado: se não tiver certeza de um número, não cite

O que mais me chama atenção é que banco hoje é praticamente uma empresa de tecnologia com licença bancária: a maior parte da relação com o cliente acontece pelo app. O Pix mudou a régua de expectativa, porque as pessoas passaram a esperar que tudo seja instantâneo e disponível o tempo todo, o que coloca uma pressão enorme em disponibilidade e em infraestrutura. E o Open Finance faz o dado circular entre instituições com autorização do cliente, o que aumenta muito o valor de saber usar dado bem, e ao mesmo tempo eleva a barra de segurança e de LGPD. É por isso que a combinação de tecnologia e dados nesse setor me parece um lugar interessante para aprender.

• Banco hoje é tecnologia: a relação com o cliente é digital
• Pix elevou a expectativa de disponibilidade e tempo real
• Open Finance: dado compartilhado com autorização do cliente
• Segurança da informação e LGPD como consequência direta

• Não opinar sobre concorrentes ou sobre estratégia do banco
• Não citar número de mercado que você não tem certeza

Tenho duas. A primeira: como é o dia a dia de quem entra como estagiário na área de Tecnologia e Dados, existe um projeto específico que eu participaria desde o início? E a segunda: quais características vocês mais valorizam em quem se destaca nesse programa?

• Sempre feche com 2 perguntas: zero passa desinteresse, mais de 3 passa ansiedade
• P1: como é o dia a dia e se há projeto específico desde o início
• P2: quais características vocês mais valorizam em quem se destaca
• A segunda é estratégica: abre espaço para você reforçar algo que já disse

• Não perguntar sobre salário, férias ou efetivação nesta primeira etapa
• Não perguntar algo que está no site do programa — mostra que não pesquisou
• Anote a resposta: demonstra atenção real