Por que um banco de perguntas acelera a preparação para entrevistas Rust
Passar em uma entrevista de Rust não depende apenas de conhecer a sintaxe. O que diferencia candidatos é a capacidade de explicar decisões: por que um trecho compila, por que o borrow checker reclama, quando usar Arc em vez de Rc, quando Box é suficiente, quando um erro deveria parar a aplicação ou ser tratado como dado de domínio. Um roteiro estruturado de perguntas ajuda a transformar conhecimento espalhado em respostas rápidas e coerentes — exatamente o que a entrevista técnica exige sob pressão.
Este artigo reúne 35 perguntas frequentes em entrevistas de Rust, organizadas por tema, com respostas comentadas e referências cruzadas para os materiais do site. Use-o como simulado: leia a pergunta, tente responder em voz alta e só depois compare com a resposta. Quem está começando pode combinar este banco com o nosso guia de entrevista para backend e com o plano de estudos para pleno, que conectam os conceitos a projetos práticos. Para quem busca vagas Rust agora, vale treinar também perguntas comportamentais e de currículo focado em Rust.
Ownership e borrow checker
1. O que é ownership em Rust e por que existe?
Ownership é o conjunto de regras que define quem é dono de cada valor na memória, quando o valor é liberado e como ele pode ser emprestado. Existe para garantir segurança de memória sem coletor de lixo: o compilador prova, em tempo de compilação, que não haverá acesso a memória liberada, double free nem data race. O custo é um conjunto de restrições que o desenvolvedor aprende a respeitar — e que, com o tempo, vira intuição sobre design de API.
2. Qual a diferença entre String e &str?
String é um tipo owned: dono do buffer na heap, crescível, alocado e liberado quando sai de escopo. &str é uma referência (fat pointer) para uma sequência de bytes UTF-8 que pode estar na heap, no binário ou emprestada de uma String. A regra prática: funções que só leem texto recebem &str; tipos que precisam possuir e modificar o texto usam String. Isso evita cópias desnecessárias e torna APIs mais flexíveis.
3. O que significa “move” e quando acontece?
Mover significa transferir a propriedade de um valor para outro vinculado. Em tipos sem o traço Copy (como String, Vec, HashMap), uma atribuição ou passagem por valor move o original: depois disso, o vinculo antigo não pode mais ser usado. Isso previne double free. Quando se quer manter o valor acessível em dois lugares, usa-se empréstimo (& e &mut) ou tipos de posse compartilhada como Rc e Arc.
4. Quais são as três regras do borrow checker?
Primeira, pode haver várias referências imutáveis (&T) ao mesmo tempo. Segunda, pode haver exatamente uma referência mutável (&mut T) e nenhuma imutável simultânea. Terceira, referências sempre devem apontar para dados válidos — nunca para memória liberada. Essas regras evitam data races e dangling pointers em tempo de compilação, sem custo de runtime.
5. Quando o compilador reclama de “cannot borrow as mutable because it is also borrowed as immutable”?
Isso ocorre quando existe uma referência imutável viva ao mesmo tempo em que se tenta criar uma mutável. A solução depende do caso: encerrar o uso da referência imutável antes da mutável (o NLL — Non-Lexical Lifetimes — já reduz muito esse problema), reestruturar o dado para não precisar dos dois empréstimos ao mesmo tempo, ou separar a mutação em uma função que recebe &mut por inteiro.
Lifetimes
6. O que é lifetime e por que ela aparece na assinatura de funções?
Lifetime é uma anotação que descreve por quanto tempo uma referência é válida em relação às outras. O compilador precisa provar que toda referência retornada por uma função não aponta para memória que morreu. Na maioria dos casos o lifetime é elided ( Lifetime Elision), mas quando a relação de entrada/saída é ambígua, escrevemos <'a> para explicitar a ligação. Ver lifetimes em profundidade.
7. Quando lifetimes explícitas aparecem em structs?
Quando um struct guarda uma referência (e não um tipo owned), é preciso declarar o lifetime para que o struct não sobreviva aos dados que ele aponta. Por exemplo, struct Parser<'a> { input: &'a str } diz que o Parser não pode viver mais que o input. Sempre que possível, prefira tipos owned (String, Vec) em structs; use referências com lifetime apenas quando há um ganho claro de memória e o dono do dado é claro.
8. O que é 'static e quando usar?
'static indica que a referência é válida por toda a execução do programa — típicos de literais de string e globais. Não é uma boa ideia usar 'static como “saída mágica” para erros de lifetime em funções comuns: isso restringe quem pode chamar a função. Use 'static conscientemente, em caches de processo, dados embutidos no binário ou bounds de threads spawnadas.
Traits e generics
9. Qual a diferença entre trait object e generics (monomorfização)?
Generics com impl Trait ou <T: Trait> geram uma versão de código para cada tipo concreto usado — monomorfização, com desempenho máximo ao custo de binário maior. Trait objects (dyn Trait) usam despacho dinâmico via vtable, permitindo coleções heterogêneas a um pequeno custo de indireção. A regra: performance crítica e tipos conhecidos em tempo de compilação favorecem generics; coleções de tipos variados ou extensibilidade via plugins favorecem dyn.
10. Quando usar impl Trait em posição de argumento vs. retorno?
impl Trait em argumento é açúcar para um generic (fn f(x: impl Trait) equivale a fn f<T: Trait>(x: T)). Em posição de retorno, -> impl Trait permite devolver tipos concretos complexos (inclusive impl Future) sem nomeá-los, o que é essencial para async e para tipos como iteradores encadeados. Em retorno, no entanto, você só pode devolver um único tipo concreto.
11. O que é o traço Clone e como difere de Copy?
Copy é uma promessa de cópia trivial (bitwise) que acontece implicitamente em atribuições, aplicável apenas a tipos sem posse de heap (como números, chars, tuplas de Copy). Clone é a capacidade explícita de duplicar o valor chamando .clone(), podendo envolver alocação. Todo Copy deve implementar Clone, mas a recíproca não vale. Tipos com buffers (String, Vec) implementam Clone, nunca Copy.
12. O que são traits associadas (associated types) e quando preferi-las?
Associated types (type Item; dentro de um trait) descrevem um tipo de saída que existe uma única vez por implementação do trait — diferente de generics, que poderiam gerar várias implementações. Iterator usa associated type Item: para cada tipo concreto de iterador, há um único Item. Use associated types quando a relação entre o tipo e o trait determina unicamente o tipo auxiliar; use generics no trait quando faz sentido haver várias implementações no mesmo tipo.
Tratamento de erros
13. Por que Rust usa Result em vez de exceções?
Exceções introduzem caminhos de controle implícitos: qualquer chamada pode saltar longe, dificultando o raciocínio sobre limpeza e fluxo. Result<T, E> torna o erro parte do tipo de retorno, forçando o chamador a lidar com ele. Com o operador ? o código fica conciso sem perder explicitude. O resultado é que erros ficam visíveis nas assinaturas e o compilador ajuda a garantir tratamento. Veja tratamento de erros em profundidade.
14. Quando usar Option vs Result?
Option modela ausência legítima: um valor que pode ou não existir, sem que isso seja um erro (HashMap::get, primeiro elemento de uma lista vazia). Result modela uma operação que pode falhar: leitura de arquivo, requisição de rede, parse. A confusão surge quando ausência vira erro de domínio; nesse caso, Result comunica melhor a intenção. Reutilize tipos de erro específicos em vez de strings soltas.
15. O que é Box<dyn Error> e por que evitar em bibliotecas?
Box<dyn Error> é um atalho para “qualquer erro”, útil em scripts rápidos. Em bibliotecas e serviços, porém, ele apaga informações: o chamador não consegue distinguir falha de rede de falha de parse, dificultando retentativa, logging estruturado e mensagens claras. Defina um enum de erro com thiserror em bibliotecas e use anyhow em aplicações binárias, conforme detalhado em bibliotecas de error handling.
16. Como propagar contexto ao usar ??
Encadeie .map_err() ou use anyhow::Context para adicionar contexto: fs::read(path).context(format!("lendo {path:?}"))?. Assim o erro final carrega uma trilha de mensagens que explica onde falhou, mesmo mantendo a causa original. Em produção, esse contexto é o que diferencia um alerta útil de um stacktrace obscuro.
Async e concorrência
17. Qual a diferença entre async fn e uma função síncrona?
async fn não executa imediatamente: ela devolve um Future, uma máquina de estados que só progride quando um executor a faz avançar. Isso permite milhares de tarefas concorrentes em poucas threads. O custo é que o código precisa rodar dentro de um runtime (Tokio, async-std) e nem toda biblioteca é compatível. Para concorrência e I/O de alta escala, async costuma valer a pena.
18. Quando usar tokio::spawn em vez de join?
tokio::spawn cria uma tarefa independente, que roda em paralelo com quem a chamou; é adequado para trabalho que continua mesmo se o chamador terminar (servidores, workers). join (ou join_all, FuturesUnordered) espera as tarefas terminarem juntas, sem torná-las independentes. Use spawn quando há ciclo de vida próprio e join quando a operação faz parte de um passo sincronizado.
19. O que é Send e Sync e por que importam em async?
Send diz que um tipo pode ser movido entre threads com segurança; Sync diz que várias threads podem compartilhar &T. Executores como Tokio movem tarefas entre threads de trabalho, então futures devem ser Send. Erros comuns incluem segurar um Rc (não Send) dentro de uma future spawnada, ou um Mutex de std que pode bloquear o runtime. Para dados compartilhados em async, prefira Arc<tokio::sync::Mutex> ou canais.
20. Como evitar deadlock com mutex em Rust?
Deadlock clássico acontece quando duas tarequivos seguram locks e esperam uma pela outra. Em Rust, evite segurar múltiplos locks ao mesmo tempo; quando precisar, adquira sempre na mesma ordem. Em async, evite std::sync::Mutex dentro de .await (pode bloquear a thread inteira); use tokio::sync::Mutex ou projete para que o lock seja curto e síncrono. Canais (mpsc) costumam resultar em código mais simples que mutex compartilhado.
21. Qual a diferença entre Arc e Rc?
Rc é contagem de referências single-threaded: leve, mas não Send. Arc (atomic) é seguro para múltiplas threads. A regra: se o dado pode migrar entre threads (especialmente em async), use Arc. Para caches locais de uma única thread, Rc economiza overhead atômico. Misturar os dois por engano é um erro recorrente em entrevistas.
Sistema de tipos e padrões
22. O que é PhantomData e quando aparece?
PhantomData<T> é um tipo sem custo de runtime que marca para o compilador uma relação com T — útil em structs genéricos que não armazenam T diretamente mas precisam ser tratados como se armazenassem, por exemplo para lifetimes, variance ou drops. Aparece em wrappers de tipos seguros, builders e em tipos que codificam estados via type-level programming.
23. Como modelar uma máquina de estados invalidável pelo compilador?
Use o pattern typestate: cada estado é um tipo, e transições só existem como métodos que consomem self e devolvem o próximo estado. Assim é impossível chamar send() antes de connect(), porque o tipo em connect() consome o anterior. Isso elimina categorias inteiras de bugs e é um argumento frequente para escolher Rust em sistemas críticos.
24. O que é o pattern newtype e por que é útil?
newtype envolve um tipo primitivo em uma struct de um campo (struct UserId(u64);) para dar identidade semântica e impedir misturas (UserId e OrderId não são intercambiáveis mesmo sendo ambos u64). Permite implementar traits específicas, controlar conversões via From/Into e documentar invariantes. É barato (zero-cost) e melhora muito a legibilidade de domínios.
25. Quando usar macros em vez de funções?
Macros são adequadas quando a tarefa não pode ser feita por função: gerar código em tempo de compilação (vec!, println!), criar itens (macro_rules que define structs), repetir padrões com variabilidade sintática, ou implementar traits automaticamente (#[derive]). Para lógica de runtime, prefira funções, que são mais legíveis e tipáveis. Veja macros declarativas e procedurais.
Coleções, iteradores e performance
26. Como funciona a avaliação preguiçosa em iteradores?
Iteradores em Rust são lazy: o encadeamento iter().map().filter() apenas monta uma pipeline; nada executa até um consumidor (collect, sum, for). Isso permite otimizações (zero-cost abstractions) e evita alocações intermediárias. O compilador frequentemente elimina overhead, tornando iteradores comparáveis a loops manuais — e mais expressivos.
27. Quando collect() em HashMap vs. um loop com insert?
collect() é idiomático e conciso quando você já tem um iterador de pares. Um loop com insert é melhor quando a chave precisa de tratamento (conflito, default, agregação) ou quando o tamanho final não é previsível. Em código de hot path, meça: às vezes pré-alocar com with_capacity e usar loop evita realocação. Ver iteradores em profundidade.
28. Como medir performance de um trecho Rust?
Comece com benchmarks estáveis (criterion), perfis com perf ou cargo flamegraph, e compare versões com cargo bench. Evite otimizar antes de medir — o compilador e o LLVM já eliminam muito overhead. Para detalhes de otimização de performance, lembre-se que cache locality e alocações costumam pesar mais que micro-otimizações de aritmética.
Cargo, testes e tooling
29. O que é cargo workspace e quando adotar?
Workspace agrupa múltiplos crates que compartilham Cargo.lock e target/, acelerando builds e garantindo versões consistentes em monorepos. Adote quando há vários binários/bibliotecas relacionados, dependências compartilhadas ou times que coordenam releases. Veja o guia sobre cargo workspaces e monorepos.
30. Como estruturar testes em Rust?
Testes de unidade ficam em #[cfg(test)] mod tests dentro do próprio arquivo. Testes de integração vão em tests/, como crates externos que dependem do seu crate. Use #[test] e assert_eq!, e para casos parametrizados considere crates como rstest. Para serviços, combinar testes de unidade com testes de integração contra containers é a configuração mais robusta.
31. Quando usar feature flags em uma biblioteca?
Feature flags isolam funcionalidades opcionais para reduzir dependências e tempo de compilação para quem não precisa delas (por exemplo, suporte opcional a serde ou a um driver específico). Defina features pequenas e composicionais, documente a matriz de compatibilidade e evite features mutuamente exclusivas. Erros comuns: features que quebram a API pública ou que dependem de ordem de ativação.
Carreira e perguntas comportamentais
32. Como responder “Por que Rust?” em uma entrevista?
Conecte Rust à experiência concreta: fale de um bug de memória que ela evitaria, de um serviço onde performance e segurança importavam, de um refactor que ficou mais simples com tipos. Evite slogans como “Rust é a melhor linguagem”; entrevistadores valorizam quem sabe descrever trade-offs e citar limitações honestamente. Relacione com o guia de carreira Rust 2026.
33. O que responder quando perguntarem sobre um projeto Rust fracassado?
Escolha um caso real onde aprendeu algo: descreva o objetivo, a decisão que não funcionou, como detectou, o que mudou e o que levaria para o próximo projeto. A estrutura “situação, decisão, consequência, aprendizado” comunica maturidade. Entrevistadores buscam senioridade na forma como você lida com erro, mais do que sucesso linear.
34. Como demonstrar senioridade Rust sem ter trabalhado oficialmente com a linguagem?
Mostre projetos pequenos e operáveis: uma API com Axum, um worker com fila, uma CLI com testes, um README que explica decisões. Contribuições para projetos open source contam — veja contribuição open source. O sinal forte é código que roda, trata erro e explica por que foi feito assim. Para o passo a passo, leia sobre transição para Rust.
35. O que perguntar ao entrevistador em uma vaga Rust?
Pergunte sobre o uso real da linguagem: partes do sistema que são Rust, versão adotada, cadência de upgrade, revisão por pares, testes, observabilidade e onboarding de quem não conhece a linguagem. Essas perguntas revelam maturidade do time e demonstram que você pensa como engenheiro, não apenas como candidato. Compare as respostas com o nosso panorama de empresas que usam Rust e com as vagas abertas.
Como usar este banco de perguntas na prática
A melhor forma de aproveitar este material é transformar leitura em prática. Separe as perguntas por tema, dedique sessões curtas e recorrentes, e escreva pequenos programas para confirmar cada resposta. Para cada conceito que travar, busque o artigo profundo correspondente — ownership e borrowing, tratamento de erros, async com Tokio — e construa um exemplo mínimo. Quem combina leitura com código tende a reter melhor e a responder com segurança sob pressão.
Depois de cobrir as 35 perguntas, simule uma entrevista completa com um colega ou gravando a si mesmo, cronometrando o tempo de resposta e prestando atenção a trechos que ficam vagos. Esses trechos são sinais de onde revisitar. Para quem busca primeiro emprego Rust ou quer acelerar a transição de carreira, simulados estruturados costumam ser o diferencial entre avançar ou ficar na fila. Boa preparação — e até nas vagas.