Executando verificação de segurança...
-7

Linguagem não é ferramenta. Framework sim!

O equívoco sobre profundidade técnica nas entrevistas de tecnologia

Nos últimos anos, uma frase vem se repetindo em posts e discussões de tecnologia:

“Profundidade técnica não é dominar sintaxe, é entender fundamentos.”

Essa afirmação soa bonita, mas esconde um equívoco grave: tratar linguagem de programação como se fosse uma ferramenta descartável, quando na verdade ela é o núcleo que conecta fundamentos de computação ao hardware.

Frameworks mudam o tempo todo. Linguagens, não.


Linguagem: um núcleo estável

Linguagens de programação existem há décadas com mudanças incrementais, mas mantendo um núcleo estável:

  • C (anos 70) continua sendo a base de sistemas operacionais e compiladores.
  • Java (1995) segue firme em aplicações corporativas, com quase 30 anos de evolução.
  • JavaScript (1995) ainda move a web, apesar de todos os frameworks que nasceram e morreram ao seu redor.
  • Ruby (1995) ainda está na base de milhares de sistemas críticos, mesmo após ondas de “novas modas”.

Elas não são “ferramentas de moda”. São o idioma universal no qual construímos software.
É nelas que os fundamentos de computação — estruturas de dados, concorrência, compilação, alocação de memória — ganham forma concreta.
Mas as pessoas esquecem que por trás de um sistema, existe um hardware que precisa manter um padrão de comunicação com a linguagem.


Framework: uma ferramenta descartável

Frameworks, sim, são ferramentas que mudam constantemente:

  • Rails já foi dominante, depois perdeu espaço.
  • Angular já teve duas reescritas quase completas.
  • React (2013) hoje é onipresente, mas pode ser substituído amanhã.
  • Spring Boot, Next.js, NestJS… todos seguem a mesma lógica: ferramentas úteis, mas efêmeras.

Frameworks são como andaimes numa obra: ajudam a construir mais rápido, mas não fazem parte da estrutura final.


O idealismo perigoso

Quando alguém diz que “profundidade técnica” é apenas fundamentos (algoritmos, estruturas de dados, teoria), está caindo em duas armadilhas:

  1. Confundir teoria com prática.

    • É como um engenheiro que entende cálculo estrutural, mas nunca foi até a obra.
    • No papel, tudo parece perfeito. Mas no terreno existe um córrego escondido ou uma estrutura vizinha que compromete o empreendimento.
    • Só quem domina a prática da linguagem vai perceber e saber adaptar.
  2. Desprezar a linguagem.

    • Achar que basta conhecer fundamentos e que “qualquer linguagem serve” é ignorar que cada linguagem tem particularidades que impactam arquitetura, performance e até segurança.
    • Garbage collection do Java, ponteiros do C, tipagem dinâmica do Ruby, event loop do JavaScript… são detalhes críticos que nenhum framework resolve.

O que realmente deve ser avaliado em entrevistas?

O erro não está em cobrar conhecimento técnico. O erro está em cobrar o que não importa.

  • Avaliar frameworks → mede decoreba.
  • Avaliar só fundamentos genéricos → mede abstração sem prática.
  • Avaliar linguagem + fundamentos → mede profundidade técnica real.

Quem domina a linguagem consegue:

  • Criar frameworks.
  • Criar novas linguagens.
  • Adaptar-se a ferramentas novas.
  • Aplicar fundamentos de computação no mundo real.

Conclusão

Linguagem não é ferramenta. Framework sim.
Frameworks vêm e vão, mas linguagens permanecem como a base que conecta software e hardware.

Profundidade técnica não é teoria sem prática, nem decoreba de frameworks.
É fundamentos + domínio da linguagem aplicados em problemas reais.

E na prática, isso faz toda a diferença:

  • O engenheiro que nunca foi ao canteiro de obras projeta uma ponte perfeita no papel, mas que desaba ao encontrar o terreno.
  • O programador que só decora teoria projeta soluções bonitas, mas que travam na primeira limitação real da linguagem.

Daí vem o dilema de muitos novos desenvolvedores que querem que o mundo se adapte a sua preguiça de entender o core de uma linguagem.
Entender os fundamentos da computação sempre foi essencial para qualquer desenvolvedor desde o início da internet, mas isso não significa que deva ser a única coisa cobrada em entrevistas técnicas, isso é o básico e mínimo do mínimo.

Ah... mas existe IA hoje em dia, ninguém precisa saber de linguagem; - Errado!
Se você não sabe o que uma linguagem possui em seu core, como vai saber se o que a IA está te entregando é o melhor para aquele contexto de projeto?
Empresas buscam especialistas em uma linguagem justamente pelo conhecimento profundo nela e em seu ecossistema, isso garante não só performance da equipe (que não ficará perguntando pra que serve um .sort() para IA), mas também reduz o gargalo de treinamento que engenheiros seniores terão que explicar porque quadrado não cabe na bolinha e evitará problemas de segurança que alguém que não conhece a linguagem irá construir com gambiarras que a linguagem já tem um caso de uso específico para aquilo.

Fundamentos são em maioria para pessoas que querem passar em matérias de faculdade e entrar em startup fundada por alguém sem conhecimento técnico, que não enxerga os débitos técnicos futuros.

Nessa onda hypada de lançarem inúmeros SaaS com IA, a galera confunde que isso não passa de uma bolha e que não irá se manter por muito tempo.
O salário tem despencado por essa onda, mas em breve, apenas especialistas serão procurados para tratar problemas ocasionados por pessoas que estão hipnotizadas dentro dessa bolha.

  • O programador que só decora teoria projeta soluções bonitas, mas que travam na primeira limitação real da linguagem, são os mesmos que defendem nas redes sociais essa abordagem de que basta saber fundamentos da computação e não conseguem ficar sequer 3 meses em uma empresa por ter passado apenas decorando palavras bonitas e não saber lidar com a pressão de resolver um bug em produção às 03:00 am de um feriado.

Profundidade técnica de verdade é saber a teoria, a linguagem e a prática.
O resto é idealismo.

Carregando publicação patrocinada...
4

Vou colocar alguns pensamentos soltos que tive ao ler seu texto, não é um texto organizado e estruturado


Existem alguns pontos no seu texto que não casam muito bem, como os exemplos abaixo:

Quem domina a linguagem consegue:

- Criar frameworks.
- Criar novas linguagens.
- Adaptar-se a ferramentas novas.
- Aplicar fundamentos de computação no mundo real.

Fundamentos são em maioria para pessoas que querem passar em matérias de faculdade e entrar em startup fundada por alguém sem conhecimento técnico, que não enxerga os débitos técnicos futuros.

Fundamentos não são apenas para passar na faculdade, sem entender e saber aplicar os fundamentos em diferentes contextos é que você se torna refém de decoreba. Boa parte do seu texto vai nesse sentido, mas no final mistura tudo e fica confuso.


Apesar de linguagens de programação não serem APENAS ferramentas, elas são sim ferramentas. O que as coloca nessa categoria é o uso que você faz delas, você tem um problema e usa uma linguagem de programação para resolver, então a linguagem e todo que foi utilizado (libs, frameworks, servidores, serviços, bancos de dados, outros softwares, hardware, o café que você tomou...) são todos ferramentas nesse contexto.


O que eu mais me deparo pela internet afora, são pessoas desprezando o entendimento de fundamentos, a maior parte dos mais jovens nesse mercado acreditam que SOLID, Clean Arch, DDD etc são fundamentos e que são aplicáveis em qualquer contexto, quando na verdade são apenas recomendações que precisam ser avaliadas antes de serem consideradas no contexto.

Se perguntarem para eles se é melhor uma paradigma de orientação a objetos ou procedural, ele vão responder orientação a objetos na mesma hora sem nem ouvir qual é o projeto, apenas porque decoraram que o melhor é isso, e quando a gente vai olhar para seus códigos a essência de OO quase não existe, é basicamente um código procedural escrito usando classes (anêmicas, aninhadas, God Classes, altamente acopladas sem inversão ou injeção de dependências...).

É aquela história que "para martelo tudo é prego", e as vezes ele tá com um grifo na mão para fazer o papel de martelo.


Outra questão a se considerar é que o entendimento dos fundamentos da programação não deve estar atrelado ao entendimento de alguma linguagem de programação e vice-versa. Mas o casamento desses conhecimentos é o que te permite criar softwares.


Na questão de se tornar um profundo entendedor de uma linguagem, eu acho interessante, mas apenas depois de você já ter se consolidado no mercado sabendo aplicar minimamente bem 2 ou 3 linguagens diferentes.

Vi muita gente que teve que "rebolar" quando o ASP Clássico foi abandonado ou quando o Steve Jobs condenou o Flash (ActionScript) à morte. Pois eram altamente especializados nessas linguagens e ignoraram todo o resto, pois pagavam muito bem na época.

É claro que existem empresas que buscam profissionais altamente proficientes em determinadas ferramentas, mas essas vagas raramente são para quem estão começando na carreira.


Como disse, são apenas pensamentos soltos com base no seu texto.

3

Frameworks mudam o tempo todo. Linguagens, não.

Acredito que esse seja o conceito mais errado do texto todo. Procure uma base em PHP 6 e outra em PHP 8.

São 2 linguagens diferentes

Pegue uma base em .NET Framework e .NET Core

São 2 linguagens diferentes

Pegue uma base em Java 6 e Java 21

São 2 linguagens diferentes

A linguagens de programação mudam o tempo todo, assim como os frameworks, surgem técnicas novas e a tecnologia como um todo precisa se adaptar.

Edit:

C (anos 70)

Ganhou revisões em 99 (C99), 2011 (C11), 2018 (C17), 2024 (C23)

Sim, o C está em evolução até hoje

1

Olá @Pilati, obrigado por trazer esses pontos para a discussão. Seus exemplos, na verdade, reforçam a tese central do meu artigo.
O que tu trouxe foi exatamente a falta de diferenciação técnica que estou tentando abordar para novatos entenderem de onde vem e se aplicam os fundamentos.
Colocar tudo no mesmo "saco de ferramentas", conceitos que operam em camadas completamente diferentes da computação é fundamentalmente incorreto.

Java 6 e Java 21, dizer que são "duas linguagens diferentes" é um erro profundo. Java 21 é a evolução da mesma linguagem. Ele introduz conceitos poderosos como Virtual Threads, Records e Pattern Matching, mas o faz sobre a mesma fundação: a JVM, o mesmo modelo de objetos, a mesma sintaxe base e, crucialmente, um altíssimo grau de retrocompatibilidade. Um desenvolvedor Java 6 se tornaria um desenvolvedor Java 21 infinitamente mais rápido do que aprenderia Rust ou Go. A base é a mesma.

PHP 6 e PHP 8 a mesma lógica se aplica aqui. O PHP 8 modernizou a linguagem com um sistema de tipos mais forte, JIT compiler, etc. Foi uma evolução massiva e necessária, mas ainda é PHP. Não é uma linguagem nova.

A confusão começa ao chamar ".NET" de linguagem. .NET é uma uma plataforma/ecossistema, C# é a linguagem.
Confundir os dois é como como confundir a rodovia com o carro. Meu ponto é que a "rodovia" (.NET) pode ser reconstruída, mas o "carro" (C#) apenas evolui, mantendo sua essência.

Da mesma forma, dizer que Java 6 e Java 21 são "linguagens diferentes" é como dizer que o portugês de 1980 e o de 2025 são idiomas diferentes. Não são. É uma evolução sobre um núcle estável, não uma substituição, que é o que acontece o tempo todo com frameworks.

A estabilidade que menciono das linguagens não significam que elas sã
o estáticas, mas que seu núcleo paradigmático e sintático é estável. As mudanças são, em sua maioria, incrementais e adicionais.

Compare isso com a mudança de um framework: migrar um projeto de Angular.js (v1) para Angular (v2+) não é uma evolução, é uma reescrita completa. A filosofia mudou, a arquitetura mudou, a linguagem (de JavaScript para TypeScript como padrão) mudou. Isso sim é uma "ferramenta diferente".

A transição de .NET Framework (legado, focado em Windows) para .NET Core (moderno, multiplataforma) foi uma mudança na plataforma, no "andaime". A linguagem C# evoluiu junto com essa mudança, mas ela continuou sendo C#.

Já o fato do "C" uma linguagem de 50 anos evoluir através de revisões padronizadas e incrementais, mantendo um núcleo tão estável que código de décadas atrás ainda é relevante, prova que ela é um alicerce sólido.
Ninguém está reescrevendo o kernel do Linux a cada 5 anos porque "surgiu um framework de C mais novo". As mudanças são cuidadosamente adicionadas a uma base sólida.

Espero que isso ajude a esclarecer a minha tese. A estabilidade de aprendizado com foco na linguagem quanto as entrevistas de emprego vs devs quererem usar apenas fundamentos, é o que estou tentando restaurar: um vocabulário técnico básico que parece estar se perdendo por não haver mais quem oriente num nível técnico mais profundo, criando superficialidade na nossa comunidade que cria um débito técnico nas pessoas e geram frustrações em processos seletivos que exigem conhecimento em uma linguagem mas só estudaram fundamentos.