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. Middle: compreensão mais profunda, otimização e situações reais de trabalho.
O Ruby procura na classe singleton do objeto, depois nos módulos prepended, depois na própria classe, depois nos módulos included em ordem reversa de inclusão, depois sobe para a superclasse, e repete. SomeClass.ancestors imprime a ordem real, o que resolve a maioria das discussões mais rápido do que raciocinar sobre isso. super continua por essa mesma cadeia a partir de onde você está.
preload carrega a associação em uma segunda consulta. eager_load usa um único LEFT OUTER JOIN. includes escolhe por você, mudando para um join quando você referencia a associação num where. Use includes por padrão, e recorra aos outros dois quando precisar forçar a estratégia — geralmente porque o join está duplicando linhas ou a segunda consulta é mais barata.
Comece pelos logs e pelo número de consultas, não lendo código — a maioria dos endpoints lentos no Rails são problemas de consulta. Procure N+1, um índice faltando atrás de um where numa tabela grande, e trabalho que não precisa estar no request de jeito nenhum. EXPLAIN diz se o índice está realmente sendo usado. Caching é o que você faz depois disso, não no lugar disso.
Você indexa as colunas pelas quais filtra e ordena, e para um índice de múltiplas colunas a ordem importa — ele pode atender um prefixo de suas colunas, não qualquer subconjunto. Um índice não ajuda quando a consulta toca a maior parte da tabela de qualquer forma, e custa a cada escrita, então indexar tudo é um problema por si só. Um LIKE '%x' com coringa no início não pode usar um índice B-tree comum de jeito nenhum.
Porque um job pode rodar duas vezes — um retry depois de um timeout, um crash depois do trabalho mas antes da confirmação. Se rodar duas vezes cobra o cartão duas vezes, isso é um bug do job, não da fila. Você torna isso seguro associando o efeito a uma chave: verifica se a cobrança já existe, usa um índice único, ou torna a operação naturalmente repetível.
Você extrai o comportamento que não é sobre o próprio estado do registro — um service object para uma operação de vários passos, um query object para um scope complexo, um form object quando um formulário abrange dois models. O modo de falha nas duas direções é real: um model de 900 linhas que ninguém consegue tocar, ou quarenta classes de um método só sem um lugar óbvio. O teste é se uma pessoa nova consegue encontrar o código pelo nome.
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 Middle Ruby on Rails →