As entrevistas de Ruby seguem duas camadas: a própria linguagem — blocks, módulos, a cadeia de busca de métodos — e depois o Rails, onde a maioria das perguntas na verdade é sobre Active Record e o banco de dados por trás dele. Aqui estão as perguntas mais frequentes, cada uma com uma resposta modelo. Senior: arquitetura, trade-offs, mentoria e tomada de decisão.
Assuma que a tabela fica bloqueada durante o statement, e planeje a mudança para que isso não aconteça. Adicione colunas como nullable sem um default, faça o backfill em lotes fora da migration, adicione índices de forma concorrente, e só depois adicione a restrição. Renomear e remover são os casos perigosos porque código antigo continua rodando durante o deploy — faça isso em duas releases com uma escrita dupla no meio.
Trace os limites antes de extrair qualquer coisa — geralmente ao longo das partes do domínio que mudam juntas. Force-os primeiro dentro do mesmo codebase, com módulos ou engines e sem acesso a banco entre limites, que é onde você descobre quase de graça que o limite estava mal traçado. Extrair um serviço é o último passo, não o primeiro, e só vale a pena quando um time ou uma necessidade real de escala exige.
Ela se paga numa biblioteca pequena onde elimina uma quantidade grande de repetição — define_method sobre uma lista de atributos está ótimo. Ela custa no ponto em que alguém busca o nome de um método e não encontra nada, ou onde um typo vira um nil silencioso porque method_missing engoliu. Se você define method_missing, defina respond_to_missing? junto, senão o objeto mente sobre o que pode fazer.
Você faz cache do que é caro e estável, e só depois que a consulta já estiver tão boa quanto possível — caching não conserta um N+1, é uma forma de escondê-lo até o cache falhar. Decida a invalidação antes do caching: uma chave que inclui updated_at expira sozinha, enquanto uma limpeza manual é o que será esquecido. Dados errados em cache são piores que uma página lenta.
Primeiro coloque a suíte de testes num estado honesto, porque a atualização só é tão segura quanto o que ela consegue te dizer. Depois avance uma versão menor por vez, resolva os avisos de depreciação antes que virem erros, e mantenha a aplicação rodando na versão antiga e na nova na mesma branch onde o framework permitir. A parte que as pessoas subestimam são as gems: o bloqueio geralmente é uma dependência sem manutenção, não o Rails em si.
Numa entrevista de verdade você fala sob pressão. O Cam faz essas mesmas perguntas, avalia cada resposta e mostra exatamente o que melhorar.
Praticar entrevista de Senior Ruby on Rails →