Buscando Trabajo en EEUU: Amazon IV

Ésta será la última entrada de la serie relatando mi experiencia entrevistando con Amazon, el gigante del comercio electrónico. Escribí anteriormente la primera, segunda y tercera parte de esta historia, cuya lectura recomiendo antes de seguir leyendo el resto.

Había conseguido una entrevista in situ con Amazon en sus oficinas centrales en Seattle. Como ya describí en la anterior entrada, ellos se encargaban de todos los gastos incluyendo el transporte, comida y el lujoso hotel en el centro de la ciudad. Gracias a la paliza que me había pegado estudiando en el avión de camino a Seattle, dormí como un lirón esa noche. A la mañana siguiente, tuve tiempo de sobra para estudiar un poco más y leer sobre cómo funcionan las entrevistas en Amazon, y resulta que los de Seattle tienen un concepto muy particular en lo que a sus entrevistas se refiere. Como en la mayoría de las empresas, un candidato tiene varias entrevistas independientes con uno o más ingenieros en un día, pero generalmente esos ingenieros son tus posibles futuros compañeros de trabajo y casi siempre tu posible futuro jefe. En Amazon, una de las entrevistas tiene como único objetivo subir el listón. Un entrevistador especialmente preparado se encarga de que cada ingeniero contratado por Amazon es más inteligente que la media de la plantilla para asegurarse de que la inteligencia media de los ingenieros trabajando para ellos sólo sube. Además, ese entrevistador tiene derecho de veto sobre los demás, por lo que la presión era enorme. En teoría tiene su lógica, pero en la práctica eso significaba que en una de las entrevistas me lo iban a poner especialmente difícil.

Llegué a las oficinas casi 20 minutos antes, lo cual me dio tiempo de sobra para tomarme un café en un Starbucks cercano. Cabe mencionar que Seattle es la ciudad donde se construyó el primer Starbucks, ¡por eso hay uno en cada esquina! A diez minutos del comienzo de mi entrevista, entré en las oficinas y me presenté a la recepcionista. Con una puntualidad exquisita, exactamente a la hora fijada, dos representantes de recursos humanos me vinieron a recoger y me llevaron a una sala de conferencias donde pasaría el resto de mi entrevista. Como es habitual, los de recursos humanos eran gente muy agradable que me dieron una idea general sobre cómo iba a ser el resto del día e incluso me dieron un par de consejos para cuando comenzasen las entrevistas "de verdad". Unos pocos minutos más tarde, me dejaron para que entrasen dos ingenieros que darían comienzo a una de las peores palizas que me han dado nunca. Uno de los ingenieros se presentó como alguien que no estaría en mi grupo de trabajo, y el otro estaba allí para aprender sobre "este tipo de entrevistas". Inmediatamente supe que esa primera entrevista sería la que subiría el listón.

Tuve la oportunidad de tomar una foto de mi entrevistador. Licencia CC Wikimedia Commons

Si intentara escribir la pregunta que me hicieron durante esa entrevista posiblemente tardaría varias horas y no me entendería nadie, así que mejor nos ahorramos todos un disgusto. Resumiendo, mi entrevistador se pasó 35 minutos (más de la mitad del tiempo que teníamos para la entrevista) explicándome la dichosa pregunta, que era un escenario muy enrevesado que requería el uso de programación orientada a objetos de alto nivel y al menos tres tipos distintos de estructuras de datos. Mientras le explicaba mi razonamiento, en un momento dado dibujé varias flechas en la pizarra que representaban una relación entre diferentes conjuntos de datos y mi entrevistador me interrumpió, sonriendo, y dijo:

- Imagino que esa última flecha que acabas de dibujar la quisiste hacer con una línea de puntos en vez de con una línea continua, ¿verdad?

Sinceramente, no tengo ni idea de cuál es el criterio de uso para los distintos tipos de flechas en la representación de conjuntos de datos en una pizarra, y tampoco me importa porque el único objetivo de mis garabatos era clarificar mis ideas. En mi opinión, es como si me hubiera corregido porque mis líneas no eran lo suficientemente rectas, y me sentí algo ofendido por su actitud de superioridad. Al final de la entrevista, había diseñado una aplicación cuya estructura de datos fundamental era una tabla hash que asociaba una pareja de claves con un determinado valor. Mi entrevistador me dijo que esa no era la solución que estaba buscando, y me explicó que era mucho mejor tener una tabla hash que asociara una clave a otra tabla hash, y entonces utilizar la segunda clave para recuperar el valor buscado.

Para el que le cueste entender ese último párrafo, en realidad los detalles no importan. El quid de la cuestión era que, aunque las dos soluciones eran técnicamente equivalentes, la suya era, en su opinión, mucho mejor. Realmente creo que, en su arrogancia, mi entrevistador no entendió realmente mi solución, porque por más que lo pienso sigo sin entender como la descartó tan a la ligera.

Éste era mi aspecto después de la primera entrevista. Fuente

Después de que me diesen la del pulpo en la primera entrevista, mis entrevistadores fueron relevados por otro ingeniero de origen presumiblemente indio cuyo acento me fue bastante complicado de interpretar al principio. Sin tener ni siquiera unos segundos de descanso, me lanzó una pregunta que, gracias a Dios, fue muy mucho más sencilla que la primera. Me pidió que escribiera un programa que leyese los datos de una matriz de tamaño N x N en un patrón de espiral, por ejemplo dada la siguiente matriz:

(0,0)	(0,1)	(0,2)	(0,3)	(0,4)
(1,0)	(1,1)	(1,2)	(1,3)	(1,4)
(2,0)	(2,1)	(2,2)	(2,3)	(2,4)
(3,0)	(3,1)	(3,2)	(3,3)	(3,4)
(4,0)	(4,1)	(4,2)	(4,3)	(4,4)

El entrevistador me pidió que escribiera un bucle que leyera los datos de la matriz en el orden descrito secuencialmente tal que así:

25	21	13	14	22
20	12	5	6	15
11	4	1	2	7
19	10	3	8	16
24	18	9	17	23

O si N era un número par, la secuencia sería del siguiente tipo:

16	12	5	13
11	4	1	6
10	3	2	7
15	9	8	14

Aunque no era una pregunta extremadamente sencilla, pedía a gritos una solución que empleara recursividad. Con un poquito de esfuerzo, logré sacar la solución correcta e incluso me sobraron unos minutos antes de la siguiente entrevista.

Incluso después de mi segunda entrevista, el vaso seguía medio vacío. Licencia CC Wikimedia Commons

De nuevo, relevo de ingenieros. Mi nuevo entrevistador me hizo una pregunta relacionada con optimización combinatoria basada en el conocido problema de la mochila, también llamado KP, que describí con más detalle en esta entrada. Desgraciadamente, no fui capaz de dar con la solución acertada a la primera, aunque creo que no lo hice del todo mal pese a que me tuvo que dar alguna pista. Después de semejante bajón, y de nuevo sin tener ni un segundo de descanso, en mi última entrevista estaba tan agotado después de las otras que no podría haber estado al mismo nivel ni aunque lo hubiese intentado. Me pidió que escribiese algo de código que buscase la secuencia de 3 páginas más común en el historial de navegación de los usuarios. Tomando el ficticio usuario 1 como ejemplo con el siguiente historial de navegación, donde cada letra representa una página:

A -> B -> C -> A -> D -> E

Cada 3 páginas representan una secuencia distinta. En este caso las secuencias  A -> B -> C  y  B -> C -> A  podrían ser consideradas independientemente. Además está la complejidad añadida de tener varias secuencias posibles con un elemento inicial. Por ejemplo, para usuario 1, visitar la página  A  podría estar seguido de página  B  pero también de página  D. Así pues, me pareció obvio que estaba ante un sistema de estados finitos (también llamado FSM por sus siglas en inglés). Procedí a hablar sobre cadenas de Markov y procesos estocásticos hasta que, para mi sorpresa, mi entrevistador admitió no saber lo que era una cadena de Markov. En ese momento, cambié de estrategia y me centré en las estructuras de datos que utilizaría para guardar la información necesaria, en este caso siendo un trie la más apropiada. Debí dar en la diana porque, en cuanto mencioné la estructura de datos que utilizaría, la dinámica de la entrevista cambió completamente y pasó a ser mucho más relajada. Después de tener la primera conversación amigable con un entrevistador desde que hablase con las chicas de recursos humanos casi 5 horas antes, dio por terminada la ronda de entrevistas y me acompañó de vuelta a la sala de recepción de las oficinas para despedirme.

Tenía el resto del día para visitar Seattle pero estaba tan cansado y deprimido que volví al hotel para dormir hasta que decidí salir para cenar algo. Aunque no lo había hecho del todo mal en mis entrevistas, tenía la sensación de que no volvería a Seattle, y no estaba muy equivocado. Durante mi vuelo de vuelta a Ohio la mañana siguiente, recibí un mensaje en el contestador del departamento de RRHH de Amazon diciendo que no me veían como un buen candidato para la posición, y que podría volver a mandar mi currículum a Amazon en 6 meses si quería intentarlo otra vez.