Forem: Anderson Contreira

WARNING TO DEVELOPERS: A new wave of “technical test scams” is targeting devs

Anderson Contreira — Sat, 06 Dec 2025 17:36:59 +0000

🚨 WARNING TO DEVELOPERS: A new wave of “technical test scams” is targeting devs — and it's getting more sophisticated

Over the past few months, several developers — including myself — have been targeted by a scam involving fake technical tests sent by “recruiters.”
People like Allan Lancioni, João Pessoa, and Muhammad Ramadhani have already documented identical attacks. Their posts are MUST-read.

This is not theoretical.
It’s real. It’s happening now.
And yes — it almost happened to me this year.

🔥 How the scam works (same pattern every time):

A “recruiter” (sometimes pretending to be a CEO/HR) contacts you.
The job looks amazing — above-market salary, remote position, paid in USD, etc.
They ask for your CV and GitHub.
They say you’re “approved for the next stage” without any real interview.
Before the call, they send you a codebase to review or modify as a “technical test.”

And that’s where the attack kicks in.

Running the project executes a malicious script hidden inside the dependencies, allowing remote code execution and giving the attacker access to your machine — especially to browser wallets and local credentials.

🧨 Real cases from the community

👉 Allan Lancioni

He reverse-engineered an actual attack.
The project contained scripts that enabled code injection and crypto-wallet theft.
His post (highly recommended):
https://www.linkedin.com/pulse/como-identifiquei-um-golpe-em-teste-t%C3%A9cnico-an%C3%A1lise-real-lancioni-kcyac/

👉 João Pessoa

He received a suspicious repo as a “technical test.”
In the package.json he found:

fs@0.0.1-security (placeholder inserted when a malicious package is removed)
execp@0.0.1 (malicious package designed to execute arbitrary commands)
request (deprecated + vulnerable)
A remote-code-execution script hidden in dark.min.js using atob + eval

His post:
https://www.linkedin.com/in/jppessoa/

👉 Muhammad Ramadhani

Received an almost identical project with the same malicious dependencies.
His warning went viral in the Web3 community.

Profile: https://www.linkedin.com/in/ramadhvni/

⚠️ And my personal case?

Yes — they tried this with me too.

The red flags:

The company claimed to be “X”, but the recruiter used a gmail.com address.
The repo had zero relation to the company name.
The project involved crypto (again, same pattern).
The code structure was suspicious.
They pushed me to run the project before any technical call.

The repo I received:
👉 mega-org99/Coinpromoting_dApp

Allan even replied saying the repo he received was extremely similar:
👉 megaorg991/tokentradingdapp

Same structure.
Same dependencies.
Same modus operandi.
Probably the same group.

My intuition kicked in — and I dropped the process immediately.
Better to lose a “job opportunity” than compromise my machine, accounts, and data.

🛡️ How to protect yourself (practical checklist):

✔️ 1. NEVER run `npm install`, `yarn`, or `pip install` on unknown projects.

Open the dependency files first.
Look for suspicious packages, single-version modules, weird names, etc.

✔️ 2. **Be skeptical of any test sent before a real conversation.**

Scammers skip interviews — they push codebases.

✔️ 3. **Check the recruiter’s email and company domain.

Gmail = Red Flag.**

✔️ 4. Ask for a technical explanation of the project.

Scammers avoid calls.

✔️ 5. Use ChatGPT to analyze suspicious code.

Paste dependencies → it will flag malicious patterns instantly.

✔️ 6. If an offer seems too good to be true… it probably is.

High salary + “easy test” + no interview = scam formula.

🚨 Final reminder: This isn’t paranoia — it’s protection.

Scammers target developers because:

devs run code
devs store SSH keys, API tokens, environment secrets
devs often have corporate access
devs trust “technical tests” too easily
devs working with Web3/crypto are especially vulnerable

If something feels off, walk away.
Your instinct is a security tool.

Stay safe. Audit everything. Trust nothing blindly.

ALERTA IMPORTANTE PARA DEVS: golpe em testes técnicos está crescendo - fiquem espertos

Anderson Contreira — Sat, 06 Dec 2025 17:34:56 +0000

🚨 ALERTA IMPORTANTE PARA DEVS: golpe em “testes técnicos” está crescendo (e cada vez mais sofisticado)

Nos últimos meses, vários desenvolvedores — inclusive eu — têm sido alvo de um golpe envolvendo “testes técnicos” enviados por supostos recrutadores.
Pessoas como Allan Lancioni, João Pessoa, e Muhammad Ramadhani já documentaram ataques muito semelhantes. Recomendo fortemente ler os conteúdos deles também.

Esse golpe não é teoria.
É real. Está acontecendo agora.
E sim, quase aconteceu comigo este ano.

🔥 Como o golpe funciona (sempre o mesmo padrão):

Um “recrutador” (às vezes se passando por CEO ou HR de blockchain) inicia contato.
A vaga parece ótima — salário acima da média, 100% remota, pagamento em dólar etc.
Ele pede seu CV e GitHub.
Diz que você “passou para a próxima etapa” sem nem conversar direito.
Antes da entrevista, envia uma codebase para você estudar ou ajustar.

E é aí que o ataque acontece.

Ao rodar o projeto, um script malicioso dentro das dependências executa um payload remoto — permitindo invasão, roubo de dados e, especialmente, acesso a carteiras de criptomoedas instaladas no navegador.

🧨 Casos reais analisados (dos artigos citados):

👉 Allan Lancioni

Ele fez engenharia reversa completa do ataque que recebeu.
A codebase tinha scripts escondidos que permitiam injeção de código e roubo de carteiras cripto.
Artigo dele aqui (leitura obrigatória):
https://www.linkedin.com/pulse/como-identifiquei-um-golpe-em-teste-t%C3%A9cnico-an%C3%A1lise-real-lancioni-kcyac/

👉 João Pessoa

Recebeu um repositório suspeito como “teste técnico”.
Ao checar o package.json, encontrou:

fs@0.0.1-security (indicador de pacote removido por malícia)
execp@0.0.1 (pacote criado só para executar comandos arbitrários)
request vulnerável
Um script de execução remota escondido em dark.min.js, usando atob + eval para rodar código vindo da internet.

Post original dele:
https://www.linkedin.com/in/jppessoa/

👉 Muhammad Ramadhani

Recebeu projeto idêntico, com exatamente os mesmos pacotes maliciosos.
Seu alerta viralizou entre devs de Web3.
Perfil: https://www.linkedin.com/in/ramadhvni/

⚠️ E o meu caso pessoal?

Sim, eu também recebi essa tentativa de golpe este ano.

Os sinais foram:

A empresa dizia ser “X”, mas o email do recrutador era um gmail.com.
O repositório não tinha nada a ver com o nome da empresa.
O projeto era relacionado a criptomoedas (de novo, o mesmo padrão).
Estrutura de código estranha.
Pressa para que eu rodasse a aplicação antes de qualquer call técnica.

O repositório que recebi foi este:
👉 mega-org99/Coinpromoting_dApp

Quando comentei isso, o próprio Allan respondeu que o golpe dele usava outro repo semelhante:
👉 megaorg991/tokentradingdapp

Mesma estrutura. Mesmo modus operandi.
Provavelmente o mesmo grupo.

Minha intuição falou mais alto e abandonei o processo na hora.
Preferi perder uma “oportunidade” do que arriscar minha máquina, minhas contas e meus dados.

🛡️ Como se proteger (de forma prática):

✔️ 1. Nunca rode `npm install`, `yarn` ou `pip install` em projetos enviados por desconhecidos.

Abra o package.json, requirements.txt, composer.json etc.
Procure pacotes desconhecidos, versões únicas, nomes estranhos.

✔️ 2. Desconfie de qualquer teste enviado antes de uma call real com o recrutador.

Golpista não faz entrevista — manda “teste” direto.

✔️ 3. **Pesquise o nome do recrutador e da empresa.

E-mail Gmail = bandeira vermelha.**

✔️ 4. Peça para o entrevistador explicar o projeto em call.

Golpista foge disso.

✔️ 5. Lembre que ChatGPT pode ajudar.

Se você colar dependências suspeitas e pedir análise, ele aponta padrões de malware.

✔️ 6. Se parecer bom demais… desconfie.

Golpe perfeito começa com proposta muito acima da realidade.

🚨 Resumo final: isso não é exagero — é prevenção.

Golpistas estão mirando desenvolvedores porque:

dev roda código
dev tem acesso a máquinas produtivas
dev guarda tokens, SSH keys, wallets
dev confia demais em “testes técnicos”

Não caia nessa.

Se algo parecer estranho, saia fora.
Seu instinto é uma ferramenta de segurança tão importante quanto seu antivírus.

Planejamento de carreira: ou você assume o volante, ou vira passageiro da própria vida

Anderson Contreira — Sat, 06 Dec 2025 14:47:48 +0000

Vamos ser sinceros e começar com uma verdade incômoda:
a maioria das pessoas não planeja a própria carreira — elas apenas sobrevivem.

Entram no mercado, aceitam o primeiro salário, resolvem algumas coisas básicas, pegam um financiamento aqui, outro ali… e quando percebem, a vida passou.

E a frase clássica chega:

“Meu Deus… já estou quase com 40. Como isso aconteceu tão rápido? Será que fiz o que deveria ter feito?”

Aconteceu porque você não planejou.
E quando você não planeja, você vive no modo “vida leva eu” — e esse é o caminho mais certo para estagnação e para deixar que alguém planeje seu futuro por você.

1. O tempo não espera — e sua carreira também não

A vida é implacável:
ou você se move, ou ela te move.

Dos 20 aos 30, você acha que tem o mundo inteiro pela frente.
Dos 30 aos 40, você percebe que não tem tanto tempo assim.
E depois dos 40, sua margem de erro diminui brutalmente. A pressão aumenta, e a liberdade de arriscar diminui.

Independente da sua idade, se você não tem um plano, você se torna passageiro da própria vida.

2. Ambição e Planejamento Pós-Primeira Chance

Sim, eu vou falar a palavra que muita gente evita:

👉 mediocridade.

Ter a primeira oportunidade (seja como Júnior em TI, ou Auxiliar de Vendas) é um grande passo. Mas depois que você entra, a mentalidade muda. Você precisa ter direção.

Se você não sabe para onde quer ir, qualquer caminho te leva ao lugar errado.

Um profissional Júnior, no mínimo, precisa ter um plano de transição para Pleno. Um Auxiliar de Vendas precisa mirar em ser Vendedor e, em seguida, Gerente. Você precisa ter uma ideia de como responder à pergunta: "Onde você se vê em 5 anos?"

O papo de "salário mínimo, esforço mínimo" tem seu peso, mas se você adota isso como lei de vida, você se transforma em um profissional mediano. E profissional mediano não cresce. Em lugar nenhum.

Ambição de crescimento é o mínimo. Falta de ambição é o caminho direto para a mediocridade.

3. Entregar tudo e não receber nada? Então pare de insistir.

Trabalhar bem, entregar com qualidade, e até fazer um pouco além — isso é o básico.

Mas se você faz a sua parte e percebe que a empresa:

não te reconhece,
não te desenvolve,
não te promove,
não te valoriza…

Então você não tem que "ter paciência". Você tem que ter opções.

Você não tem um emprego. Você tem um atraso na sua vida.

*Lealdade é estratégia de carreira, mas seja leal com quem é leal a você. * A empresa é uma ferramenta. Se ela não serve mais, mude a ferramenta.

4. O peso da vida pessoal (e por que ela congela carreiras)

Casamento, filhos, boletos, escola, casa, saúde... tudo isso muda completamente a forma como você toma decisões.

É difícil, mas é real: quando a vida aperta, o instinto é não arriscar.

Vou ser direto (e realista):

👉 Se você consegue estudar, fazer faculdade, pós e inglês ANTES de formar família… faça.

Isso reduz o peso emocional e financeiro absurdamente.

Quando você estuda antes:

tem mais tempo, menos preocupações e mais energia;
tem mais liberdade para trocar de emprego e evoluir mais rápido;
pode dedicar foco total no crescimento, com menos risco nas escolhas.

Quando estuda depois de casar e ter filhos:

o tempo é menor e o cansaço é maior;
o dinheiro é mais contado e a responsabilidade aperta;
o risco parece maior e as decisões precisam ser muito mais calculadas.

Não é impossível — eu jamais diria isso. Mas é muito, muito mais difícil.

Sua carreira passa a impactar outras pessoas. Isso te trava, te deixa mais cauteloso. E, às vezes, te prende onde você não deveria estar mais.

👉 Quanto antes você se qualificar, menos a vida vai te limitar depois.

5. Seu Nome é Seu Ativo Mais Valioso: O Peso das Finanças.

Para ter liberdade para dar passos (mesmo que cautelosos) em sua carreira, você precisa de uma retaguarda: controle financeiro.

A grande maioria de nós não teve educação financeira. Tivemos que aprender na marra. Mas com tantas ferramentas e pessoas compartilhando sobre o tema, não dá mais para dar desculpas.

Precisamos falar sobre a cultura da dívida. Não há mérito em se orgulhar de estar devendo, ou pior, ver dívidas caducando em 5 anos como se fosse uma conquista.

A única coisa que temos que zelar é o nosso nome e nossa reputação.

👉 Sem dinheiro, você não compra tempo. Sem tempo, você não compra evolução.

O controle financeiro pavimenta o caminho das suas aquisições e conquistas, e te dá a liberdade de dizer não a empregos ruins e a liberdade de arriscar para empregos melhores.

6. Estudos: Não é só aprender, é se manter na jornada.

Muitas áreas não precisam da faculdade para começar (como a maioria em TI). Mas o quanto antes resolver, melhor será. Para cargos de liderança, a formação formal conta — e muito.

E sobre o idioma:

Inglês não se aprende em três meses. É manutenção.

Eu sei o quanto um professor particular ajuda, pois a exposição contínua ao idioma, como em aulas de conversação, faz toda a diferença. Assim como nossa casa precisa de limpeza e manutenção, aulas de idiomas nos ajudam a manter as coisas em ordem.

Outro ponto fundamental:

Você precisa pesquisar o caminho da sua área. O que é preciso para ser Pleno? O que o mercado pede de um Sênior, Arquiteto ou Gerente? A experiência adquirida vai pavimentar o caminho, mas você precisa saber para onde está pavimentando.

7. Liderança: Assusta, mas paga a conta.

Muita gente foge da liderança.Eu sei como é bom ficar só "fazendo o seu" sem se incomodar.

Mas essa escolha pode te congelar ou atrasar na sua carreira.

Porque o mercado premia quem se expõe, quem resolve, quem agrega, quem ensina e quem assume responsabilidade.

Exposição abre portas. Fugir dela fecha.

Se liderança não é para você — sem problemas.
Mas então seja o quê?

👉 Uma referência técnica, no mínimo.

8. O Plano Prático (que realmente funciona)

Tudo isso vai exigir organização: do tempo, do dinheiro, das prioridades e dos objetivos.

E aqui vai o método simples que funciona de verdade:

📌 1. Todo fim de ano, monte sua lista do próximo ano

Parece bobo, mas funciona mais do que você imagina. Coloque metas claras, seja na área de TI ou em qualquer outra:

Estudar inglês/fazer curso;
Fazer faculdade/pós/tirar certificação;
Aprender tecnologia X ou Y;
Juntar dinheiro/quitar dívida/antecipar financiamento;
Buscar promoção/mudar de emprego;
Melhorar comunicação/treinar liderança;
Começar academia/ler 3 livros.

📌 2. Revise e priorize a lista ao longo do ano

Isso te mantém no caminho, te lembra do que foi alcançado e do que precisa de mais foco.

📌 3. Tenha uma ferramenta para gestão financeira

Pode ser uma planilha simples ou um app. Tanto faz. O importante é saber quanto ganha, quanto gasta e quanto pode arriscar/investir.

Organização + Ambição + Constância = Crescimento Real.

Conclusão: carreira é planejamento — não sorte

A verdade é dura, mas é real:

👉 O tempo passa.
👉 O mercado muda.
👉 A vida aperta.
👉 E quem não planeja… paga caro depois.

O importante é:

não cair na zona de conforto,
não viver no modo “vida leva eu”,
e não deixar que a vida decida por você.

Sua carreira é seu patrimônio.
Seu nome é seu bem mais valioso.
Sua vida é sua responsabilidade.

A empresa é uma ferramenta/escada.
O plano é seu.
A jornada é sua.
E o destino… também.

RESTful – Pílula 6 – Paginação, Filtros e Ordenação em APIs REST

Anderson Contreira — Thu, 04 Dec 2025 14:46:05 +0000

Conforme uma API cresce, lidar com grandes volumes de dados se torna inevitável.
Para manter performance, organização e consistência, APIs RESTful maduras utilizam padrões bem definidos de paginação, filtros, seleção de campos (fields) e ordenação.

Esses mecanismos tornam a API mais eficiente, previsível e flexível para integrações externas.

Por que isso é importante?

evita respostas gigantes e lentas
melhora performance do servidor e do banco
reduz tráfego desnecessário
aumenta a flexibilidade para consultas complexas
oferece controle total para o consumidor da API

Paginação – Os padrões mais utilizados

A API pode adotar mais de um padrão, mas deve manter consistência.

1. Modelo baseado em page / limit

Requisição:

GET /users?page=1&limit=20

Resposta recomendada:

{
"success": true,
  "code": 1,
  "label": "OK",
  "message": "Operation completed successfully",
  "params": ["page", "limit"],
  "data": [
    { "id": 1, "name": "Alice" },
    { "id": 2, "name": "Bob" }
  ],
  "meta": {
    "page": 1,
    "limit": 20,
    "total": 143,
    "totalPages": 8
  }
}

Esse é o modelo mais intuitivo e comum.

2. Modelo baseado em offset / limit

Requisição:

GET /users?offset=0&limit=20

Resposta recomendada:

{
  "success": true,
  "code": 1,
  "label": "OK",
  "message": "Operation completed successfully",
  "params": ["offset", "limit"],
  "data": [
    { "id": 1, "name": "Alice" },
    { "id": 2, "name": "Bob" }
  ],
  "meta": {
    "offset": 0,
    "limit": 20,
    "total": 143,
    "count": 2
  }
}

Características:

offset indica o deslocamento inicial
limit indica quantos registros retornar
count mostra quantos itens vieram nesta resposta

Muito utilizado em bancos SQL e sistemas que precisam navegar por índices exatos.

3. Cursor-based pagination

Ideal para bases muito grandes ou altamente dinâmicas.

Exemplo:

GET /orders?cursor=eyJpZCI6MTB9&limit=20

Benefícios:

evita inconsistências entre páginas
escala melhor
recomendado quando registros mudam com frequência

Filtros — Consultas mais flexíveis

Filtros permitem buscar apenas dados relevantes, sem criar endpoints específicos.

Exemplos:

GET /users?status=active&role=admin

Filtros mais elaborados:

GET /products?category=clothes&min_price=50&max_price=200

Evite endpoints com lógica embutida:

GET /users/active        // não recomendado
GET /products/cheap      // não recomendado

Seleção de campos (fields)

Permite ao cliente escolher quais campos deseja receber, reduzindo tamanho do payload e melhorando performance.

Requisição:

GET /users?fields=id,name,email

Resposta:

{
"success": true,
  "code": 1,
  "label": "OK",
  "message": "Operation completed successfully",
  "params": [
"fields"
],
  "data": [
    { "id": 1, "name": "Alice", "email": "alice@example.com" },
    { "id": 2, "name": "Bob",   "email": "bob@example.com" }
  ],
  "meta": {
    "offset": 0,
    "limit": 20,
    "total": 143,
    "count": 2
  }
}

Validação do fields

A API deve:

impedir retorno de campos inexistentes
bloquear campos privados ou sensíveis
padronizar erros quando parâmetros inválidos forem enviados

Erro recomendado para campos inválidos

A API deve retornar erro claro, consistente e seguro quando o cliente pedir um campo inexistente ou proibido.

{
  "success": false,
  "code": 32,
  "label": "INVALID_FIELD_ERROR",
  "message": "Invalid field in 'fields' parameter",
  "params": [
    "fields"
  ],
  "details": "Allowed fields are: id, name, email, created_at",
  "trace": "Traceback (most recent call last):\n  File \"/usr/local/lib/python3.9/site-packages/flask/app.py\", line 2447, in wsgi_app\n    response = self.full_dispatch_request()\n  File \"/usr/local/lib/python3.9/site-packages/flask/app.py\", line 1952, in full_dispatch_request\n    rv = self.handle_user_exception(e)\n  File \"/app/src/controllers/user_controller.py\", line 45, in get_users\n    raise InvalidFieldException(invalid_fields=['password'], allowed_fields=['id', 'name', 'email', 'created_at'])\nexceptions.InvalidFieldException: Invalid field 'password' not in allowed fields (id, name, email, created_at)"
}

Notas importantes sobre segurança e padronização

Sobre o código interno (code = 32)

Ele complementa o status HTTP (neste caso, 400).
Toda API madura mantém uma tabela de códigos internos padronizados.
Facilita debugging, monitoramento, suporte e internacionalização.

Sobre o label

A label é a chave mais importante para o frontend:

é estável
é semântica
permite mapeamento para diferentes idiomas
possibilita UX customizada em cada aplicativo

Exemplo de mapeamento frontend:

{
  INVALID_FIELD_ERROR: {
    en: "Invalid field.",
    pt: "Campo inválido.",
    es: "Campo inválido."
  }
}

Sobre o campo trace

nunca deve ser exposto em produção
útil apenas em logs internos ou dev mode
stack traces expostos aumentam superfície de ataque

Sobre o campo details

deve ajudar a entender o erro
sem expor lógica interna, queries, tabelas, caminhos de arquivo
mensagens simples como “Allowed fields are…” são aceitáveis

Ordenação (sorting)

A API pode adotar dois padrões amplamente aceitos.

1. Padrão com prefixo "-"

GET /users?sort=created_at
GET /users?sort=-created_at

field → ordem crescente
-field → ordem decrescente

Simples e muito comum.

2. Padrão sort + order_by (mais explícito)

GET /users?sort=name&order_by=ASC
GET /users?sort=name&order_by=DESC

Vantagens:

mais claro
amigável ao consumidor
fácil de validar

Exemplos:

GET /products?sort=price&order_by=ASC
GET /products?sort=created_at&order_by=DESC

Ambos os padrões são válidos; escolha um e mantenha consistência.

Combinando tudo em uma única consulta

GET /orders?status=paid&sort=created_at&order_by=DESC&offset=20&limit=20&fields=id,amount,currency,created_at

Boas práticas gerais

mantenha consistência em toda a API
documente filtros, campos e ordenação suportados
evite endpoints com lógica embutida
sempre valide campos em fields
nunca exponha stack traces em ambiente produtivo
considere cursor pagination para bases muito grandes

Resumo

Paginação evita sobrecarga e melhora performance
Page/limit e offset/limit são válidos
Cursor pagination é excelente para grandes volumes
Filtros trazem flexibilidade
Seleção de campos ajuda na performance e organização
Ordenação pode ser prefixada (-created_at) ou explícita (order_by=ASC)
Erros devem ser padronizados com code, label, message, params, details e controle seguro de trace

Don’t Limit Yourself: Why Broadening Your Tech Horizons Keeps You Relevant

Anderson Contreira — Wed, 03 Dec 2025 00:36:48 +0000

If there is one thing time has taught me working in IT, it is this: getting stuck with what you already know is the fastest path to being left behind.

Our field evolves constantly. You do not need to learn something new every month, but you should widen your possibilities. Learning new languages, frameworks, tools or paradigms expands your technical vision and makes you more versatile to solve real problems.

It is even better when your company gives you freedom to experiment with new technologies, as long as it does not turn into chaos.

Choosing technology is not about what seems cool, but about what makes sense for the context of the project. In your personal projects, explore without fear because that is where real growth happens.

If I were to recommend a set of technologies today for someone looking for greater opportunities in the market, I would start with:

JavaScript or TypeScript
PHP
Python
Go
Java

The only order here is their learning curve. JavaScript and TypeScript are easier to begin with, and Java demands more structure and discipline.

Why “Don’t Limit Yourself” Matters More Than Ever

In today’s tech world, versatility is a major advantage. The boundaries between roles such as back end, front end, DevOps, data and machine learning are increasingly blurry. Companies value professionals who can navigate across layers and contribute in various ways.

From Coding to DevOps

Knowing a programming language is not enough anymore. Understanding infrastructure, deployment pipelines, continuous integration and continuous delivery, containerization and cloud services under the umbrella of DevOps can make a huge difference. DevOps is not just a set of tools. It is a culture that merges development and operations to speed up delivery and improve collaboration.

A developer who also understands DevOps helps their team to deliver faster and keep systems stable. That ability alone sets you apart.

Adding Machine Learning to Your Toolbox

If you expand your knowledge into Machine Learning, you unlock opportunities in data-driven features, automation, personalization, predictive systems and more. Machine Learning is no longer something optional. It is increasingly part of mainstream products and systems.

Combining a background in software development with ML and applying MLOps practices for deploying and maintaining ML models can make you a highly desirable professional for companies building modern, data-intensive applications.

Front End, Back End, Databases, Full Stack or All of the Above

Knowing only one side of the stack is a limitation. If you also study front end frameworks, UI and UX basics, how to design APIs and especially learn about databases, both SQL and NoSQL, and their best use cases, you become much more prepared to tackle real-world challenges end to end.

A well chosen database strategy makes a big difference in scalability, performance and maintainability. Understanding when to use relational databases, when to go for document stores and when caching or indexing makes sense can separate a good system from a fragile one.

How to Expand Your Skills Without Losing Focus

Here are some ideas to explore beyond your main stack, while keeping your learning structured:

Choose one complementary domain at a time such as DevOps, ML, front end, database or security, and study the basics seriously.
Build small personal projects to apply what you learned because hands-on experience is irreplaceable.
Combine disciplines by building a simple project that touches full stack, DevOps and ML. The learning multiplies.
Keep code, infrastructure and machine learning clean and maintainable because good practices matter everywhere.
Stay curious, but do not spread yourself too thin. Aim for depth in a few domains rather than superficial knowledge in many.

Final Thoughts

In a world where technology evolves rapidly, it is no longer enough to be a specialist in one language or framework. Versatility, continuous learning and willingness to cross boundaries make you stand out.

Embrace DevOps, explore Machine Learning, understand front end and back end, dive into databases. Expand your toolbox with intention, build holistic knowledge and become the kind of professional who adapts, learns and leads.

Do not limit yourself. Learning is what keeps you relevant

Por que o plano de carreira virou exceção, e como isso afeta a entrada de novos profissionais no mercado

Anderson Contreira — Tue, 02 Dec 2025 21:00:49 +0000

O mercado de TI passou por transformações profundas nos últimos anos. Uma das mais evidentes é a dificuldade crescente que profissionais em início de carreira têm enfrentado para conseguir sua primeira oportunidade. Isso não acontece de forma isolada; existe um conjunto de fatores que explica por que as empresas estão mais resistentes em contratar e desenvolver novos talentos.

A permanência nas empresas mudou

Durante muito tempo era comum que pessoas construíssem grande parte da sua trajetória profissional em um único lugar. Hoje, essa realidade mudou completamente. Profissionais permanecem cada vez menos tempo em uma empresa; existe uma tendência dos profissionais buscarem uma nova oportunidade em até três anos; entre os mais jovens esse período costuma não chegar a um ano.

Para as empresas, isso cria um dilema. Desenvolver um profissional iniciante demanda investimento, mentoria, direcionamento e a curva de aprendizagem das tecnologias. Muitas vezes, esse investimento só começa a gerar retorno após um ano,e muitas vezes é quando o colaborador já está prestes a sair. Como consequência, a empresa fica mais cautelosa e passa a priorizar contratações de profissionais mais experientes, que entregam impacto imediato.

E existe outro elemento importante: o salário. No mercado de TI é amplamente conhecido que trocar de empresa costuma gerar um ganho financeiro real; muitos conseguem aumentos de 15% a 20%. Já os reajustes internos por reconhecimento dificilmente passam de 8% a 10%. As promoções podem ser um pouco melhores, mas nem sempre a mesma vem da forma esperada. Essa diferença incentiva a busca por oportunidades externas e contribui para o ciclo de alta rotatividade. O resultado é simples: as empresas investem menos porque as pessoas saem rápido, e as pessoas saem rápido porque as empresas investem pouco.

Automação elevou ainda mais a exigência para quem está começando

Tarefas que antes eram delegadas a profissionais em início de carreira hoje podem ser automatizadas por ferramentas de IA, plataformas low-code e soluções que aceleram o desenvolvimento. Com isso, as empresas passaram a focar em perfis mais completos, plenos e seniors capazes de entregar autonomia desde o primeiro dia.

O efeito final é uma barreira real de entrada para quem está começando. Um ciclo que restringe oportunidades e diminui a renovação natural do mercado.

Dentro das empresas, o problema continua: falta estrutura de crescimento

Mesmo quando olhamos para organizações que possuem plano de carreira, os problemas persistem.

Algumas empresas simplesmente não têm estrutura alguma. Outras até possuem algo no papel, mas executam de forma confusa ou pouco transparente. Pouquíssimas realmente fazem esse processo funcionar como deveria.

Ao longo da minha trajetória, vivenciei três contextos onde o plano de carreira existia formalmente. No entanto, um deles era extremamente complexo de interpretar. Ferramentas como 9-Box, por exemplo, eram utilizadas sem clareza nos critérios. Isso tornava o processo cansativo, frustrante e inconsistente. Ainda assim, houve reconhecimento financeiro, mas a promoção exigia muito mais do que parecia razoável.

Essa falta de clareza se agrava quando a empresa não possui metodologias de acompanhamento estruturadas, como:

• 1:1 periódicos
• Avaliações 360°
• Modelos como 9-Box
• Frameworks claros de competência
• Feedback contínuo e rastreável

Sem isso, o profissional fica no escuro. Sem direção, sem mapa, sem entender o que precisa evoluir e sem confiança de que seu esforço vai gerar crescimento.

O impacto humano — e a barreira invisível que desencoraja talentos

Muitos profissionais com potencial acabam desistindo antes mesmo de começarem sua jornada. A barreira de entrada se tornou tão alta que vagas que deveriam ser de formação exigem experiência de um ou dois anos, algo que simplesmente não faz sentido para alguém tentando iniciar a carreira.

Essa régua elevada, combinada com falta de orientação e processos internos frágeis, gera um ambiente onde muita gente só quer uma oportunidade, mas se vê presa em um ciclo de “falta experiência, mas precisa de experiência para conseguir experiência”.

Sem alternativas claras, muitos acabam migrando para outras áreas por puro esgotamento.

Ainda assim, investir em novos talentos continua sendo estratégico

Apesar de todo o cenário acima, existe uma verdade inegável: as empresas que desejam longevidade precisam continuamente formar novos profissionais.

• Pessoas que estão começando absorvem conhecimento muito rápido
• Mentoria cria cultura, fortalece times e garante sucessão
• Equipes com níveis diferentes de experiência são mais saudáveis
• Talentos iniciantes renovam ideias, energia e visão
• Sem novos profissionais, cria-se um risco real de “apagão de talentos” no futuro

Manter uma proporção saudável de profissionais iniciantes não deveria ser visto como custo, mas como estratégia de continuidade.

E agora?

Não existe solução simples para esse tema. Ele envolve empresas, educação, políticas de mercado e mentalidade coletiva. Mas existe um ponto de partida: reconhecer o problema.

Empresas precisam repensar sua estratégia de desenvolvimento. Profissionais precisam aprender a identificar ambientes saudáveis. E o mercado como um todo precisa equilibrar tecnologia, eficiência e pessoas.

Se nenhuma mudança acontecer agora, no futuro a preocupação não será falta de frameworks, ferramentas ou IA. Será falta de gente preparada para construir o que vem pela frente.

Quando a empresa prefere contratar alguém de fora em vez de promover quem já está dentro

Anderson Contreira — Mon, 01 Dec 2025 18:11:11 +0000

Falar sobre carreira é, inevitavelmente, falar sobre motivação. E poucas coisas desmotivam tanto um time quanto ver a empresa buscando alguém de fora para uma posição que poderia, e deveria, ser preenchida internamente.

Sim, existem casos em que faz todo sentido trazer alguém novo. Eu já vi isso acontecer. Em uma empresa onde trabalhei, a chegada de um novo gestor de RH foi um divisor de águas. A cultura mudou, processos amadureceram e até a estrutura de Business Partners foi criada. Ali, contratar alguém de fora foi estratégico e necessário.

Mas nem sempre é esse o cenário.

Em outras situações, a empresa tem profissionais competentes, comprometidos e culturalmente alinhados, mas prefere ignorá-los. E aí nasce o problema: como manter a motivação de quem já está entregando valor, mas não é visto como opção?

Essa postura corrói o clima, afeta a confiança e, muitas vezes, acelera a saída de talentos que estavam prontos para dar o próximo passo.

E existe um outro lado dessa moeda: a resistência a permitir movimentos internos reais.

Já vi (e vivi) situações como pessoas querendo migrar de desenvolvimento para DevOps, mas encontrando barreiras invisíveis. Gestores que não enxergam valor em papéis como Arquitetura e acabam impedindo o crescimento natural do time. Estruturas engessadas onde mudar de área significa quase começar do zero. E a pior situação: propostas indecentes para quem quer migrar de carreira, como sair da empresa e voltar como júnior, com salário menor, porque a área não quer manter o mesmo nível. Sim. Aconteceu comigo. E acontece com muita gente.

E aqui vai um ponto essencial: se não é estratégico promover alguém naquele momento, o mínimo é dar feedback, reconhecimento e direcionamento.

Mesmo que a promoção não seja possível agora, existem outras formas de valorizar quem está ali. Ajuste salarial coerente com a performance. Indicação clara de caminhos de crescimento. Orientação concreta, como “faça esse curso”, “tire essa certificação”, “faça uma pós em X ou Y”. Mostrar que existe um plano e que existe futuro.

Quando isso não existe, a mensagem fica clara: faça o que fizer, nada vai mudar.

Aí o gestor se surpreende com o turnover. Reclama da perda de talentos. Questiona por que gente boa sai tão rápido. Mas a resposta estava na cultura que ele mesmo ajudou a construir.

E reforço aqui que trazer alguém de fora pode ser importante e estratégico por vários motivos. O problema não é contratar. O problema é esquecer quem já está na luta todos os dias.

Reconhecer é barato. Motivar é inteligente. Perder talento é o custo mais alto de todos.

E você? Já passou por isso ou viu acontecer de perto?

Quick tip for anyone building a career in Tech

Anderson Contreira — Sun, 30 Nov 2025 15:56:58 +0000

If you’re growing in the tech field, make sure you have public and relevant projects on your GitHub.

And when I say “relevant,” I’m not talking about complex enterprise systems —

complete study projects are perfectly fine, such as:

Well-structured APIs
Functional frontend applications
Small full-stack apps
Tools that solve real problems
Project templates and boilerplates

In other words: something that shows your technical maturity, not just random bootcamp exercises or generic CRUDs thrown together.

These projects help recruiters and tech leads understand:

How you structure an application
Your architectural thinking
Whether you apply industry best practices
Your awareness of security
Your ability to document your work
Code clarity and consistency
How you make technical decisions

When I used to review candidates, I checked all of this.

And professionals who ignored these details lost points in the evaluation, even if they were technically strong.

“But AI can generate all the code now.”

Yes, AI helps a lot.

But here are two important truths:

1) AI will not do everything for you — especially when it comes to deep understanding, technical reasoning, and decision-making.

Not to mention the situations where AI generates way more code than necessary.

2) It’s easy to spot AI-generated code that wasn’t reviewed, or when a developer can’t explain what they built.

And let’s be honest: even before AI, many people were copying code or entire projects without understanding them.

The problem is not using AI.

The problem is using it without reviewing, without understanding, and without developing real critical thinking.

If you want to stand out:

👉 publish complete, meaningful projects

👉 review your code (AI-generated or not)

👉 demonstrate technical maturity in practice

👉 build a portfolio that truly represents your skills

Trust me: it makes a huge difference.

Dica rápida para quem está construindo carreira em TI

Anderson Contreira — Sun, 30 Nov 2025 15:54:42 +0000

Pessoal, deixem projetos públicos e relevantes no GitHub de vocês.

E quando eu falo “relevantes”, não significa que precisam ser sistemas complexos — projetos de estudo completos também valem, como:

APIs bem estruturadas
Frontends funcionais
Pequenas aplicações full stack
Ferramentas que resolvem um problema real
Templates de projetos

Ou seja: algo que mostre seu nível técnico, e não apenas exercícios soltos de bootcamp ou CRUDs genéricos.

Esses projetos ajudam recrutadores e líderes técnicos a entender:

Como você organiza uma aplicação
Sua visão de arquitetura
Se aplica boas práticas de mercado
Seu cuidado com segurança
Sua capacidade de documentar
Clareza e consistência no código
Como você toma decisões técnicas

Quando eu avaliava perfis para contratar, eu olhava tudo isso.

E profissionais que ignoravam esses detalhes perdiam pontos na avaliação, mesmo sendo bons.

“Ah, mas hoje a IA faz tudo.”

Sim, a IA ajuda muito.

Mas existem duas verdades importantes aqui:

1) A IA não faz tudo por você: principalmente aquilo que exige entendimento profundo e decisões técnicas — fora quando ela gera muito mais código do que o necessário.

2) É fácil perceber quando o código foi gerado e não revisado, quando o dev não entende o que entregou ou não sabe explicar suas escolhas.

E vale lembrar: antes da IA isso já acontecia, com profissionais copiando projetos inteiros, copiando lógica de outros repositórios e simplesmente encaixando isso no próprio código.

O problema não é usar IA.

O problema é usar sem revisar, sem entender e sem desenvolver pensamento crítico.

Se você quer se destacar:

👉 publique projetos completos

👉 revise seu código (humano ou gerado por IA)

👉 demonstre maturidade técnica na prática

👉 construa um portfólio que represente quem você realmente é

Acredite: isso faz diferença — e muita.

Finding Balance in Architectural Decisions

Anderson Contreira — Fri, 28 Nov 2025 22:38:06 +0000

In software projects, not every decision needs a full-blown architectural committee or a 30-page design document. But the opposite is also true: some decisions are too important to be treated as a simple quick fix.

Every engineering team faces moments where they need to choose between doing something the right way or doing something fast. In Brazil, we often call the fast solution a gambiarra or puxadinho, an improvised workaround that solves the problem for now but usually comes with long-term costs. In English, the closest terms would be a patch, hacky fix, temporary workaround, or band-aid solution.

And the reality is: sometimes you do need a quick workaround to move forward. Deadlines exist, business pressure is real, and teams often need short-term progress. The problem starts when these quick fixes become the foundation of the system.

Not Every Decision Needs Heavy Architecture

But some absolutely do.

Good architects and senior engineers know how to find this balance. They know when something can be done fast and when it needs a more structured approach. They ask questions like:

Is this decision easy or painful to reverse later?
Will this create technical debt that affects core flows?
Are we introducing hidden coupling that will slow us down?
Is this a workaround, or are we building a long-term solution?

This balance is what separates sustainable architecture from a collection of short-lived patches.

Workarounds Have a Purpose, but They Also Have a Cost

A workaround can help the product move forward, validate an idea, or unblock a team. The issue is that workarounds tend to accumulate quietly. One temporary decision becomes another. That small puxadinho added today becomes tomorrow’s bottleneck.

Over time, the system becomes fragile, harder to test, difficult to refactor, and resistant to change. What was once a shortcut becomes a long-term liability.

How to Make Better Architectural Decisions

You don’t need to over-engineer everything. But you do need awareness, intention, and clarity. Some principles help:

Understand what is hard to change.
Database schemas, communication patterns, module boundaries, and API contracts deserve careful thought.
Keep documented trade-offs.
Tools like ADRs (Architecture Decision Records) help future teams understand why a decision was made.
Separate workarounds from architecture.
A workaround should always be labeled, documented, and revisited later.
Design for adaptability.
Loosely coupled components, clear interfaces, and simple boundaries reduce long-term pain.
Consider the business context.
Sometimes the right decision is the fast one, as long as everyone understands the cost.

Final Thoughts

Architecture is not about choosing the perfect pattern or technology. It is about balance, trade-offs, timing, and intention. It is knowing when a gambiarra is enough to move forward and when it is time to slow down and build the right foundation.

In the end, architecture is a continuous conversation, not a single decision. The systems we build reflect the choices we make along the way. Make them intentionally.

RESTful – Pílula 5 – Versionamento de APIs RESTful

Anderson Contreira — Fri, 28 Nov 2025 22:14:03 +0000

Com o tempo, qualquer API evolui.
Novos campos surgem, regras mudam, recursos são removidos e estruturas são reorganizadas.
Sem versionamento, qualquer mudança pode quebrar clientes que dependem daquele contrato.

Por isso, versionar APIs é essencial para garantir evolução sem interromper quem já integra com você.

Por que versionar uma API?

Porque APIs mudam — e quando mudam, você precisa garantir:

compatibilidade entre clientes antigos e novos
segurança para introduzir breaking changes
um caminho de migração previsível
documentação clara, separada por versão
estabilidade durante o ciclo de vida da API

Formas de versionamento

1️⃣ Versionamento na URL (o mais comum e explícito)

GET /v1/users
GET /v2/users

Simples, direto e fácil de documentar.

2️⃣ Versionamento por Header

Via Accept Header:

Accept: application/vnd.myapp.v1+json

Manter as URLs limpas é um benefício, mas exige maturidade maior dos clientes.

Nota: É uma opção válida, mas eu recomendo usar o caminho mais tradicional e simples que é via URL.

3️⃣ Versionamento via Query Parameter (não recomendado)

GET /users?version=2

Evite — confunde cache, roteamento e não é considerado RESTful.

Nota: Em resumo, não use!!!

Arquitetura: como manter múltiplas versões?

Dependendo do design e da maturidade do sistema, duas abordagens são comuns:

Abordagem 1 — Versões dentro da mesma aplicação

A mesma aplicação (ou monólito, ou service) contém:

código da versão 1
código da versão 2
rotas /v1 e /v2 expostas lado a lado

Esse modelo é muito comum e simples de manter quando as versões compartilham 80% da base lógica.

Prós:

facilidade de deploy
menos repositórios
menor custo infra inicial

Contras:

código mais complexo
necessidade de controle de legado dentro do mesmo código
risco de acoplamento entre versões

Abordagem 2 — Versões como aplicações totalmente separadas

Cada versão é uma aplicação distinta, com seu próprio repositório:

api-v1 (repo separado)
api-v2 (repo separado)

Essa abordagem é comum quando:

V2 é radicalmente diferente da V1
há reescrita completa
existe intenção de isolar responsabilidades

Prós:

maior isolamento
codebase mais limpa
ciclo de vida independente

Contras:

mais repositórios
mais custos operacionais
mais pipelines e infraestrutura

📌 Nota: Essa parte arquitetural será explorada em um artigo técnico dedicado.

Quando realmente criar uma nova versão?

Crie uma nova versão quando houver breaking changes, como:

mudança estrutural de payloads
renomeação ou remoção de campos
mudança na semântica dos recursos
alteração no comportamento de endpoints
mudanças que impactem clientes antigos

Adicionar novos campos não exige versão nova.

Versionamento também pode acontecer no API Gateway

Além do versionamento na aplicação, Gateways também podem cuidar disso.
É muito usado em arquiteturas de médio e grande porte.

Kong API Gateway

No Kong, é possível:

criar routes separadas para cada versão
apontar /v1/* para um upstream
apontar /v2/* para outro serviço
controlar ciclo de vida de versões facilmente

Exemplo:

/v1/ → api-v1-service
/v2/ → api-v2-service

Também permite ativar/desativar versões sem alterar a aplicação.

AWS API Gateway

No API Gateway da AWS, você pode:

usar stages para cada versão (v1, v2, v3)
mapear rotas específicas para Lambdas ou serviços distintos
versionar por deploy stage + base path mapping
ter controle fino de throttling e lifecycle por versão

É excelente para arquiteturas serverless ou híbridas.

GCP API Gateway

O API Gateway do Google permite:

criar configurações separadas de API para cada versão
publicar múltiplas versões lado a lado
usar OpenAPI specs distintas para cada release
rotear /v1/ e /v2/ para backends diferentes

Simples e direto, com boa integração ao GCP.

Exemplo prático de versionamento

Versão 1

Endpoint:

GET /v1/products/10

Resposta:

{
  "id": 10,
  "name": "Camiseta",
  "price": 39.90
}

Versão 2 (mudança estrutural)

GET /v2/products/10

Resposta:

{
  "id": 10,
  "title": "Camiseta",
  "pricing": {
    "amount": 39.90,
    "currency": "BRL"
  }
}

Resumo

Versionamento é essencial para estabilidade e evolução
O modelo mais comum é /v1/
Headers podem ser uma alternativa
Query params não são recomendados (Não faça isso)
Você pode versionar pela aplicação ou pelo API Gateway
Versionamento pode significar uma app com múltiplas versões ou apps separadas
Crie versões novas somente quando houver breaking changes

Faculdade em TI não serve pra nada...

Anderson Contreira — Thu, 27 Nov 2025 17:10:00 +0000

uma análise realista sobre carreira, ambição e futuro

A frase “não precisa de faculdade para trabalhar com TI” virou moda.
Aparece em posts, palestras, vídeos e discussões por toda parte. E sempre com o mesmo tom provocador:

“Diploma não importa.”
“A faculdade está ultrapassada.”
“O que vale é codar.”

Esse discurso parece libertador — e, em parte, ele realmente tem fundamento.
Mas a verdade é mais complexa do que isso.
Depois de anos trabalhando com empresas nacionais e internacionais, fica evidente que:

A faculdade não é tudo.
Mas também está longe de não ser nada.

O debate não é “fazer ou não fazer”.
O debate é que tipo de carreira você quer construir.

1. Sim, o mercado ficou mais flexível, mas não para tudo

De fato, muitas empresas modernas deixaram de exigir diploma. Especialmente startups, consultorias e scale-ups, onde o que importa é:

experiência real
projetos construídos
capacidade de aprender rápido
autonomia
comunicação clara

Esse cenário permite que profissionais entrem na área sem ensino superior.

Mas isso vale principalmente para:

vagas júnior
pleno
alguns casos, para sêniors, mais focados em execução técnica

Ou seja:

entrar na área sem faculdade é totalmente possível.

Crescer nela… já é outra história.

2. Para cargos de liderança, o diploma volta a fazer diferença

Quando falamos de posições como:

Tech Lead
Staff Engineer
Principal Engineer
Engineering Manager
Arquiteto de Software

…a exigência muda.

Essas funções não dependem apenas de código. Elas envolvem:

visão sistêmica
pensamento estruturado
maturidade profissional
tomada de decisão
influência e comunicação
alinhamento com estratégia de negócio
credibilidade interna

É por isso que, em muitas empresas de médio e grande porte, o diploma ainda aparece como requisito mínimo — mesmo que “desejável”.

E não porque a faculdade ensine arquitetura moderna ou práticas avançadas, mas porque o diploma transmite:

consistência
disciplina
capacidade de completar ciclos
base teórica
preparação para responsabilidades maiores

Você pode crescer sem diploma?
Sim.
Mas o teto chega mais rápido.

3. Vagas internacionais: mais exigentes do que o hype promete

Outra distorção comum é acreditar que “lá fora ninguém liga para diploma”.

Na prática, muitas vagas internacionais ainda pedem:

Bachelor’s Degree (como requisito ou forte desejável)
equivalente formal em tecnologia
histórico acadêmico validado
comprovação para processos de visto, imigração ou compliance

Isso acontece por motivos como:

padronização global de RH
exigências legais
auditorias internas
políticas de contratação
responsabilidade sobre projetos críticos

E mesmo quando o diploma não é obrigatório, ele pesa no filtro inicial.

Em resumo:
para quem mira carreira internacional, a faculdade aumenta competitividade de forma clara.

4. Faculdade e certificações comunicam investimento na carreira

Esse ponto é essencial — e raramente alguém menciona:

Tanto diploma quanto certificações enviam uma mensagem direta:

“Eu invisto em mim mesmo.”

Empresas (e clientes!) percebem isso.
Mesmo que o conhecimento técnico venha de outras fontes, o diploma reforça:

profissionalismo
comprometimento
base teórica
disciplina
credibilidade

Da mesma forma que um AWS Solutions Architect mostra entendimento em cloud,
uma graduação mostra consistência de longo prazo.

Isso não é tudo — mas é um diferencial claro.

5. Liderança exige muito além de código

Crescer em TI não é só aprofundar stack.
É desenvolver habilidades como:

gestão de projetos
gestão de pessoas
liderança
comunicação e influência
negociação
capacidade de priorização
visão de negócio

E é aí que cursos como:

pós-graduações
MBAs
cursos de liderança e gestão
PMBOK
comunicação assertiva
gestão ágil

…se tornam extremamente relevantes.

Esses temas raramente são aprendidos sozinho.
E quem domina isso simplesmente avança mais rápido.

6. “Mas eu conheço gente que cresceu sem diploma!”

Sim.
Exceções existem.
E são inspiradoras.

Mas construir sua carreira apoiada em exceções é arriscado.
O mercado, no geral, segue padrões claros — e diploma, ainda hoje, continua sendo um desses padrões para determinadas trilhas profissionais.

7. Antes de perguntar “preciso de faculdade?”, pergunte: “onde eu quero chegar?”

A resposta é simples:

Quer entrar na área? → Não precisa.
Quer crescer até pleno/sênior? → Também não.
Quer liderar, arquitetar, influenciar? → Ajuda muito — às vezes é requisito.
Quer trabalhar no exterior? → Em muitos casos, é obrigatório.
Quer competir entre os melhores? → É um diferencial forte.

Seu futuro define sua necessidade.

Conclusão

A faculdade não garante nada.
Mas dizer que “não serve pra nada” é simplificar demais uma realidade complexa.

O diploma é uma ferramenta.
Não é a única.
Mas também não é irrelevante.

E aqui vai o conselho mais prático possível:

Se puder, faça a faculdade o quanto antes — e se livre desse problema.
Se puder, faça também uma pós relevante em uma instituição decente.

Isso tira essa pendência do seu caminho e te liberta para focar nos próximos passos da sua carreira:

evoluir tecnicamente,
construir portfólio,
liderar pessoas,
desenvolver maturidade,
conquistar oportunidades melhores,
e abrir portas para o mercado global.

Não é sobre diploma.
É sobre onde você quer chegar —
e se você prefere remover barreiras ou criar novas.

Forem: Anderson Contreira

WARNING TO DEVELOPERS: A new wave of “technical test scams” is targeting devs

🚨 WARNING TO DEVELOPERS: A new wave of “technical test scams” is targeting devs — and it's getting more sophisticated

🔥 How the scam works (same pattern every time):

🧨 Real cases from the community

👉 Allan Lancioni

👉 João Pessoa

👉 Muhammad Ramadhani

⚠️ And my personal case?

🛡️ How to protect yourself (practical checklist):

✔️ 1. NEVER run npm install, yarn, or pip install on unknown projects.

✔️ 2. Be skeptical of any test sent before a real conversation.

✔️ 3. **Check the recruiter’s email and company domain.

✔️ 4. Ask for a technical explanation of the project.

✔️ 5. Use ChatGPT to analyze suspicious code.

✔️ 6. If an offer seems too good to be true… it probably is.

🚨 Final reminder: This isn’t paranoia — it’s protection.

ALERTA IMPORTANTE PARA DEVS: golpe em testes técnicos está crescendo - fiquem espertos

🚨 ALERTA IMPORTANTE PARA DEVS: golpe em “testes técnicos” está crescendo (e cada vez mais sofisticado)

🔥 Como o golpe funciona (sempre o mesmo padrão):

🧨 Casos reais analisados (dos artigos citados):

👉 Allan Lancioni

👉 João Pessoa

👉 Muhammad Ramadhani

⚠️ E o meu caso pessoal?

🛡️ Como se proteger (de forma prática):

✔️ 1. Nunca rode npm install, yarn ou pip install em projetos enviados por desconhecidos.

✔️ 2. Desconfie de qualquer teste enviado antes de uma call real com o recrutador.

✔️ 3. **Pesquise o nome do recrutador e da empresa.

✔️ 4. Peça para o entrevistador explicar o projeto em call.

✔️ 5. Lembre que ChatGPT pode ajudar.

✔️ 6. Se parecer bom demais… desconfie.

🚨 Resumo final: isso não é exagero — é prevenção.

Planejamento de carreira: ou você assume o volante, ou vira passageiro da própria vida

1. O tempo não espera — e sua carreira também não

2. Ambição e Planejamento Pós-Primeira Chance

3. Entregar tudo e não receber nada? Então pare de insistir.

4. O peso da vida pessoal (e por que ela congela carreiras)

Quando você estuda antes:

Quando estuda depois de casar e ter filhos:

5. Seu Nome é Seu Ativo Mais Valioso: O Peso das Finanças.

6. Estudos: Não é só aprender, é se manter na jornada.

7. Liderança: Assusta, mas paga a conta.

8. O Plano Prático (que realmente funciona)

📌 1. Todo fim de ano, monte sua lista do próximo ano

📌 2. Revise e priorize a lista ao longo do ano

📌 3. Tenha uma ferramenta para gestão financeira

Conclusão: carreira é planejamento — não sorte

RESTful – Pílula 6 – Paginação, Filtros e Ordenação em APIs REST

Por que isso é importante?

Paginação – Os padrões mais utilizados

1. Modelo baseado em page / limit

2. Modelo baseado em offset / limit

3. Cursor-based pagination

Filtros — Consultas mais flexíveis

Seleção de campos (fields)

Validação do fields

Erro recomendado para campos inválidos

Notas importantes sobre segurança e padronização

Sobre o código interno (code = 32)

Sobre o label

Sobre o campo trace

Sobre o campo details

Ordenação (sorting)

1. Padrão com prefixo "-"

2. Padrão sort + order_by (mais explícito)

Combinando tudo em uma única consulta

Boas práticas gerais

Resumo

Don’t Limit Yourself: Why Broadening Your Tech Horizons Keeps You Relevant

Why “Don’t Limit Yourself” Matters More Than Ever

From Coding to DevOps

Adding Machine Learning to Your Toolbox

Front End, Back End, Databases, Full Stack or All of the Above

How to Expand Your Skills Without Losing Focus

Final Thoughts

Por que o plano de carreira virou exceção, e como isso afeta a entrada de novos profissionais no mercado

A permanência nas empresas mudou

Automação elevou ainda mais a exigência para quem está começando

Dentro das empresas, o problema continua: falta estrutura de crescimento

✔️ 1. NEVER run `npm install`, `yarn`, or `pip install` on unknown projects.

✔️ 2. **Be skeptical of any test sent before a real conversation.**

✔️ 1. Nunca rode `npm install`, `yarn` ou `pip install` em projetos enviados por desconhecidos.