lunes, octubre 07, 2013

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:



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.

Recomendaciones generales para entrevista técnica con Amazon

Al momento de coordinar una entrevista con Amazon, te hacen llegar las sigueintes recomendaciones para que la entrevista se desarrolle de la mejor manera posible.

The technical interview will include (but is not limited to) questions related to Coding, Data structures, Algorithms and Object Oriented Design and will last about an hour.  Due to the technical nature of this interview, please do not drive or commute during your phone interview. Please consider the following interview tips: 1. Be in a quiet place where you are comfortable and there are no distractions .2. Have a copy of your resume available just in case you are questioned on it.3. Please have access to the internet during this time.4. Have any questions you have for the interviewer ready.5. If you will be speaking on your cell phone, please ensure that you are in a place with enough cell phone coverage to avoid any call drops.6. Review the job description and this link: Amazon Values

Pauta de preparación para pruebas técnicas de Amazon

Estas es la pauta de preparación que te hace llegar Amazon cuando postulas. Básicamente es lo que se espera uno debiera preparar.
¿Saben de otra empresa qué haga lo mismo? Yo no, y he hablado con muchas empresas. Este es el tipo de cosas que marca la diferencia entre las grandes empresas y el resto.

Work hard. Have fun. Make history.



Thank you for the interest in Amazon.com and taking the time to speak with us about some of the exciting opportunities that we have available.  We’ve put this document together to help give you an idea of what types of knowledge we expect some level of familiarity with.
Preparing for Your Interview
At Amazon.com we’re looking for talented engineers that can apply the knowledge that they’ve learned in school and in industry to solving some of the world’s most complicated software problems.  As such, our interviews are mainly focused on how well you can use your acquired knowledge to solve real world (or in some cases not so real world) problems.  Below is a list of broad areas that we expect people to be familiar with.  It’s certainly not required that you memorize all of the information outlined below, but this should serve as a helpful reference guide for the types of things you might want to brush up on before interviewing with Amazon.com.
Programming Languages
We do not require that you know any specific language before interviewing for a technical position at Amazon.com, but familiarity with a prominent object oriented language is generally a prerequisite for success.  Not only should you be familiar with the syntax of a language like C++, Java, or C#, you should also know some of the language nuances such as how memory management works, what some of the most commonly used collections or libraries are, etc.  You should be able to compare languages and talk about the tradeoffs between using language X vs. language Y.
Additionally, it’s considered a plus to be familiar with some scripting language such as perl, ruby, awk, etc.  It’s also nice to know the basics of regular expression as they are now a mainstay in both the object oriented and scripting worlds.
Data Structures
Most of the work we do involves storing and providing access to data in efficient ways.  This necessitates a very strong background in standard data structures.  You should know what each of these data structures is and how they’re implemented; what their runtimes are for common operations; and under what circumstances it would be beneficial to use one.  The below are in no particular order.
Array
Linked List
Tree (Tree, Binary Tree, Binary Search Tree, Red-Black Tree, etc.)
Heap
Hash Table
Stack
Queue
Trie
Graph (both directed and undirected)
Algorithms
It’s also important to know efficient ways manipulate data.  One great way of doing this is brushing up on some common algorithms.  We’ll expect that you can apply and discuss the tradeoffs between some commonly used algorithms.
Sorting
Bubble Sort
Merge Sort
Quick Sort
Radix/Bucket Sort
Traversals (On multiple data structures)
                Depth First Search
                Breadth First Search
Coding
Expect to be asked to code syntactically correct code – no pseudo code.  If you’re a bit rusty coding without an IDE or coding in a specific language, it’s probably a good idea to dust off the cobwebs and get comfortable coding with pen and paper.  The most important thing a software engineer does at Amazon.com is write scalable, stable, robust, and well tested code.  These are going to be the main criteria by which your code will be evaluated, so make sure that you check for edge cases and common error inputs as well as the “happy paths” through the code.
Object Oriented Design
Good design is paramount to extensible, bug free, and long living code.  It’s possible to solve a software problem in an almost limitless number of ways, but when software needs to be robust and extensible, it’s important to know some common techniques that help with this.  Using object oriented design best practices is one way to build lasting software.  You should have a working knowledge of a few common and useful design patterns (singleton, factory, adapter, bridge, visitor, command, proxy, observer, etc.) as well as know how to write software in an object oriented way with appropriate use of inheritance and aggregation.
Databases
Most of the software that we write is backed by a database somewhere.  A lot of the challenges we face come in to play when interfacing with existing data models and when designing new data models.  You should know the basics of how relational databases work, how to design relational database schemas, as well as how to write basic SQL queries against a database.
Distributed Computing
Our systems at Amazon.com usually have to work under very strict tolerances at high load.  While we have some internal tools that help us with scaling it’s important to have an understanding of a few basic distributed computing concepts.  Having an understanding of topics such as map-reduce, service oriented architectures, distributed caching, load balancing, etc. will help you in formulating answers to some of the more complicated distributed architecture questions you might encounter.
Internet Topics
This is Amazon.com, we’re an online company and we expect our engineers to be familiar with, at least, the basics of how the internet works.  You might want to brush up on how internet browsers do what they do, DNS lookups, what TCP/IP and HTTP are, sockets, etc.  We’re not looking for network engineering types of qualifications, but a solid understanding of the fundamentals of how the web works is a requirement.
Operating Systems
You won’t need to know how to build your own operating system, but you should be familiar with some OS topics that can affect code performance, such as memory management, processes, threads, synchronization, paging, multithreading, deadlocks (causes, detection, avoidance).

viernes, octubre 04, 2013

Entrevistas de trabajo y pruebas de conocimientos técnicos (parte I)

Quisiera compartir algunas experiencias e impresiones relativas a algunas entrevistas de trabajo he tenido en mis años desempeñándome como ingeniero informático. Va a ser un artículo extenso, por lo que advierto al honorable lector que si no es conquistado por mi narrativa, es altamente probable que se aburra.

Hace yo diría un año atrás, aproximadamente, respondí a la consulta en Twitter de una persona con quien tuve la oportunidad de trabajar hace algunos años atrás. Necesitaba alguien que "se manejara con XML", a lo que dados los proyectos en los que trabajé, repliqué con un poco humilde "XML is spoken".
Algo así como un mes después de mi respuesta, Andrés me contacta telefónicamente para citarme a una entrevista, de la cual él no me entregó mayor información y equivocadamente (ya diré porqué) yo tampoco solicité mayores antecedentes. Antes de seguir consideren esto como una regla de oro:
SIEMPRE PREGUNTEN LOS TÉRMINOS DE LAS ENTREVISTAS A LAS QUE VAN A ASISTIR
Es esperable que un empleador serio y respetuoso por los postulantes a cargos disponibles informe sobre el carácter de las entrevistas que realizará. No es justo para los candidatos llegar sin preparación a un prueba técnica, o ser sorprendidos por una.

Una vez en la reunión, Andrés no pudo estar presente a la hora acordada, ya que debió responder a otro compromiso laboral, sin embargo encomendó a una colega de él el entrevistarme. Mi entrevistadora me explicó un poco lo relacionado con este trabajo, que resumiendo se trataba de desarrollos en torno a un Bus de Comunicación para múltiples canales de entrada. Un equipo de excelencia, muy acorde al modus operandi que ya me resultaba familiar.

Tras una interesante conversación con mi entrevistadora, ella me señala que mientras esperaba que Andrés pudiera desocuparse, contestara un test escrito de conocimientos técnicos. A pesar de no ir preparado, y sabiendo solamente que sería "algo con XML", lo contesté.
Aquí me dí cuenta que debí haber preguntado como se desarrollaría la entrevista.

Hubo muchas preguntas de caracter semi-general que supe responder sin problemas, pero un gran porcentaje eran cosas que sinceramente JAMÁS he resuelto a mano, y por ende si bien conozco y domino, delego "el trabajo sucio" en la IDE o en aplicaciones auxiliares. Algunos ejemplos fueron hacer un schema XML, y otro escribir un WSDL, ¡a mano! ¡sin IDE! Digamos que desde la prehistoria que muchos desarrolladores no hacen ninguna de esas tareas a mano.
Mi sensación de esta prueba fue que ni el mismo equipo de excelencia sería capaz de contestar un 60% adecuadamente. Y si así fuera realmente me preocuparía, ya que si bien se valora el conocimiento "a mano", hay infinitas tareas cuya resolución eficiente puede realizarse a través del buen uso de herramientas dispuestas para ello.

Luego llegó Andrés, conversamos un tanto, y bromeamos un poco respecto a que no hice trampa para contestar la prueba, buscando en Internet usando mi teléfono móvil. Finalmente llegamos al tema de pretensiones de sueldo, y por la cara de Andrés ni siquiera hubo intención de negociar.

Independiente del resultado de la prueba, que dada mi absoluta NO preparación, fue sencillamente indigno (y ya les contaré como me enteré de esto), Andrés conocía mi trabajo, y tenía una muy buena idea previa de mis capacidades, mal que mal trabajamos en un proyecto anterior bastante grande. La lamentable lectura que hice fue que sencillamente prefirió no trabajar conmigo, y sostuvo una decisión predefinida en mi pobre desempeño en la prueba técnica. Como si haberme entrevistado hubiera sido "por cumplir" o para "ver que tal". Triste sensación, pero sólo eso una sensación de.

Tiempo después un amigo me consideró para apoyarlos en un proyecto en la empresa donde él trabaja. Su jefe, que era un muy buen amigo de mi ex-jefe cuando trabajamos con Andrés, se refiere a mi como alguien que "no se manejaba", precisamente aludiendo a que sabía de mi mal desempeño en la prueba técnica que les comento.
Esto es otra confirmación de que el mundo es pequeño y redondo, y que de una u otra manera, tarde o temprano siempre vas a saber que pasa a tu alrededor. No mucho que decir por este impasse de discreción, y dejémoslo ahí.

Sobre las pruebas técnicas, sobre todo  aquellas que son muy extensas, tengo 2 posturas:

  1. Por un lado no les encuentro sentido ya que no son representativas del verdadero potencial de un postulante.
    Un buen reclutador ES capaz de determinar si un postulante se ajusta al cargo al que postula.
    Un buen reclutador SE HACE ASESORAR por un experto (o al menos alguien con conocimientos) en las áreas que debe dominar el postulante.
    A un buen reclutador le es suficiente la entrevista personal con el postulante.

    Los nervios pueden jugar en contra del postulante, hay demasiados factores, incluyendo una evaluación absolutamente alejada de la realidad del modo de trabajo y desarrollo de la misma empresa, que pueden tener incidencia negativa en la calificación del candidato.

    En el peor caso el primer contrato normalmente es a prueba, por período no demasiado largos y se puede no renovar si el candidato no cumple los requerimientos del cargo.
  2. Por otro lado, si los cargos demandan REALMENTE un conocimiento técnico experto, o la postulación requiere que la empresa tenga PLENA CERTEZA (minimizando el riesgo a cero o casi cero) que se escogerá al candidato adecuado, y si finalmente trabajar en esa empresa es REALMENTE ATRACTIVO, como por ejemplo trabajar en Amazon, Facebook, Google o alguna otra empresa de similar estampa, entonces las pruebas técnicas tienen todo el sentido esperable.
Hay un tercer caso donde en realidad mi pronunciamiento es sobre la empresa, y como delega la selección de personal más que la utilidad o no utilidad de la prueba.
Son empresas que solicitan responder a una prueba muy extensa, que trata los más diversos tópicos técnicos, y en las que el postulante realmente no sabe a que cargo postulará, o que es lo que realmente necesitan que sepa (ya me pasó en una empresa donde respondí una prueba que me paseaba desde shell scripts, a base de datos, a SOA, a Java, a PHP, a administración de sistemas, indistintamente), y en que aparentemente la misma empresa tampoco tiene claro que tipo de profesional necesita.

A mi parecer o se puede medir todas las experticias con una misma regla, ni evaluarlas con una misma prueba.

En la parte II pretendo referirme a las pruebas técnicas de  Amazon, de las que he conocido de cerca 2 variantes.