Me explique como você analisaria a complexidade de tempo e de espaço de um trecho de código.

Descubra como o tempo de execução cresce conforme a entrada cresce, e aí descarte constantes e termos de ordem menor. Leia a estrutura do código: blocos sequenciais somam, loops aninhados multiplicam, e chamadas recursivas seguem a recorrência. Espaço é a memória extra que você aloca além da entrada, incluindo a pilha de chamadas. Diga o pior caso por padrão, e aponte o caso médio separadamente se eles diferirem de forma significativa.

Eu começo nomeando o n, porque metade da confusão nessas conversas vem de duas pessoas medindo coisas diferentes. Depois eu leio o código estruturalmente. Blocos sequenciais somam, então o maior vence; loops aninhados multiplicam; uma chamada recursiva vira uma recorrência que eu posso expandir ou reconhecer. Para espaço eu conto qualquer coisa que eu alocar além da entrada, e sempre incluo a pilha de chamadas, que é a parte que as pessoas esquecem na recursão. Um exemplo concreto: eu tinha uma função que parecia linear porque era um loop sobre uma lista de pedidos, mas dentro dela a gente chamava um helper que buscava um registro por id numa lista. Aquela busca era linear, então o custo real era quadrático, e só apareceu quando um cliente chegou a uns quarenta mil pedidos. A gente trocou a lista por um dicionário indexado por id e o endpoint foi de uns nove segundos para menos de duzentos milissegundos. Então minha regra é olhar dentro de cada chamada, não só nos loops que dá para ver.