Entrevista técnica com dev Magento 2: as perguntas e o que a boa resposta contém

Como avaliar conhecimento de Magento sem saber programar

Você não precisa entender cada detalhe da resposta. Precisa conferir se ela toca os pontos listados em cada pergunta e pedir um exemplo: "quando foi a última vez que você fez isso, e o que deu errado?". Quem trabalhou em produção responde com caso, risco e consequência. Quem decorou responde com definição.

Cada pergunta leva nota de 0 a 2 na grade do fim. As respostas esperadas foram conferidas na documentação da Adobe para Magento 2.4, listada nas fontes. Se tiver alguém técnico de confiança, chame para a conversa; se não tiver, a grade já separa bastante.

Perguntas sobre plugin, preference, observer e ObjectManager

1. Quando você usa um plugin around, e quando evita?

Boa resposta: around só quando o comportamento original precisa ser substituído, como diz a diretriz técnica da Adobe; para mudar argumento ou resultado, before ou after. Cita que around aumenta a pilha de chamadas e afeta desempenho. Alerta: "uso around para tudo, é mais flexível".

2. Quando uma preference é inevitável?

Boa resposta: para ligar interface à implementação, que é uso normal, ou quando o plugin não alcança e a herança alcança (método protegido, construtor). Sabe que preference sobre classe do core substitui a classe inteira e pesa no upgrade. Alerta: preference como primeira opção.

3. Observer ou plugin: como você escolhe?

Boa resposta: observer reage a evento e, pela diretriz, não modifica os valores recebidos; para alterar entrada ou saída de método, plugin. Observer pequeno, com a regra de negócio em outra classe, sem depender da ordem de outros observers e declarado na área certa. Alerta: alterar o pedido dentro do observer.

4. Por que não usar o ObjectManager direto?

Boa resposta: dependência declarada no construtor deixa a classe testável e substituível; a documentação admite o ObjectManager só em fábricas com lógica complexa e testes de integração. Alerta: "funciona do mesmo jeito".

Perguntas sobre banco, API e filas

5. Para que serve o db_schema_whitelist.json?

Boa resposta: acompanha o db_schema.xml e é gerado com bin/magento setup:db-declaration:generate-whitelist --module-name=Vendor_Modulo; sem a tabela ou coluna registrada nele, a remoção declarada não acontece. Alerta: criar tabela com SQL na mão.

6. Data patch ou schema patch?

Boa resposta: data patch altera dados; schema patch, estrutura customizada. Patch roda uma vez e fica registrado na tabela patch_list; getDependencies() define a ordem e getAliases() cobre renomeação. Alerta: rodar SQL direto em produção a cada deploy.

7. Como você expõe um dado novo do pedido na API sem mexer na interface do core?

Boa resposta: extension attributes, declarados em etc/extension_attributes.xml, sobre as interfaces de dados do service contract, o conjunto de interfaces que dá ao módulo uma API estável entre versões. A documentação diz que terceiros não podem alterar as interfaces de dados da API. Alerta: preference na interface de dados, ou load() direto no model em vez do repository.

8. Como funcionam filas e consumers, e o que acontece se o cron parar?

Boa resposta: a mensagem é processada de forma assíncrona por consumers declarados em queue_consumer.xml. Por padrão, o job consumers_runner do cron inicia os consumers, que processam até max_messages e terminam; também dá para usar bin/magento queue:consumers:start. Se o cron parar e não houver outro gerenciador de processos, como o Supervisor, os consumers não voltam a rodar e as mensagens ficam paradas na fila. Sabe que a documentação desaconselha vários consumers numa fila operada pelo MySQL. Alerta: não saber onde a mensagem espera nem quem a consome.

Perguntas sobre indexação, cache, modo de produção e lentidão

9. Update on Save ou Update by Schedule?

Boa resposta: no agendado, gatilhos do MySQL gravam as mudanças numa tabela de changelog e o cron reindexa; comando bin/magento indexer:set-mode schedule. Lembra que sem cron o índice para. Alerta: não relacionar índice com cron.

10. cache:clean ou cache:flush?

Boa resposta: cache:clean remove itens dos tipos de cache habilitados sem afetar outros processos; cache:flush limpa o armazenamento inteiro e pode afetar outras aplicações que usam o mesmo Redis ou Valkey. Alerta: "sempre flush".

11. O que muda com a loja em modo production?

Boa resposta: arquivos estáticos servidos só do cache, por isso o deploy gera os estáticos; erros vão para log e não aparecem ao cliente; confere com bin/magento deploy:mode:show. Alerta: deixar a loja em developer "para facilitar".

12. Como você investigaria uma página lenta?

Boa resposta: medir antes de mexer; ver se a página sai do cache (em developer mode o Magento envia o cabeçalho X-Magento-Cache-Debug com HIT ou MISS); procurar bloco com cacheable="false", que tira a página inteira do cache; usar bin/magento dev:profiler:enable html; olhar indexadores, cron e consumers parados. Alerta: "aumenta o servidor" antes de medir.

Grade de pontuação para comparar candidatos

Some por bloco: perguntas 1 a 4 (como o código se encaixa no Magento), 5 a 8 (dados, API e filas) e 9 a 12 (operação). Numa entrevista técnica para dev Magento backend, os dois primeiros blocos pesam mais, e um candidato forte em código pode pontuar menos em operação; se a hospedagem ou outro profissional cuida do servidor, isso pesa menos. Compare pelo bloco que a demanda pede, como explico no artigo sobre os perfis de programador Magento. E lembre que nota alta em entrevista justifica valor-hora mais alto só quando vem com evidência, como discuto em o que mexe na hora de programador Magento.