Mostrando las entradas con la etiqueta Amazon. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Amazon. Mostrar todas las entradas

jueves, mayo 05, 2016

Te tengo una oferta de trabajo: No gracias

Búsqueda de imágenes por Currículum vitae en Google

Este va a ser un artículo arriesgado, lleno de varias verdades, de esas que nos cuesta admitir, incluso quizás toque la fibra sensible de gente ligada a empresas de headhunting, siempre  pensando en ingeniería informática. No se cual sea la realidad de otras especialidades, probablemente sea muy diferente.

Trabajo como ingeniero informático en una empresa chilena, vengo haciendo desarrollos desde  1995 y algo creo haber aprendido en todos estos años. En una sola oportunidad (hace ya varios años) me vi en una especie de urgencia por buscar trabajo, y estuve cesante 2 semanas, gracias a una estrategia sincera-agresiva de postulación (postulaba por lo bajo a 30 ofertas cada día). He ido a muchas entrevistas, y después de algún tiempo me he dado cuenta que todas fallan en lo mismo:
Prueba de conocimientos técnicos

A veces te avisan, otras veces te  toma de sorpresa. Cuando saliste recién de la universidad, o cuando aún estás estudiando, tienes todos los conocimientos frescos. En ese entonces, si me preguntaban de SOLID, el principio de sustitución de Liskov, Dijkstra, algorítmos de búsqueda eficiente de texto, como recorrer un árbol binario de manera inversa, probablemente  sabría como responder. Curiosamente Amazon, Google y Facebook (entre las grandes empresas que recuerdo) basan buena parte de sus procesos de selección en pruebas técnicas de un nivel medio-alto, alto. Tanto así que hay libros completos que explican como prepararse para esas pruebas.

Si quiere leer un artículo que apunta sus dardos directo sobre ese asunto lea: https://medium.com/@evnowandforever/f-you-i-quit-hiring-is-broken-bb8f3a48d324#.98cfx1v4a

Si a mi me toca una prueba técnica, respondo con lo puesto, con imprecisiones, no de memoria. En una oportunidad perdí 2 horas de mi vida respondiendo un test para una postulación que iba desde comandos básicos de Linux, hasta SQL. Daba la impresión que ni siquiera los reclutadores sabían que necesitaban. De esa sospecho que aún habiendo contestado casi todo bien (eran preguntas insultantemente fáciles), finalmente no me llamaron ni para si ni para no por el rango de sueldo que estaba pidiendo (todo el perfil de empresa  penca que busca un mono que las haga todas por poca plata).

Yo ya no estoy para esos trotes, a mis casi 40 años he hecho cosas importantes, trabajado en proyectos grandes, resuelto problemas complejos, creado productos (desde cero), ya he dejado una huella. Eso ya aparece en mi Curriculum (en adelante CV), y no me da miedo que llamen por teléfono a esas empresas preguntando si lo que puse en mi CV es o no es verdad. Pídanme que resuelva problemas, pero no las recetas universitarias que uno se aprende de memoria para pasar el ramo.

Tengo la fortuna de haber construido una discreta red de contactos que sabe que es lo que soy capaz de hacer, y que en ocasiones requiere de mi experticia. Y soy de la postura que  si ellos confiaron en mi no puedo menos que  hacer bien mi trabajo. ¿Pruebas técnicas o sicológicas? ¡Si claro!, las hubiera reprobado todas.

Tengo amigos cercanos que estuvieron en procesos de selección, incluso me han ofrecido incorporarme a los equipos donde ahora trabajan, pero "Gracias, pero no gracias". No estoy para esos procesos.

¿Qué pasa con las empresas en Chile?
Quisiera pensar que  tratan de imitar a las grandes empresas TI de USA, es cosa de ver algunos procesos, como el del Banco de Chile, jornadas de semanas enteras 3 o 4 horas diarias enfrentándose a pruebas técnicas, o los avisos de Get on board buscando ninjas y superhéroes en X tecnología. Y eso descartando las pruebas sicológicas que determinan que eres el inepto técnico chuper-buena-ondi  más adecuado para el cargo.

Seguro que debe haber pruebas para determinar la capacidad de los postulantes para resolver problemas, ojalá relacionados de alguna manera con el cargo ofrecido. Todavía no veo pruebas de ese tipo.

Otras empresas funcionan en base a las recomendaciones, un criterio dado por nuestros propios pares, que determina si uno puede potencialmente servir para una posición. Y no es que por ser "cercanos" a quien te recomendó tienes tu puesto asegurado, la entrada viene con el ticket de recomendación, pero si te  echan de la fiesta es porque tu mismo te lo buscaste: uno tiene que saber hacerse valer.

¿Sirven los expertos en el "Libro de Petete"?
Mi respuesta es radical: Sirven sí y sólo sí son capaces de resolver problemas.
La capacidad de aprender a usar una herramienta desconocida en poco tiempo (no más de un par de horas) y construir una prueba de concepto funcional, que resuelva un problema específico (planteado como requerimiento), no es algo que te enseñen en los libros. O viene en la sangre o lo aprendiste con los años de circo.

Un experto de libro no necesariamente es un buen profesional, y ya escribí un poco sobre expertos/especialistas.


Mi experimento
Hace  algunos meses me contactaron unos ex-compañeros de Universidad. Sólo me sonaban de nombre de la Escuela. La oferta era trabajar para un banco internacional. Me entrevisté con un indio, en inglés. Con la dificultad que tuve para comunicarme respondí conforme a lo que me preguntó. Lo sentí incómodo, como molesto por tener que entrevistarme.
Como una semana después me entrevisté con un chileno, y al ver el matiz de la entrevista decidí explicarle que  si me iba a hacer preguntas técnicas en realidad los 2 estábamos perdiendo el tiempo, ya que yo soy más de resolver problemas mediante la aplicación a repetir lo que aparece en el libro. El enfoque de mi entrevistador cambió, me preguntó sobre los proyectos en que había participado, mi actual experiencia y obviamente sobre que áreas dominaba mejor.
De todas formas tuve que responder un test técnico, pero bastante aplicado.

Después de esa entrevista supe que mi decisión final ya no pasaba por un tema de lucas (que tan 'bien' me iban a pagar), sino por un tema de cultura de empresa. No me veía trabajando en una empresa donde tuviera que ir con  zapatos, pantalón de vestir y camisa, llegar a las 8 AM todos los días y sin un espacio para investigar sobre nuevas tecnologías. Menos ver ciertas complicaciones para poder llegar en bicicleta a esa oficina.

Las lucas pueden ser muy buenas, pero, como dijo un caído en batalla, "Hay cosas que no se transan". Y son precisamente esas cosas las que hacen que una oferta deje de ser atractiva para un ingeniero informático. Finalmente, después que me informaron que   iba a tener otra entrevista con otro indio decidí dar un paso al lado del proceso. "Gracias, pero no gracias".

¿Experimento?
Si, experimento. Después de un tiempo sin pasar por procesos de entrevista y ajustes de CV, me plantié seguir un proceso de selección, ver hasta donde llegaba, que tan "blando" estaba para enfrentar entrevistas y pruebas técnicas.
La verdad es que siento que tan mal no estoy, y enfrentarme nuevamente a un proceso que no destacó precisamente ni por su agilidad ni por su enfoque, hizo que valorara mucho más la oportunidad que se me ha brindado para trabajar donde estoy. Enumerando puntos no sacrificables:

  • Puedo llegar en bicicleta
  • Horario semi-flexible
  • Posibilidad de trabajar desde la casa
  • Ropa informal (zapatillas, jeans y polera)
  • Espacios para la investigación (en todo caso esto es por lo que estoy resolviendo puntualmente, pasaron algunos meses antes de poder llegar a esto)
  • Beneficios de salud
  • Equipo no muy grande y de muy alto nivel técnico
  • Metodologías de trabajo establecidas (quizás no las mejores, pero  con espacio para mejorarlas)
  • Escritorio cómodo, ventana y juguetes (parece chiquero, pero trabajo feliz)

Imagen real de mi puesto de trabajo

Si su oferta puede igualar estas condiciones, quizás la piense.




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.

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.

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

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.

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).

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.