Entrevistas de trabajo y pruebas de conocimientos técnicos (parte II) - Amazon

Siguiendo con la secuencia de artículos, en esta oportunidad me referiré a mi propia experiencia de entrevistas de trabajos con Amazon. Aparte de satisfacer la curiosidad de muchos amigos que estuvieron atentos a como me iba (en serio ¡gracias  todos ustedes! :) ), espero que mucho de lo que voy a escribir sirva de consejo para otras personas que vayan a enfrentar entrevistas con  Amazon.

La primera vez que me entrevistaron me contactaron por Linked In, esto fue a fines de Abril de 2013, mi suegra había fallecido recién, y la verdad mi estado de ánimo estaba afectado, fuera de la ansiedad natural de enfrentar a una prueba con una de las empresas más importantes del mundo.
La prueba en si fue escrita, 3 preguntas de Diseño Orientado a Objetos (OOD) y Codificación, y consideraban tus respuestas  siempre y cuando las hubieras contestado en 65 minutos o menos.

1. La primera  pregunta fue de diseño orientado a objetos. El requerimiento era modelar (y dentro de lo posible implementar) un software de diseño gráfico, algo así como Inkscape o MS Paint. No era difícil, pero era una pregunta larga, te podías complicar tanto como quisieras.
   

   Let's say we're developing a vector graphics application. It will allow the user to create lines, rectangles, circles, text, etc. and manipulate them independently - move them, resize them, etc. Design an object model for this application. (How would you model the representation of the document in an object oriented language? What classes would you define? What methods would you have? What would your API look like?)

2. La segunda pregunta fue de algoritmos y estructuras de datos. Se debía implementar un método que mostrara en pantalla el listado de amigos directos o por nivel (amigos de mis amigos) de una red social, y así sucesivamente. El problema real era como recorrer un árbol por nivel.
   

   Code printSocialGraph(Member m). Direct friends of m are Level 1 friends. Friends of friends are level 2 friends.....and so on
   Print level 1 friends first. Then print level 2 friends....and so on

3. La tercera pregunta era de programación de algoritmos eficientes. Pedían una implementación eficiente para calcular un ene-ésimo número de Fibonacci. Lo más "obvio" era haber implementado una especie de pila con memoria para futuras ejecuciones (o algo así), o usar alguna ecuación matemática avanzada para este  cálculo. Por un tema de tiempo hice la implementación recursiva tradicional, y lo más seguro que mal...
   

   Write an efficient function that returns the n’th Fibonacci number (There are many ways to solve this problem. Please write the most efficient method possible). Each Fibonacci number is the sum of the last two. The first 10 are: 1, 1, 2, 3, 5, 8, 13, 21, 34, 55.
   long getNthFibonacci(long i) { ... }

Las cosas importantes que rescato de aquí:

• Prepararse para manejo de tiempo
• Repasar patrones de diseño
• Manejar las estructuras de datos básicas, árboles sobretodo y manejar los algoritmos para recorrerlos.
• Leer y entender algunos algoritmos de computación distribuida

Según he leído, la evaluación es bastante estricta en cuanto a la sintaxis, se espera poder copiar y pegar el código que hayan generado y que compile correctamente. Y una cosa que me llamó la atención es que la plataforma que utilizan para la prueba técnica literalmente graba el como vas respondiendo, probablemente para entender los procesos mentales detrás de cada respuesta.

En la segunda oportunidad me contactaron directamente a mi correo, seguramente debido a que ya tenían mi currículum de la oportunidad anterior. Ahora la entrevista sería telefónica, de 1 hora, y se me solicitaba tener acceso a internet y compartir una pantalla para escribir código colaborativo.

Después de una fallida entrevista, debido a mala conexión telefónica (moraleja, para llamadas internacionales NUNCA dar el celular, o línea fija o Skype (o similar)), logré que agendáramos la entrevista para otro día.
Llegado el día D, me entrevisté con el jefe del equipo de desarrollo al que postularía.

La entrevista se desarrollo de esta manera:

• Mohan me contó un poco que es lo que hacía en  Amazon  me fue preguntando sobre mi experiencia laboral reciente. Tengan presente cuál fue su trabajo más desafiante e interesante. Yo me equivoqué y cité una experiencia más del montón que destacable, era otro el proyecto sobre el que  me tuve que explayar.
• Al momento de la parte de preguntas técnicas comenzamos con generalidades. Al respecto, tengan frescos los conceptos de OOP, UML y estructuras de datos. Yo me enredé innecesariamente al intentar definir conceptos básicos. Afortunadamente Mohan (mi entrevistador) supo interpretar mi enredo y, quizás sin intención, guiarme hacia la respuesta correcta. No teman dar ejemplos, pero procuren que sean los ejemplos adecuados.
• Luego prosigueron las preguntas relativas a patrones de diseño. Mohan me preguntó sobre que patrones me resultaban familiares y cuales había utilizado recientemente. Esta fue la pregunta trampa. Mencioné conocer y haber trabajado con los patrones Singleton, Proxy, Command, MVC, y entre esos haber utilizado más recientemente el Singleton.
  Aquí pueden perderse o coronarse. Me hizo implementar el patrón Singleton, y aún bajo las traiciones de mi memoria, y muchos alcances de errores que me mencionó detectar, lo logré sacar. Ojo el patrón Singleton, así de paquete no es "thread safe" (i.e. múltiples threads llamando la clase en el mismo instante exacto no aseguran que el singleton funcione como es esperado), por lo que hay que sincronizarlo. Esto también fue parte de la entrevista. Yo no recordé la sintaxis de como sincronizar la llamada.
• Finalmente la parte técnica terminó con una pregunta tipo, y digo tipo porque recuerdo haberla visto en varios otros lados:
  

  Se tiene un archivo con líneas de texto con una palabra por línea. cada palabra puede ser un anagrama de otra, vale decir esta compuesta por las mismas letras que otra palabra pero en distinto orden. Ejemplos:
  { opt, pot, top }, { apt, tap, pat }, { casa, saca }
  Se pide determinar que grupos de palabras son anagramas entre si.

Esta pregunta clásica la razoné de la siguiente manera:

1. Agrupar las palabras según su largo (en caracteres) ya que entre palabras de igual longitud existe mayor probabilidad que sean anagramas entre ellas.
2. Recorrer este nuevo listado agrupado haciendo un chequeo de equivalencia para cada nueva palabra rescatada. Aquí mi idea apuntó hacia un "hashmap de múltiples llaves" (ERROR garrafal, eso no es un hashmap, y si lo fuera no es eficiente). Mohan me perdonó lo de las múltiples llaves, señalándome que efectivamente la cosa iba por un hashmap, y me dió como "hint" que ordenara las palabras. En un principio pense en ordenar todas las palabras, pero eso no tenía mucho sentido, hasta que ejemplificó:

• apt ordenado (alfabéticamente) es apt
• tap ordenado (alfabéticamente) es apt
• pat ordenado (alfabéticamente) es apt

Entonces la solución salta a la vista, hashmap donde la llave es la palabra ordenada.

Nuevamente me traicionaron la ansiedad, los nervios y el tiempo. Resolví el problema en seudocódigo, y finalmente me dijo si tenía preguntas. lo único que atiné a preguntar fue "¿Cómo es trabajar en Amazon? ¿es como resolver estos tests?" A lo que respondió que si, efectivamente su trabajo a diario es optimizar los procesos de  Amazon  sobretodo los procesos de distribución de paquetes para resolver los envíos minimizando costos tanto para clientes como para la empresa.

Cosas que rescato, y voy a repetir mucho de lo que mencioné más arriba:

• Asegúrense de establecer un canal de comunicación confiable, NUNCA por teléfono móvil.
• Tengan presente cuál fue su trabajo más desafiante e interesante.
• Tengan frescos los conceptos de OOP, UML y estructuras de datos.
• Tengan frescas las implementaciones de patrones de diseño simple (o en su defecto algún cheat sheet a mano).
• No tengan miedo a preguntar.
• Siempre seguros de lo que están diciendo, incluso al reconocer que no saben.

Consideren que la persona que los va a entrevistar tiene un nivel técnico muy alto, así que no le van a poder mentir sin que se de cuenta, muy acorde a los estándares de la empresa.
 Amazon exige profesionales de un nivel técnico MUY alto, con fuerte dominio en patrones de diseño y algoritmos, y sobretodo en algoritmos. No basta saber un poco de todo, o ser un especialista en determinada tecnología (sea herramienta, lenguaje de programación o arquitectura). Las pruebas DEMANDAN preparación A CONCIENCIA.
Y esto es porque el nivel de empresa que ha alcanzado Amazon, EXIGE excelencia, y la única forma de mantener ese nivel es con PROFESIONALES DE 1er NIVEL.

No es la típica entrevista donde con suerte sabes que te pueden preguntar. Todo está disponible para que puedas prepararte de la mejor manera:

• Cargo al que postulas, o la base desde la que te van a medir.
• Amazon Values que es básicamente lo que esperan de ti (en términos no técnicos)
• Pauta de preparación con la que uno debiera estudiar
• Recomendaciones generales para la entrevista

Yo no soy un tipo que "se peine" con algoritmos, mi fuerte ha sido resolver el día a día y tratar de hacerlo de la mejor manera. Por eso me siento honrado que una empresa como  Amazon me haya dado una oportunidad y haya destinado una hora de sus valiosos recursos en entrevistarme.

Como dijo un colega "El NO ya lo tienes", así que nada se perdía con intentarlo. Ustedes ya tienen más información de como enfrentar a este monstruo.

Nota a Mayo de 2020: Sí, estoy claro que pasados 7 años muchas cosas han cambiado. Sin embargo no puedo no dejar este enlace con ciertas apreciaciones que como joven desarrollador no investigué en su oportunidad. Lo feo de trabajar como desarrollador en Amazon: https://gist.github.com/bricker/cb811b3b86d767124801 Simplemente léanlo.