Como mandar muito bem em uma entrevista de algoritmos – Parte 02

Este é o segundo artigo com dicas para que você vá bem em uma entrevista de algoritmos. O primeiro pode ser acessado aqui.

?

Aqui na Palantir, os algoritmos são importantes, mas a codificação é nossa força vital. Vivemos e morremos pela qualidade do código que fazemos. Assim, não é surpresa que a habilidade em codificar é o que mais enfatizamos durante uma entrevista. Um candidato pode safar-se com capacidade mediana em lidar com algoritmos (dependendo da função), mas ninguém pode ter insuficiências em codificação.
Suponha que você tenha confiança na sua habilidade em escrever software de qualidade. Sua tarefa em uma entrevista de codificação (que serão várias) é mostrar aos entrevistadores que de fato você tem as manhas da programação – que você é um programador experiente, que sabe escrever códigos de qualidade.

Isso é mais fácil de falar do que de fazer. Afinal, fazer codificação em seu IDE favorito no conforto de um $familiar_place é muito diferente de codificar em uma lousa (sobre um problema com o qual você não tem familiaridade nenhuma) em uma tensa entrevista de 45 minutos. Sabemos que o ambiente da entrevista não é o mundo real, e ajustamos nossas expectativas a isso.  Entretanto, há algumas coisas que você pode fazer para se sair bem nessa situação.

Gostaríamos então de lhe dar uma ideia do que procuramos durante uma entrevista de codificação. O mais importante é a capacidade de escrever um código limpo e correto – não é suficiente ser apenas correto. Quando estiver trabalhando, um monte de gente estará interagindo com sua codificação, de forma que ela deve ser legível, de fácil manutenção e extensível quando apropriado.

Se sua solução for simples e correta, e você a tiver produzido em um tempo razoável sem precisar de muita ajuda, você estará em boa forma. Mas, mesmo que você tropece um pouco, há outras formas de demonstrar sua habilidade. À medida que você trabalha, também observamos sua capacidade em depurar, de solucionar problemas, suas habilidades analíticas, sua criatividade e entendimento do ecossistema que circunda a produção da codificação.

Com nossos critérios de avaliação em mente, seguem abaixo algumas sugestões que, esperamos, ajudem você a ter seu melhor desempenho.

Antes de iniciar a codificação

• Tenha certeza de que você entendeu o problema. Não hesite em perguntar. Especificamente, se alguns quesitos do problema parecem mal definidos ou pouco claros, peça esclarecimentos ao seu entrevistador. Não há problema em pedir esclarecimentos, e certamente você não vai querer perder algum dado fundamental ou encaminhar seu raciocínio a partir de suposições sem fundamento.
• Trabalhe com exemplos simples. Isso pode ser útil antes e depois da codificação. Trabalhando com exemplos simples antes de iniciar a codificação pode lhe dar clareza adicional sobre a natureza do problema – pode ajudar na percepção de situações ou padrões do problema que poderiam não ser percebidos caso você estivesse raciocinando de forma abstrata.
• Faça um planejamento. Cuide para não iniciar a codificação sem pensar na estrutura de alto nível do programa. Não será necessário trabalhar em detalhe (isso pode ser difícil com problemas mais complicados), mas você deve pensar suficientemente a respeito. Sem um planejamento adequado, você pode ser forçado a gastar seu tempo limitado retrabalhando partes significativas da sua programação.
• Escolha uma linguagem. Na Palantir, não nos preocupamos com quais linguagens você conhece, desde que você tenha bons fundamentos (decomposição, design orientado a objeto etc.). Dito isso, você deve ter a habilidade de se comunicar com seu entrevistador e, assim, escolher algo que ambos entendam. Em geral, é mais fácil para nós usar Java ou C++, mas tentamos acomodar outras linguagens. Se isso tudo falhar,  invente seu próprio pseudo-codigo. Só tenha certeza de que ele é preciso (ou seja, não é tradicional) e é internamente consistente, explicando suas escolhas a medida que prossegue.

Enquanto está codificando

• Pense alto. Explique seu raciocínio ao entrevistador à medida que vai codificando. Isso permite uma comunicação plena com seu entrevistador e lhe dá a oportunidade de corrigir falhas de concepção ou de obter orientação.
• Desmembre o problema e defina as abstrações. Uma habilidade crucial que procuramos é a capacidade de lidar com a complexidade, desmembrando grandes problemas em outros menores, que sejam manejáveis. Para qualquer coisa não trivial, você não vai querer codificar uma função gigante, monolítica. Sinta-se livre para definir funções helper, classes helper, e outras abstrações para chegar a uma solução operacional. Você também pode usar padrões de design ou outros idiomas de programação. Idealmente, sua solução deverá ser bem confeccionada e, como resultado, fácil de ler, entender e provar-se correta.
• Adie a implementação de suas funções helpers (?). (isso serve como corolário ao item anterior).  Escreva a assinatura, e tenha certeza de entender o contrato que seu helper o obriga, mas não o implemente imediatamente. Isso tem múltiplos propósitos: (1) mostra que você tem familiaridade com abstrações (tratando o método como uma API); (2) vai lhe permitir manter o ímpeto para alcançar uma solução geral; (3) resulta em menos mudanas de contexto para seu cérebro (você pode raciocinar separadamente a respeito de cada nível da chamada da pilha); e (4) seu entrevistador pode não exigir a implementação, se considerá-la trivial.
• Não se perca em trivialidades. Na Palantir, estamos muito mais interessados na solução geral do problema que você oferece e em suas habilidades de programação do que o quanto você se lembra de nomes de funções de biblioteca ou da sintaxe de linguagens obscuras. Se você não se lembrar exatamente de como fazer alguma coisa na linguagem que você escolheu, explique a seu entrevistador que você olhará os detalhes na documentação. Da mesma forma, se você utilizar uma abstração ou um idioma de programação que admite uma implementação trivial, não tenha medo de escrever a interface e de omitir a implementação, de forma que você possa se concentrar nos aspectos mais importantes do problema (por exemplo, “Vou usar um buffer circular aqui com a interface correspondente, sem escrever a implementação completa).

Quando você tem a solução

• Pense nas situações limite. Naturalmente você deve empenhar-se por uma solução correta em todos sentidos. Algumas vezes, poderá haver imperfeições no cerne da lógica de sua solução, mas mais frequentemente os bugs aparecerão em sua forma de lidar com situações extremas (isso também é verdade na vida real). Tenha certeza de que sua solução funciona em todas as situações extremas em que você possa pensar. Uma maneira de procurar por bugs em situações extremas é…
• Depure seu código. Uma das melhores maneiras de checar seu trabalho é simular uma execução com um input simples. Pegue um de seus exemplos anteriores e tenha certeza de que seu código produz o resultado certo. Grande pegadinha aqui: ao simular mentalmente como seu código se comporta, seu cérebro será tentado a projetar o que ele deseja que aconteça, contrariamente ao que realmente acontece. Lute contra essa tendência sendo tão literal quanto possível. Por exemplo, se você estiver calculando uma índex string com código como str.length()-suffix.length(), não assuma que você sabe aonde esse índex vai parar. Faça os cálculos e verifique se o valor é o que você esperava.
• Explique os atalhos que você tomou. Se você pulou algumas coisas que faria no “mundo real”, informe sobre o que você fez e por quê. Por exemplo, “Se estivéssemos escrevendo isso para uso real, eu gostaria de checar uma invariant aqui”. Uma vez que a codificação em uma lousa é um ambiente artificial, isso nos dará o conhecimento sobre como você tratará a codificação em um trabalho real.

Como adendo, abaixo algumas sugestões de livros de que gostamos a respeito da arte de elaboração de software:

• Clean Code: A Handbook of Agile Software Craftsmanship – Robert C. Martin
• Code Complete: A Practical Handbook of Software Construction – Steve McConnell
• The Practice of Programming – Brian Kernighan, Rob Pike
• Design Patterns: Elements of Reusable Object-Oriented Software – Erich Gamma, et al.
• Effective Java – Joshua Bloch

?
Texto disponível em http://blog.palantirtech.com/2011/10/03/the-coding-interview/