Parece una pregunta muy sencilla: ¿Puedes escribir un programa que calcule la media aritmética de una lista de números? La respuesta también puede ser sencilla, simplemente iterando sobre la lista y sumando los números para al final dividirlos por la cuenta. Por ejemplo, en Java:
La respuesta, aunque sencilla, no es del todo correcta. Imagínate, por ejemplo, que tu función recibe una lista vacía, o incluso sin inicializar. Tu código fallaría espectacularmente. Cuando escribes una función, por simple que sea (me atrevería a decir especialmente si es una función muy simple, pues será más probable que la reutilicemos en otras partes del código), nunca confíes en los parámetros de entrada de la función. Una versión algo más robusta sería:
Pero aún no es del todo correcta. ¿Puedes adivinar por qué? En este caso, el problema es mucho más sutil. Imagínate que la lista es muy larga; no, mejor aún, muy muy muy larga. ¿Qué pasaría con la variable sum? ¡Un desbordamiento de enteros! Una manera muy sencilla de solucionar el este problema es cambiando el tipo de la variable a double:
¿Me creerías si te digo que la función aún se puede mejorar más? Si tienes un conocimiento decente de estructuras de datos, sabrás que es muy probable que List.size() es algo que merece la pena copiar en memoria o, aún mejor, evitarlo completamente usando un foreach:
A partir de aquí, aunque se pueden seguir mejorando más elementos de la función, dichas mejoras empiezan a ser debatibles y dependientes de detalles relacionados con la implementación (por ejemplo, dividiendo el resultado de la suma incrementalmente en lugar de sólo al final).
La lección que espero transmitir con esta entrada es que incluso "algoritmos" relativamente sencillos como la media aritmética pueden dar mucho juego cuando uno se para a pensar en las diferentes optimizaciones aplicables.
Mostrando entradas con la etiqueta entrevista. Mostrar todas las entradas
Mostrando entradas con la etiqueta entrevista. Mostrar todas las entradas
06 marzo 2016
29 febrero 2016
Buscando trabajo en EEUU: Microsoft I
Igual que hice con Zappos, me decidí por echar el currículum en Microsoft sin conocer a nadie ni saber mucho de la empresa. Igualmente, no me esperaba mucho pero recibí una agradable sorpresa en forma de correspondencia electrónica unas pocas semanas más tarde. Como es habitual, el primer paso fue una entrevista telefónica de carácter técnico. Es posible que su estrategia haya cambiado desde entonces, pero cuando me entrevistaron a mí no era para un rol o equipo específico. A parte de verificar tus conocimientos técnicos (por enésima vez, ¡no mientas en tu currículum!), la primera entrevista sirve para identificar para qué rol en particular tus cualidades hacen de ti un buen candidato.
Representación artística de las solicitudes para cada puesto de trabajo público en Microsoft.
Puede que haya dicho antes que las entrevistas telefónicas son generalmente muy repetitivas y muy similares entre ellas; en este caso merece la pena enfatizar eso de nuevo porque todas las preguntas que me hicieron fueron, literalmente, de libro. Si uno busca "preguntas para entrevistas de trabajo", seguramente 10 de los 15 primeros resultados se correspondan con preguntas idénticas o casi idénticas a las que te pueden hacer en la entrevista telefónica con Microsoft. ¿Lo peor de todo? Los que hacen las preguntas no tienen conocimientos técnicos y ni siquiera son empleados de Microsoft. Siguen un guión y poco más. Imagino que, salvo por los candidatos recomendados internamente por empleados, los cientos si no miles de candidatos que echan currículum a palo son filtrados por una de las agencias de trabajo con las que Microsoft tiene contrato.
Así me imagino yo que deben ser las condiciones de trabajo de los que hacen la primera entrevista telefónica.
Después de responder a las poco originales preguntas con respuestas que, a este punto, yo tenía prácticamente memorizadas, la entrevista terminó con el típico ya te llamaremos. Unos pocos días más tarde, me llevé otra agradable sorpresa cuando me ofrecieron ir a una entrevista in situ; paquete completo incluido: todos los gastos pagados para el vuelo, estancia en hotel, y coche de alquiler. Por lo visto, había respondido muy bien a todas las preguntas (aunque no tiene mucho mérito cuando prácticamente recité las respuestas de memoria), pero había destacado especialmente en las preguntas relacionadas a las pruebas de software así que mi segunda entrevista estaría enfocada a ese rol en particular. Cuando uno entrevista con Microsoft, después de la primera entrevista telefónica, prácticamente toda la correspondencia se hace a través de un coordinador de reclutamiento. Es evidente que constantemente entrevistan a candidatos porque todo el proceso fue muy agradable, sin nada de estrés, y me mantuvieron completamente informado a cada paso.
Contaré como fue la entrevista in situ en la próxima entrada.
03 mayo 2014
Buscando trabajo en EEUU: Tesla Motors IV
Como dije en mi última entrada, el ingeniero jefe me introdujo brevemente a la posición y por qué me habían elegido a mí. Una vez hecho eso, dio comienzo a la parte técnica de la entrevista con preguntas sobre el lenguaje de programación C. La pregunta en sí no era muy complicada, más bien consistía en un ejercicio de implementación aunque tenía un pequeño truco. La pregunta la formuló de la siguiente manera:
Escribe una función que reciba un sólo byte como parámetro y devuelva el mismo byte pero con cada uno de sus bits invertidos de posición, es decir, que el primer bit aparezca en última posición, el segundo en penúltima, etc.
Pensé, ¡menos mal! Por fin una pregunta sencilla de entender y podré resolver sin problemas. Nada que ver con las preguntas de los canallas en Amazon, en las que el entrevistador se tiraba 40 minutos formulándola y me daban 20 para responderla. No tenía ni idea de la mala jugada que me iban a pasar los nervios... Normalmente, no tengo ningún problema enfrentándome a todo tipo de problemas bajo presión, pero Tesla era esa empresa que me podría ofrecer el trabajo con el que siempre había soñado (o eso creía entonces). A medida que escribía código en la pizarra, notaba como el nudo de la corbata se hacía más y más pequeño. Me atragantaba, tartamudeaba y decía cosas sin sentido. El ingeniero jefe, que como ya he dicho en repetidas ocasiones era un tipo de aspecto muy amigable, me repetía que me calmase con una sonrisa. ¡Un mal entrevistador me podría haber lanzado por la borda fácilmente!
Casi habría preferido vérmelas con un grupo de piratas que pasar un minuto más atragantándome.
Hasta tal punto decía cosas sin sentido, que el entrevistador me llegó a preguntar cuál era la diferencia entre a & 0x05 y a && 0x05! Después de implementar la solución, me preguntó si era óptima y le dije que por supuesto que no. No tenía ni idea de que estaba buscando una solución óptima, pensé que sólo quería ver mi capacidad para implementar la solución al problema, fallo mío por no preguntar. Cuando me pidió que buscase una solución más óptima al problema, después de balbucear unos minutos, le dije que mandaría todo a tomar por saco y lo pondría todo en un switch bien gordo para que el compilador se las viese con el asunto. Pero, según él, había otra solución más eficiente...
¿Más eficiente? Pensé que me estaría poniendo una trampa como ya hicieron algunos entrevistadores en Zappos, así que le insistí que un switch bien compilado es sólo una instrucción de salto. ¡Nada más eficiente que eso! Pero no, él insistía en que había otra solución mejor... Le dije que la única manera de hacerlo mejor, a costa de un mayor uso de memoria, sería con algún tipo de estructura de datos cargada en RAM, tipo hashtable o similar. Viendo que me acercaba a la idea pero que no llegaría nunca a la solución que él buscaba, me acabé rindiendo. Según él, la solución más eficiente era crear un array cuyos índices se correspondían con el byte buscado y cuyos valores eran el byte invertido. A decir verdad, esa era la solución más elegante de todas, pero todavía dudo que sea más eficiente que mis otras proposiciones dependiendo de las circunstancias.
Mi solución al problema a los ojos del ingeniero jefe, evidentemente ineficiente.
Bueno, no pasa nada. Seguro que la siguiente entrevista me va mejor, pensé. Era el turno del ingeniero senior. Según me dijo, le ficharon en Tesla como empleado treinta y algo. Un tipo alto, de avanzada edad, que hablaba muuuuuy despacio. Me hizo varias preguntas sobre la implementación del proyecto que les había presentado poco más de una hora antes. Puso un par de objeciones y generalmente insistió en el porqué de mis decisiones de diseño más que en la implementación en sí. La entrevista no duró mucho y no fue mal aunque tampoco diría que fue bien. ¡Siguiente!
Era el turno de un ingeniero de hardware. Con desdén, me preguntó si realmente no sabía mucho de circuitos. Entonces me preguntó si sabía lo que era VHDL; había oído hablar de ello pero en realidad no tenía ni idea. Entonces me dijo que había visto a pocos candidatos que no venían de una universidad con mucho renombre, mencionó Standford, MIT, Berkeley, Princeton... Dijo que viniendo de una universidad con menos nombre reduciría mis posibilidades. ¡Maldito elitista! También me preguntó cómo me fue la entrevista con el anterior ingeniero, porque a veces le tenía que tirar de la lengua para saber qué estaba pensando. Me comentó que las oficinas de SpaceX estaban a tiro de piedra (probablemente una de las únicas compañía que elegiría para trabajar antes que Tesla Motors). Para cuando se pasó el tiempo de la entrevista, no me había hecho ninguna pregunta relevante.
En mi penúltima entrevista, me las vería con el más joven de todos los entrevistadores. Al parecer, tenía conocimientos más cercanos a mi área de especialidad, concretamente estadística y modelos matemáticos. Fue una de las entrevistas más entretenidas que recuerdo. Hablamos de distribuciones, márgenes de error, defectos de fábrica y métodos para reconocerlos y mitigarlos, y un sin fin de temas interesantísimos. En cierto punto, me estaba intentando ilustrar cómo los gigantescos brazos robóticos ponen el parabrisas a los coches en la fábrica, con sus brazos completamente estirados y caminando como un robot, y no pude evitar soltar una carcajada. Afortunadamente él también pensó que la situación era cómica.
Así son los robots que ponen los parabrisas en las fábricas.
Mi último entrevistador sería el vicepresidente de ingeniería; en otras palabras, un pez bastante gordo. Para mi gran sorpresa, me hizo una pregunta de programación puramente técnica. Me pidió que escribiese un método en C que tomase 2 strings como argumentos y devolviese 1 string cuyos caracteres fueran el resultado de los caracteres de los 2 argumentos intercalados. Por ejemplo, si la función recibía "abcd" y "1234", tendría que devolver "a1b2c3d4". ¡Pan comido! Estaba cansado pero mucho menos nervioso que al comenzar las entrevistas, pero lo solucioné perfectamente en cuestión de un par de minutos. El hombre parecía bastante impresionado, y me dijo: "Lo has solucionado muy rápido... ¿Has hecho esta pregunta antes?". En ese momento se me hizo un nudo en la garganta. Me paré a pensar, ya había hecho bastantes entrevistas, y también había practicado muchas preguntas por mi cuenta, pero no, nunca había hecho esa pregunta. Casi deseé que la respuesta fuera afirmativa, puesto que no quería que dudase de mi honestidad. Como quedaba tiempo de sobra, decidió hacerme OTRA pregunta. ¡Vaya premio! Aunque, a decir verdad, la segunda pregunta era mucho más interesante:
En un lago hay un hombre en una barca con una piedra de tamaño grande, pero suficientemente pequeña para que el hombre pueda levantarla y lanzarla al agua. ¿Cuando la piedra se hunde, el nivel de agua en el lago sube, baja, o se queda igual?
La verdad, no tenía ni idea. La última vez que tomé una clase de física fue al menos 5 años atrás. Por experiencia, la respuesta correcta a ese tipo de preguntas les importa poco. Están más atentos a tu capacidad de razonamiento. Sabiendo eso, razoné, pensé en alto, y le dije diferentes maneras con las que probaría si mi razonamiento era válido o estaba equivocado. Poco después, me dejó esperando al despistado de recursos humanos (otra vez) y me acompañaron al vestíbulo donde me dijeron que ya se pondrían en contacto conmigo en los próximos 7 días.
24 enero 2014
Buscando trabajo en EEUU: Tesla Motors III
Después de recibir el visto bueno tras mi entrevista telefónica con el ingeniero jefe, la misma secretaria asistente de recursos humanos, que me había llamado casi dos semanas atrás, me envió un par de formularios a rellenar para concretar una fecha para la entrevista in situ. Como tal oportunidad no se tiene todos los días, les dejé muy claro que cuanto antes mejor, porque no hay que ser un genio para saber que por cada vacante tienen miles de personas que les envían su currículum.
En menos de dos días, ya habíamos concretado fecha, hotel y vuelo, pero la historia tenía truco. Como parte de la entrevista, tendría que hacer una presentación sobre cualquiera de mis proyectos a todos los miembros del equipo de trabajo, más el ingeniero jefe, más el jefe del ingeniero jefe. En fin, que me acababa de meter en un jardín sin flores.
¡Con lo que me gustan a mí las presentaciones! Licencia CC Wikimedia Commons
Por suerte, como me había graduado de la universidad hacía menos de dos meses, pude utilizar mi proyecto de fin de carrera, para el que tuve que hacer una presentación y escribir un detallado documento sobre su funcionamiento. Aun así, tener que hacer una presentación durante la entrevista de trabajo daba bastante miedito...
Viajar a Palo Alto, California, fue un auténtico placer. El tiempo allí es una maravilla, especialmente comparado con el Medio Oeste de Estados Unidos a finales del invierno, aunque tampoco tanto mejor comparado con algunos puntos de la costa mediterránea. Evidentemente, aunque tenía vagas esperanzas, el coche de alquiler no era un Tesla Model S; en su lugar, me habían reservado un Mishubishi Lancer así que tampoco voy a quejarme. El hotel, aunque muy bonito y bien cuidado, no era ni mucho menos tan lujoso como el hotel que me reservaron para mi entrevista con Amazon. Pero, ¡y eso qué más daba! Bastante preocupado estaba yo intentando prepararme para la presentación y, encima, tal y como me comunicaron unos pocos días antes de la fecha fijada, también tendría una entrevista con cada uno de los espectadores de la presentación. Intentando estar tan preparado como me fuera posible, tuve la desafortunada idea de rebuscar por internet quiénes eran mis entrevistadores. La idea, aunque buena, la describo como desafortunada porque en lugar de ayudarme a prepararme me dejó bastante abrumado. Mis entrevistadores, todos de carácter técnico, tenían perfiles más dignos de trabajar para una agencia espacial que para un fabricante de coches: licenciaturas y másters de universidades mundialmente conocidas como Standford, Berkeley, MIT... Y un sin fin de experiencia previa en compañías de tanto nombre como Apple o Google. En otras palabras, que me esperaba la del pulpo. ¡Pero no todo era negativo! Como ya había descubierto en otras entrevistas para las que tuve que viajar casi de costa a costa en EEUU (Zappos, Amazon...), el huso horario jugaba a mi favor. Como acabé contando ovejitas antes de las diez de la noche, por la mañana estaba mucho más despierto y alerta para las entrevistas. Para la guinda del pastel, de camino a la entrevista y atascado en un tráfico horrible (aunque iba con tiempo de sobra, porque ya me habían avisado del tráfico), mi amiguísimo Phil Collins me dio algo de ánimo por la radio.
Tan pegadiza es la canción que me permitió darme un respiro y dejar de darle vueltas a la cabeza unos minutos
A medida que me acercaba a la zona de las oficinas de Tesla Motors, veía más y más coches de la marca por la carretera; cierto es que la vista impresionaba. Una vez llegué a las oficinas, me sentí un poco decepcionado de lo pequeño que era el complejo pero ver tantos coches eléctricos me distrajo bastante de tal decepción. Me dí un par de vueltas por el parking tan sólo para echar un ojo a la cantidad de cochazos por allí aparcados. Apenas 15 minutos antes de la hora fijada para mi entrevista, entré y me presenté a la secretaria, y entonces... esperé. Y luego esperé un poco más. Cinco minutos pasados la supuesta hora de la entrevista, y todavía esperando. Le pedí a la secretaria que llamara al tipo de recursos humanos que se suponía vendría a recogerme, y me dijo que en Tesla no se comunican por teléfono, pero que le mandaría un email inmediatamente. Ya habían pasado 15 minutos después de la hora fijada, y aún nada. Me empecé a poner un poco nervioso. 20, 25 minutos.... Entonces la secretaria decidió no seguir el protocolo y por fin se dignó a llamar al de recursos humanos. "Bajará en 5 minutos", me dijo. Otros 10-15 minutos más tarde, es decir, casi tres cuartos de hora después de la hora acordada, un hombre con pinta de bastante despistado se presentó como la persona a quien estaba esperando, y me pidió que subiera a la sala de reuniones tan rápido como pudiera o no me daría tiempo a hacer la presentación.
Genial, como hacer una presentación ante la presión de una entrevista de trabajo no era suficiente, encima tenía que preocuparme del tiempo. Me llevaron a una sala de reuniones en la que casi todos mis entrevistadores estaban esperando con tecnología bastante anticuada, por lo que no pude conectar mi tableta y tuve que pedir prestado un portátil. La presentación en sí no fue tan mal, aunque estaba tan nervioso que me olvidé de darles una copia de los documentos para que pudieran leerlo mientras hablaba de ello pero creo que, por lo demás, lo hice bastante bien.
Coches de la marca Tesla Motors en el parking del complejo
Después de eso, el despistado de recursos humanos me dio un pequeño paseo por el complejo. Me hubiera encantado pasar más tiempo por la fábrica pero lo que más me impresionó sin duda eran las "oficinas" en sí. Como en Zappos, me contaron que todos los empleados incluyendo el CEO, Elon Musk, tenían su sitio en el mismo espacio abierto aunque, que casualidad, el CEO no estaba allí en ese momento. Recuerdo tener la sensación de estar en un sitio parecido a como pintan Wall Street en las películas, con muchísimo ruido, gente corriendo de un lado para otro, los pocos que parecían estar concentrados en algo tenían auriculares enormes para poder trabajar... Por no haber, no había ni cubículos, eran todo filas gigantes de mesas y cada empleado tenía su silla y su nombre en una placa, nada más.
Entonces, me llevaron a otra sala de reuniones y, como en las entrevistas para otras compañías, me dijeron que pasaría allí el resto del día. Mi primera entrevista era con el ingeniero jefe. Un hombre muy simpático sin mucho aspecto de ingeniero, la verdad. Empezó a hablarme sobre la posición y por qué estaba allí. Al parecer, tuvieron a un becario el verano anterior que había trabajado en una herramienta escrita en Python que se encargaba de compilar y publicar contenido a distintos servidores sobre las pruebas hechas a las baterías de los coches en la línea de producción, para su posterior análisis estadístico. Por lo visto, no tenían a muchos empleados con experiencia con tal lenguaje de programación, y mi currículum les pareció una buena combinación para una posición muy distinta a la que me había presentado varios meses atrás. Para quien no lo sepa, la mayoría de las empresas te dicen que, incluso si no te dan una entrevista para la posición que estabas buscando, se guardarían tu currículum por si encontraban algo en el futuro. Yo siempre pensé que eso lo decían simplemente para levantar la moral de aquellos que no consiguieron una entrevista, pero por lo visto al ingeniero jefe le gustó mi currículum de entre la pila de miles que habían acumulado durante los últimos 6 meses. Vamos, que había conseguido la entrevista completamente de carambola.
A partir de ahí, empezó la parte técnica de las entrevistas. Pero de eso hablaré en una próxima entrada que ésta ya es suficientemente larga.
25 agosto 2013
Buscando trabajo en EEUU: Tesla Motors II
En mi última entrada conté la historia de cómo había chafado miserablemente la pequeña prueba que me pidieron completar los de recursos humanos de Tesla Motors. Me dijeron que me contactarían en 2 ó 3 días y yo, que me esperaba una negativa rotunda, me quedé todavía más decepcionado cuando al cabo de más de una semana no me habían llamado todavía. Parecía evidente que no se iban a molestar a perder el tiempo conmigo...
Sin embardo, el hecho de que hubiesen elegido mi currículum de entre los miles que deben tener almacenados y que me llamasen para una oportunidad de trabajo como ingeniero de firmware en pruebas no era toda la suerte que me esperaba con Tesla. Tras 8 días de espera, y sin ninguna esperanza de que me llamasen de nuevo a esas alturas, recibí una llamada inesperada con un prefijo de Palo Alto, California. Sin andarse con muchos rodeos, una secretaria de Tesla Motors me pidió algunos detalles para coordinar la fecha y hora de una entrevista telefónica con el que sería el jefe del puesto como ingeniero que ya había dado por perdido. Yo, viendo cómo se las gastan y lo mucho que me hicieron esperar la última vez, les dije que cuanto antes mejor.
Parecía haber luz al final de mi túnel de entrevistas gracias a mi golpe de suerte. Licencia CC Wikimedia Commons
Antes de que tuviera tiempo de pensarlo dos veces, ya había colgado el teléfono tras concertar una entrevista para el día siguiente; casi inmediatamente me empezaron a surgir las dudas. ¿Y si me preguntan cosas similares al pequeño examen? Evidentemente, no podría haber hecho muy mal puesto que me habían llamado, pero estaba bastante convencido de que bien lo que se dice bien tampoco podría haber salido. ¡Tendría que haber retrasado la entrevista al menos una semana para poder ponerme al día en electrónica! Empecé a ojear la Wikipedia, revisé el examen que me habían dado para prepararme para preguntas similares, desempolvé un par de libros... En un par de horas, estaba completamente agobiado y cada vez con menos esperanzas de salir vivo después de la entrevista que me esperaba en menos de 24 horas. La paliza que me dieron mis amigos de Amazon iba a ser una pequeña riña entre churumbeles en comparación con lo que se me venía encima, y encontrar un trabajo en Tesla me importaba bastante más que todas mis anteriores entrevistas juntas.
Al final, decidí no estresarme y aceptar que yo no domino el campo de la electrónica como domino el de la programación. Al fin y al cabo, nunca había admitido ser un experto en el tema ni en mi currículum (recuerda, nunca mientas en tu currículum) ni en ninguna de las llamadas telefónicas. Lo mejor sería ser completamente honesto y mantener las expectativas bajas, tal vez sería capaz de responder alguna de las más básicas preguntas pero, fuera de mi especialidad, no creo que nadie se esperase que yo fuera capaz de demostrar conocimiento alguno. Por suerte, esos pensamientos me ayudaron a dormir un poco más tranquilo.
Ya, es la misma foto que en la anterior entrada, ¡¿pero has visto el coche?! Licencia CC Wikimedia Commons
A la mañana siguiente, exactamente un minuto más tarde de la hora fijada, recibí otra llamada de Palo Alto. Tras una brevísima introducción, mi entrevistador se excusó por haberme llamado tarde, lo cual me hizo pensar que estaba hablando con una persona muy meticulosa. Para mi sorpresa, empezó con unas cuantas preguntas más típicas de recursos humanos que de ingeniero jefe: Quién eres, cuál es tu experiencia, háblame de alguno de los proyectos que hayas realizado durante tu carrera... Después de charlar unos 20 minutos se me hizo un nudo en la garganta en cuanto dijo "muy bien, ahora vamos a revisar el pequeño examen que te pidieron hacer". Al parecer, el de recursos humanos nunca le envió mi examen o se debió perder en su bandeja de correo, así que me pidió que se lo reenviara a él directamente. De haberlo sabido, ¡habría pulido mis respuestas hasta la perfección durante todos esos días! Incluso antes de que comenzara a revisarlo, decidí cortar por lo sano y decirle que, con mi experiencia y mis credenciales, no tenía ni pajolera idea de electrónica. Sorprendentemente, y para mi grandísimo alivio, no pareció preocupado para nada en el tema. Procedió entonces a revisar tan sólo mis respuestas a las preguntas más orientadas a programación, las cuales fueron todas correctas excepto por una de ellas que había dejado parcialmente incompleta. En cuanto dijo que faltaba un pequeño detalle en mi respuesta sabía exactamente de qué estaba hablando, probablemente gracias a las muchas veces que revisé el examen el día anterior; sin muchos problemas le expliqué qué fallaba y qué hacía falta para solucionar el problema.
Aunque es fácil tener una idea general de cómo fue una entrevista, es difícil leer la mente del entrevistador. Por eso, por muy bien que me fuese una entrevista, los días de espera hasta que me llamaban de nuevo siempre eran bastante difíciles. Rompiendo la habitual tendencia de mis anteriores entrevistadores de darse unos días para deliberar el resultado de la entrevista, mi entrevistador me dijo que le había causado buena impresión y que me iban a mandar a California para una entrevista en persona. ¡No me lo podía creer! Y, además, me dejó muy tranquilo cuando me aseguró al final de la entrevista que no debía preocuparme por la electrónica, porque mi perfil les encajaba por otras habilidades. Sin lugar a dudas, tenía muchísimas ganas de ir a esa entrevista, y las expectativas me hacían ver mis fracasos con Amazon y Zappos como cosa del pasado.
La continuación de esta entrada puedes encontrarla aquí.
27 marzo 2013
Buscando trabajo en EEUU: Tesla Motors I
Después de mis estrepitosos fracasos con Zappos y Amazon, yo estaba de bajón. Especialmente tras mi entrevista con Amazon, debido a lo mucho que me había preparado para ello. Inesperadamente, recibí una llamada de un representante de recursos humanos de Tesla Motors tan sólo dos días después de volver de mi entrevista con Amazon, ¡nada mejor que eso para levantarme el ánimo!
Para los que no sepan quienes son Tesla Motors, es una empresa basada en la archiconocida Silicon Valley que se dedica a fabricar coches eléctricos de lujo o al menos así lo considero yo, puesto que el modelo más barato que venden cuesta la friolera de $60,000. Dirigida por el empedernido empresario Elon Musk, ex-CEO de PayPal y actual CEO de SpaceX y SolarCity. Si pudiese elegir cualquier empresa en la que trabajar como ingeniero, ésa sería sin duda SpaceX debido a mi enorme fascinación por la exploración espacial; pero no es mucho menor mi fascinación por las tecnologías del transporte, particularmente la aeronáutica y, cómo no, la automovilística. Tras los atentados terroristas del 11 de septiembre, en Estados Unidos está muy restringido para una empresa el dar trabajo a cualquiera que no sea ciudadano americano si la empresa tiene algún tipo de contrato con el gobierno. De hecho, es simple y llanamente ilegal para todas las empresas relacionadas con la aeronáutica, por lo que SpaceX, que pese a ser una compañía privada trabaja en colaboración con NASA para determinados proyectos y ellos sí tienen contratos directos con el gobierno, no era una opción. Sin la más mínima esperanza de trabajar en el sector de la aeronáutica, ya que tengo nacionalidad española, me decantaría probablemente por alguna empresa en el sector automovilístico. El problema es que la gran mayoría de fabricantes de coches en EEUU están en Detroit y, para quien no lo sepa, no es un sitio muy agradable en el que vivir. Como demostración, fue catalogada como la ciudad más despreciable de Estados Unidos en el 2013 por la prestigiosa revista Forbes, y suele estar en la cima o cerca de ella en otras categorías similares. Dicho eso, el hecho de que Tesla Motors está situada en California hace su empresa mucho más apetecible, todo esto sin tener en cuenta que allí hacen barbaridades como ésta:
El Tesla Model S ha sido considerado como coche del año por varias publicaciones. Licencia CC Wikimedia Commons
Así pues, Tesla Motors se perfilaba para mí como uno de esos trabajos de ensueño a los que podría aspirar si hubiese atendido alguna muy prestigiosa universidad como Stanford o MIT, pero no tenía muchas esperanzas en poder optar a trabajar allí. Reluctantemente, les envié mi solicitud allá por noviembre tan pronto como tuve mi currículo preparado para mi inminente graduación universitaria pensando que nunca me contestarían. Para mi sorpresa, estando todavía en España, me mandaron un correo electrónico a principios de enero para decirme que había un puesto de trabajo en el que ellos estaban interesados en tenerme como candidato, pero no me dieron más detalles. Inmediatamente, busqué entre las nuevas ofertas de empleo y encontré varias muy recientes como becario que tenían como condición el ser todavía estudiante, pero yo ya me había graduado. Decepcionado, les contesté diciendo que sí estaba interesado pero que a falta de detalles me veía obligado a clarificar que ya no era estudiante, sino que estaba buscando un trabajo a tiempo completo. Debo aclarar que, para conseguir un trabajo en Tesla, uno debe pertenecer a una de las siguientes categorías:
- Ser uno de los mejores ingenieros del mundo en tu especialidad, en cuyo caso no estarás leyendo esto de todas maneras.
- Ser extremadamente pro-activo y/o tener recomendaciones por parte de alguien que ya trabaje en Tesla y no sea un pringao cualquiera.
- Tener mucha, muchísima suerte.
Como dije antes, me llamaron dos días después de mi entrevista con Amazon, una semana y media más tras el primer contacto, para informarme de que estaban buscando a alguien con un perfil cercano al mío: recién graduado para un puesto a tiempo completo de ingeniero de pruebas para el entorno de fabricación en el grupo de firmware, lo cual me situaba indiscutiblemente como miembro de la tercera categoría: me sentí como si me acabase de tocar la lotería. Aunque nunca me había planteado el trabajar en la rama de pruebas de software, cuanto más leía al respecto más me gustaba, incluso sobrepasando mi gusto por trabajar en la rama de desarrollo de software. La conversación fue muy amigable, el tipo de recursos humanos me habló sobre la compañía en general y sobre sus objetivos, incluyendo toda la parodia de energías verdes y limpias. Al final, me pidió que le diese alguna fecha para hacer "un pequeño examen" que me llevaría más o menos media hora. Como estaba tan emocionado en el momento y tenía un par de horas libres, le dije que podía empezar la prueba inmediatamente, de lo cual me arrepentí más temprano que tarde...
El "pequeño examen" resultó ser bastante más complicado de lo que yo pensaba. Por desgracia, la prueba estaba considerada bajo un acuerdo de confidencialidad, por lo que no puedo publicar aquí preguntas específicas. Simplemente diré que, aunque una buena parte de las preguntas eran sobre el uso básico de punteros y memoria en C, dejó en evidencia mi completa carencia de conocimiento sobre electrónica en general gracias a un buen número de preguntas relacionadas con circuitos. Me dio una hora para completarlo y se lo envié en el último minuto después de hacer tanto uso de internet como me fue posible para encontrar las respuestas de más de una pregunta, pese a que los "términos de uso" dejaban claro que el uso de materiales de apoyo para completar la prueba estaban prohibidos. Aunque tenía la intención de ser legal, la sensación de desesperación al intentar descifrar algunas de las preguntas me llevó a hacerlo. Además, estoy convencido de que prácticamente todos los candidatos también usarían internet para ayudarse en sus respuestas, y no estaba dispuesto a darle a nadie ningún tipo de ventaja.
Después de enviarle mis respuestas, de las cuales no me sentía para nada orgulloso, el de recursos humanos me dijo que me contactarían en 2 ó 3 días con los resultados, pero de eso hablaré en otra entrada.
Ejemplo del tipo de preguntas que hacen en el "pequeño examen". Licencia CC Flickr
El "pequeño examen" resultó ser bastante más complicado de lo que yo pensaba. Por desgracia, la prueba estaba considerada bajo un acuerdo de confidencialidad, por lo que no puedo publicar aquí preguntas específicas. Simplemente diré que, aunque una buena parte de las preguntas eran sobre el uso básico de punteros y memoria en C, dejó en evidencia mi completa carencia de conocimiento sobre electrónica en general gracias a un buen número de preguntas relacionadas con circuitos. Me dio una hora para completarlo y se lo envié en el último minuto después de hacer tanto uso de internet como me fue posible para encontrar las respuestas de más de una pregunta, pese a que los "términos de uso" dejaban claro que el uso de materiales de apoyo para completar la prueba estaban prohibidos. Aunque tenía la intención de ser legal, la sensación de desesperación al intentar descifrar algunas de las preguntas me llevó a hacerlo. Además, estoy convencido de que prácticamente todos los candidatos también usarían internet para ayudarse en sus respuestas, y no estaba dispuesto a darle a nadie ningún tipo de ventaja.
Después de enviarle mis respuestas, de las cuales no me sentía para nada orgulloso, el de recursos humanos me dijo que me contactarían en 2 ó 3 días con los resultados, pero de eso hablaré en otra entrada.
24 marzo 2013
Buscando Trabajo en EEUU: Amazon IV
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.
23 marzo 2013
Contando monedas
| Valor de la moneda | $0.25 | $0.10 | $0.07 | $0.01 |
| Número de monedas | 4 | 0 | 1 | 2 |
Así, primero utilizamos tantas monedas de $0.25 como podamos. Si utilizamos 5, tendríamos un valor total de $1.25, por lo que ya nos habríamos pasado. De acuerdo al algoritmo antes descrito, utilizaremos sólo 4 para un valor total de $1.00. Entonces, pasamos a la siguiente moneda más grande, con valor de $0.10. Si utilizamos 1 moneda de $0.10, tendremos un valor total de $1.10 y nos habremos pasado otra vez, por lo que no habrá que utilizar ninguna moneda de ese valor. Aplicando las mismas reglas a todas las monedas en orden decreciente, acabaríamos con la distribución representada en la anterior tabla. Utilizamos un total de 7 monedas y, salvo que esté equivocado en algo muy obvio, no hay ninguna manera más óptima de distribuir las monedas para utilizar un número menor de ellas. ¡Pero mi algoritmo era erróneo! Después de pelearme con la implementación del código, mi entrevistador utilizó la prueba por contradicción para demostrar que mi algoritmo no siempre encontraría la solución más óptima. ¿Qué pasaría si el valor buscado fuese $1.15 utilizando la misma lista de monedas? Con el algoritmo de antes, tendríamos la siguiente distribución:
| Valor de la moneda | $0.25 | $0.10 | $0.07 | $0.01 |
| Número de monedas | 4 | 1 | 0 | 5 |
Estaríamos utilizando un total de 10 monedas, pero obviamente la siguiente distribución es más óptima:
| Valor de la moneda | $0.25 | $0.10 | $0.07 | $0.01 |
| Número de monedas | 4 | 0 | 2 | 1 |
Puesto que con la última distribución sólo utilizamos 7 monedas, queda demostrado que el algoritmo ha fallado. Es importante mencionar que, si tuviéramos una moneda de $0.05 en vez de $0.07, el algoritmo funcionaría perfectamente, la explicación está relacionada con la primalidad de los números de la lista entre ellos. Con mi algoritmo y mi autoestima hechos trizas, mi entrevistador me preguntó si había algún otro algoritmo que pudiese encontrar la solución más óptima, y en ese momento le respondí que posiblemente no haya nada mucho mejor que utilizar una búsqueda de fuerza bruta. Entonces, me dí cuenta de que el problema podía ser representado como una serie de restricciones lineares por lo que podía ser resuelto mediante la programación lineal. Después de que mi entrevistador le pidiera 5 minutos más a su relevo, que ya estaba esperando en la puerta, me permitió que le explicara como resolvería el problema si tuviese acceso a algún método para resolver ecuaciones lineales, como el algoritmo simplex. Tras haber estudiado con detalle el problema de la mochila en la universidad con anterioridad, estaba bastante decepcionado por haber sido incapaz de reconocer una solución que no estuviese errada sin la ayuda del entrevistador.
21 marzo 2013
Buscando Trabajo en EEUU: Amazon III
Ésta es la tercera y penúltima parte de mi experiencia entrevistando con Amazon intentando conseguir trabajo para una posición de ingeniero de software. ¡Recomiendo leer la primera y la segunda parte antes!
Para mi sorpresa, un par de días después de mi segunda entrevista telefónica, Amazon me mandó un correo electrónico ofreciéndome una entrevista in situ en sus oficinas centrales de Seattle. Por desgracia, la invitación me llegó sólo unos días antes de las vacaciones de Navidad y yo ya había comprado mi billete para pasar las festividades en España, así que no pude concertar una cita hasta casi un mes más tarde. Como es habitual con este tipo de empresas líderes en el sector, todos los gastos del viaje serían pagados por Amazon, incluyendo billetes de avión, hotel, comidas y transporte una vez en Seattle... ¡Todo un lujo!
Dije antes que me sorprendió llegar a la entrevista in situ pero no porque hiciese mal en mis dos entrevistas telefónicas, sino porque habitualmente la mayoría de los candidatos tienen que pasar tres o incluso cuatro entrevistas por teléfono antes de recibir la invitación para ir al estado de Washington. A punto de regresar a EEUU, aproximadamente una semana antes de mi entrevista, decidí que sería una buena idea buscar algo de consejo y leer las experiencias de otros en lo relativo a entrevistar con el gigante del comercio electrónico, y encontré algunas historias de terror que me quitaron el sueño. En algunos sitios declaran conseguir un trabajo en Amazon como una misión imposible, y eso no se aleja mucho de la realidad puesto que fue reconocida como una de las empresas en la que es más difícil conseguir una oferta por uno de los más prestigiosos portales dedicados a la búsqueda de trabajo. Si me permitís, os voy a dar un pequeño adelanto y voy a confirmar que sí, las entrevistas de trabajo en Amazon son chungas de narices.
Más que estar preparado para la guerra, yo había prácticamente aceptado ya mi derrota. Las pocas historias de éxito que encontré ponían tremendo énfasis en la grandísima preparación previa a la entrevista (algunos incluso lo comparaban con una tesis doctoral). Aunque había decidido relajarme y al menos disfrutar de la experiencia, el día antes de volar a Estados Unidos cambié drásticamente de opinión y llegué a la conclusión de que, si tenía la grandísima oportunidad de entrevistar con una empresa como Amazon, ¡lo mínimo que podía hacer era intentar hacerlo lo mejor posible! Recopilé una buena lista de preguntas típicas de una entrevista como ingeniero de software y la imprimí en papel para llevármela conmigo en el avión, y aquí viene uno de los más importantes consejos para este tipo de entrevistas: Practica, practica, practica. Pero con practicar no basta, hazlo de la manera más realista posible. En una entrevista no te van a dar un editor de texto con coloreado de texto y autocompletado de código, te van a dar una pizarra y una porquería de rotuladores. Aunque tengo una pizarra de tamaño mediano que a veces utilizo para ordenar las ideas iniciales del desarrollo de algún prototipo, no fui tan lejos como para usarla para practicar para la entrevista. En su lugar utilicé bolígrafo y papel normal y corriente que se me acabó, así que terminé escribiendo en los márgenes de las revistas con los anuncios raros que ponen junto a los panfletos con los protocolos de seguridad y demás.
Debo admitir que el tiempo pasó volando gracias a la gran concentración que requiere escribir código, y estuve "estudiando" prácticamente las 9 horas de vuelo intercontinental. Estoy convencido de que la gente sentada cerca mío pensaba que padecería algún trastorno relacionado con el autismo o que era extremadamente antisocial, pero a decir verdad apenas tengo recuerdo alguno de ese vuelo. Sin embargo, mi trabajo no fue en vano, puesto que para cuando aterrizamos en el aeropuerto internacional de Atlanta era capaz de escribir una implementación de árboles binarios incluyendo todos los métodos necesarios en apenas 4 ó 5 minutos tanto en C como en Java. Si hubiese tenido ese nivel de práctica cuando estaba entrevistando con Zappos habría conseguido el trabajo con total seguridad, pero por desgracia no me había tomado la preparación previa a las entrevistas lo suficientemente en serio hasta entonces.
Incluso cuando tienes un ordenador delante, escribir en papel puede ser útil. Licencia CC Wikimedia Commons
Tras unos días de preparación a tope en los que me pasé programando a papel y boli durante incontables horas, casi hasta soñaba en binario y podía implementar la mayoría de las estructuras de datos más conocidas y casi todos los algoritmos relacionados con ellas. Presté especial atención a estructuras de datos y algoritmos que tenían importancia para el concepto de escalabilidad, puesto que Amazon es una empresa que trabaja con muchos millones de clientes y todavía más elementos de logística; siendo honesto, me sentía muy preparado aunque para nada confiado. Era consciente de que mis posibilidades eran pequeñas pero también sabía que la inmensa mayoría de los aspirantes no llegan lo suficientemente lejos como para tener la oportunidad de ir a una entrevista in situ.
Al fin llegó la hora de viajar a Seattle, que está a aproximadamente 3.300 km de, por aquel entonces, mi lugar de residencia, lo cual debería transmitir la inmensidad de territorio cubierto bajo la bandera americana. El vuelo, como dije antes, fue pagado en su totalidad por los chicos de Amazon, durante el cual continué practicando a escribir código en papel. La mujer que estaba sentada a mi lado me estuvo mirando raro casi todo el vuelo, hasta que al final me preguntó si lo que escribía eran "programas para ordenadores". Aunque intenté explicarle que lo que yo escribía no iba a acabar en ningún ordenador, fue completamente inútil, pero cuando le dije que iba a entrevistar con Amazon me contó que ella trabajaba en el, si no recuerdo mal, Seattle Times, un prestigioso periódico cuyas oficinas centrales estaban localizadas muy cerca de las de Amazon. Según ella, me iban a contratar seguro después de ver lo mucho que había practicado durante el vuelo y especialmente "en estos tiempos" en los que no paran de contratar como locos. Desgraciadamente, la realidad respecto a conseguir un trabajo con el gigante del comercio electrónico distaba bastante de la imagen que tenía la señora en su mente.
Después de un breve viaje en taxi (pagado por Amazon) llegué al increíblemente lujoso hotel en el corazón de Seattle. Ése fue, sin duda, uno de los más pomposos hoteles en los que he pasado una noche en mi vida. Tenía el resto de la tarde y gran parte de la mañana siguiente para relajarme durante las horas previas a mi entrevista, aunque debo admitir que, por primera vez en mucho tiempo, estaba algo nervioso... ¡Hablaré del resto de la entrevista en la última entrada de esta serie próximamente!
Para mi sorpresa, un par de días después de mi segunda entrevista telefónica, Amazon me mandó un correo electrónico ofreciéndome una entrevista in situ en sus oficinas centrales de Seattle. Por desgracia, la invitación me llegó sólo unos días antes de las vacaciones de Navidad y yo ya había comprado mi billete para pasar las festividades en España, así que no pude concertar una cita hasta casi un mes más tarde. Como es habitual con este tipo de empresas líderes en el sector, todos los gastos del viaje serían pagados por Amazon, incluyendo billetes de avión, hotel, comidas y transporte una vez en Seattle... ¡Todo un lujo!
Dije antes que me sorprendió llegar a la entrevista in situ pero no porque hiciese mal en mis dos entrevistas telefónicas, sino porque habitualmente la mayoría de los candidatos tienen que pasar tres o incluso cuatro entrevistas por teléfono antes de recibir la invitación para ir al estado de Washington. A punto de regresar a EEUU, aproximadamente una semana antes de mi entrevista, decidí que sería una buena idea buscar algo de consejo y leer las experiencias de otros en lo relativo a entrevistar con el gigante del comercio electrónico, y encontré algunas historias de terror que me quitaron el sueño. En algunos sitios declaran conseguir un trabajo en Amazon como una misión imposible, y eso no se aleja mucho de la realidad puesto que fue reconocida como una de las empresas en la que es más difícil conseguir una oferta por uno de los más prestigiosos portales dedicados a la búsqueda de trabajo. Si me permitís, os voy a dar un pequeño adelanto y voy a confirmar que sí, las entrevistas de trabajo en Amazon son chungas de narices.
Indumentaria recomendada para una entrevista en Amazon. Licencia CC Wikimedia Commons
Más que estar preparado para la guerra, yo había prácticamente aceptado ya mi derrota. Las pocas historias de éxito que encontré ponían tremendo énfasis en la grandísima preparación previa a la entrevista (algunos incluso lo comparaban con una tesis doctoral). Aunque había decidido relajarme y al menos disfrutar de la experiencia, el día antes de volar a Estados Unidos cambié drásticamente de opinión y llegué a la conclusión de que, si tenía la grandísima oportunidad de entrevistar con una empresa como Amazon, ¡lo mínimo que podía hacer era intentar hacerlo lo mejor posible! Recopilé una buena lista de preguntas típicas de una entrevista como ingeniero de software y la imprimí en papel para llevármela conmigo en el avión, y aquí viene uno de los más importantes consejos para este tipo de entrevistas: Practica, practica, practica. Pero con practicar no basta, hazlo de la manera más realista posible. En una entrevista no te van a dar un editor de texto con coloreado de texto y autocompletado de código, te van a dar una pizarra y una porquería de rotuladores. Aunque tengo una pizarra de tamaño mediano que a veces utilizo para ordenar las ideas iniciales del desarrollo de algún prototipo, no fui tan lejos como para usarla para practicar para la entrevista. En su lugar utilicé bolígrafo y papel normal y corriente que se me acabó, así que terminé escribiendo en los márgenes de las revistas con los anuncios raros que ponen junto a los panfletos con los protocolos de seguridad y demás.
Debo admitir que el tiempo pasó volando gracias a la gran concentración que requiere escribir código, y estuve "estudiando" prácticamente las 9 horas de vuelo intercontinental. Estoy convencido de que la gente sentada cerca mío pensaba que padecería algún trastorno relacionado con el autismo o que era extremadamente antisocial, pero a decir verdad apenas tengo recuerdo alguno de ese vuelo. Sin embargo, mi trabajo no fue en vano, puesto que para cuando aterrizamos en el aeropuerto internacional de Atlanta era capaz de escribir una implementación de árboles binarios incluyendo todos los métodos necesarios en apenas 4 ó 5 minutos tanto en C como en Java. Si hubiese tenido ese nivel de práctica cuando estaba entrevistando con Zappos habría conseguido el trabajo con total seguridad, pero por desgracia no me había tomado la preparación previa a las entrevistas lo suficientemente en serio hasta entonces.
Tras unos días de preparación a tope en los que me pasé programando a papel y boli durante incontables horas, casi hasta soñaba en binario y podía implementar la mayoría de las estructuras de datos más conocidas y casi todos los algoritmos relacionados con ellas. Presté especial atención a estructuras de datos y algoritmos que tenían importancia para el concepto de escalabilidad, puesto que Amazon es una empresa que trabaja con muchos millones de clientes y todavía más elementos de logística; siendo honesto, me sentía muy preparado aunque para nada confiado. Era consciente de que mis posibilidades eran pequeñas pero también sabía que la inmensa mayoría de los aspirantes no llegan lo suficientemente lejos como para tener la oportunidad de ir a una entrevista in situ.
Al fin llegó la hora de viajar a Seattle, que está a aproximadamente 3.300 km de, por aquel entonces, mi lugar de residencia, lo cual debería transmitir la inmensidad de territorio cubierto bajo la bandera americana. El vuelo, como dije antes, fue pagado en su totalidad por los chicos de Amazon, durante el cual continué practicando a escribir código en papel. La mujer que estaba sentada a mi lado me estuvo mirando raro casi todo el vuelo, hasta que al final me preguntó si lo que escribía eran "programas para ordenadores". Aunque intenté explicarle que lo que yo escribía no iba a acabar en ningún ordenador, fue completamente inútil, pero cuando le dije que iba a entrevistar con Amazon me contó que ella trabajaba en el, si no recuerdo mal, Seattle Times, un prestigioso periódico cuyas oficinas centrales estaban localizadas muy cerca de las de Amazon. Según ella, me iban a contratar seguro después de ver lo mucho que había practicado durante el vuelo y especialmente "en estos tiempos" en los que no paran de contratar como locos. Desgraciadamente, la realidad respecto a conseguir un trabajo con el gigante del comercio electrónico distaba bastante de la imagen que tenía la señora en su mente.
Después de un breve viaje en taxi (pagado por Amazon) llegué al increíblemente lujoso hotel en el corazón de Seattle. Ése fue, sin duda, uno de los más pomposos hoteles en los que he pasado una noche en mi vida. Tenía el resto de la tarde y gran parte de la mañana siguiente para relajarme durante las horas previas a mi entrevista, aunque debo admitir que, por primera vez en mucho tiempo, estaba algo nervioso... ¡Hablaré del resto de la entrevista en la última entrada de esta serie próximamente!
17 marzo 2013
Buscando Trabajo en EEUU: Amazon II
Esta entrada es la continuación de la primera parte de la serie relatando mi experiencia entrevistando con Amazon, te recomiendo que leas la primera antes aquí.
Había conseguido que me llamasen de Amazon para una entrevista telefónica, y fui capaz de responder las preguntas que me hicieron en la primera parte de la entrevista razonablemente bien pero, sin venir a cuento ni nada, el entrevistador me pidió que implementara una tabla hash en un área de texto que él podía ver mientras yo escribía de manera sincronizada. Cuando me preguntó si sabía lo que era una tabla hash, yo mentí como un bellaco y le dije que sí porque el concepto me sonaba bastante y no me imaginaba que me fuese a preguntar algo tan complicado. Mientras balbuceaba como un tonto, tecleaba a toda máquina intentando averiguar más detalles sobre la tabla hash y le contaba lo que descubría al tiempo que lo leía:
- Es... es... una estructura de datos... muy eficiente... tiene tiempo de búsqueda de orden constante... también tiene un tiempo de inserción de orden constante...
Efectivamente, una tabla hash es una estructura de datos, es decir, una manera de almacenar datos (números, letras, apellidos, bits a pelo, etc.) que se ajusta a unos modelos específicos. Tiene una cota superior asintótica de orden constante para las operaciones de inserción y búsqueda, que normalmente se escribe como O(1) y en cristiano significa que cuando añades (insertas) datos a tu estructura, o lees (buscas) datos desde tu estructura, el tiempo que tarde la operación es teóricamente independiente del número de elementos existentes en la estructura. Si quieres aprender más detalles sobre las tablas hash, recomiendo el vídeo protagonizado por un profesor de la Universidad Politécnica de Valencia disponible aquí, si no te apetece leer la amenazante entrada en la wikipedia.
Gracias a mi interés por la criptografía, el concepto de una función hash me era bastante familiar. Eso, unido a la poca pero suficiente información que fui capaz de encontrar en unos segundos, me permitió hacer una educada suposición de cómo funciona una tabla hash. Además, tuve una suerte del copón porque fui capaz de inventarme una función hash basada en el algoritmo de Luhn y un método para evitar la colisión de hash al vuelo, algo que no creo que sea capaz de repetir. Al final, gracias a tal alineación de los planetas, fui capaz de sacarme de la manga una implementación más o menos sólida que satisfizo a mi entrevistador, el cual me dijo al terminar la entrevista que me contactarían los de recursos humanos en 6 ó 7 días.
No habían pasado ni 4 días, y me llegó un correo electrónico de Amazon pidiéndome fijar fecha y hora para una segunda entrevista telefónica. Esta vez, sabiendo lo lentos que fueron en darme cita para la primera entrevista, les dije que cualquier día a cualquier hora me valdría, puesto que tenía planeado un viaje con motivo de las vacaciones de Navidad próximamente. Sin embargo, mi completa disponibilidad no sirvió de mucho porque no me dieron cita hasta 2 semanas más tarde, apenas unos días antes de comenzar mis vacaciones. Mi intención era lograr una entrevista in situ antes de irme pero eso, por desgracia, no iba a ocurrir.
La segunda entrevista fue prácticamente calcada a la anterior pero con un interlocutor distinto, aunque ambos trabajaban en el mismo equipo dedicado al desarrollo de software especializado en almacenes. Me sorprendió la cantidad de preguntas que fueron idénticas teniendo en cuenta que, de acuerdo con mi segundo entrevistador, él se sentaba "a dos mesas de distancia" del primero. ¡Es como si no se hubieran hablado entre ellos para nada! Desgraciadamente, especialmente en las empresas grandes, cada entrevistador tiene sus métodos y preguntas favoritas, y a veces difieren tantos los unos de los otros que no se fían ni un pelo de las conclusiones de otros entrevistadores por lo que las entrevistas son, a efectos prácticos, completamente independientes. Esta vez la pregunta difícil fue, en realidad, mucho más sencilla que en la anterior entrevista: mi entrevistador me pidió escribir un método que comprobase si 2 palabras (interpretadas como secuencias de caracteres) eran palíndromos. Ya me habían hecho la misma pregunta en una anterior entrevista telefónica con Zappos y, como no tuve ninguna dificultad en responderla, me pidió entrar en más detalles sobre eficiencia y optimización (lo cual tampoco resultó ser excesivamente complejo).
Para mi sorpresa, al final de la entrevista, mi interlocutor me dijo que me contactarían los de recursos humanos para fijar una fecha para una entrevista in situ. Por lo que había leído sobre otros entrevistados, generalmente Amazon no suele ofrecer una entrevista in situ hasta después de 3 ó 4 entrevistas telefónicas (salvo que seas nativo de Seattle, que es donde están sus oficinas), ¡eso era buena señal! Desafortunadamente, no podría concertar tal entrevista hasta después de las Navidades, pero de eso hablaré en una próxima entrada.
Había conseguido que me llamasen de Amazon para una entrevista telefónica, y fui capaz de responder las preguntas que me hicieron en la primera parte de la entrevista razonablemente bien pero, sin venir a cuento ni nada, el entrevistador me pidió que implementara una tabla hash en un área de texto que él podía ver mientras yo escribía de manera sincronizada. Cuando me preguntó si sabía lo que era una tabla hash, yo mentí como un bellaco y le dije que sí porque el concepto me sonaba bastante y no me imaginaba que me fuese a preguntar algo tan complicado. Mientras balbuceaba como un tonto, tecleaba a toda máquina intentando averiguar más detalles sobre la tabla hash y le contaba lo que descubría al tiempo que lo leía:
- Es... es... una estructura de datos... muy eficiente... tiene tiempo de búsqueda de orden constante... también tiene un tiempo de inserción de orden constante...
Si mi teclado tuviera un botón de pánico, lo habría pulsado con toda seguridad. Licencia CC Wikimedia Commons
Efectivamente, una tabla hash es una estructura de datos, es decir, una manera de almacenar datos (números, letras, apellidos, bits a pelo, etc.) que se ajusta a unos modelos específicos. Tiene una cota superior asintótica de orden constante para las operaciones de inserción y búsqueda, que normalmente se escribe como O(1) y en cristiano significa que cuando añades (insertas) datos a tu estructura, o lees (buscas) datos desde tu estructura, el tiempo que tarde la operación es teóricamente independiente del número de elementos existentes en la estructura. Si quieres aprender más detalles sobre las tablas hash, recomiendo el vídeo protagonizado por un profesor de la Universidad Politécnica de Valencia disponible aquí, si no te apetece leer la amenazante entrada en la wikipedia.
Gracias a mi interés por la criptografía, el concepto de una función hash me era bastante familiar. Eso, unido a la poca pero suficiente información que fui capaz de encontrar en unos segundos, me permitió hacer una educada suposición de cómo funciona una tabla hash. Además, tuve una suerte del copón porque fui capaz de inventarme una función hash basada en el algoritmo de Luhn y un método para evitar la colisión de hash al vuelo, algo que no creo que sea capaz de repetir. Al final, gracias a tal alineación de los planetas, fui capaz de sacarme de la manga una implementación más o menos sólida que satisfizo a mi entrevistador, el cual me dijo al terminar la entrevista que me contactarían los de recursos humanos en 6 ó 7 días.
No habían pasado ni 4 días, y me llegó un correo electrónico de Amazon pidiéndome fijar fecha y hora para una segunda entrevista telefónica. Esta vez, sabiendo lo lentos que fueron en darme cita para la primera entrevista, les dije que cualquier día a cualquier hora me valdría, puesto que tenía planeado un viaje con motivo de las vacaciones de Navidad próximamente. Sin embargo, mi completa disponibilidad no sirvió de mucho porque no me dieron cita hasta 2 semanas más tarde, apenas unos días antes de comenzar mis vacaciones. Mi intención era lograr una entrevista in situ antes de irme pero eso, por desgracia, no iba a ocurrir.
A partir de la tercera entrevista telefónica, todas parecen iguales. Licencia CC Wikimedia Commons
La segunda entrevista fue prácticamente calcada a la anterior pero con un interlocutor distinto, aunque ambos trabajaban en el mismo equipo dedicado al desarrollo de software especializado en almacenes. Me sorprendió la cantidad de preguntas que fueron idénticas teniendo en cuenta que, de acuerdo con mi segundo entrevistador, él se sentaba "a dos mesas de distancia" del primero. ¡Es como si no se hubieran hablado entre ellos para nada! Desgraciadamente, especialmente en las empresas grandes, cada entrevistador tiene sus métodos y preguntas favoritas, y a veces difieren tantos los unos de los otros que no se fían ni un pelo de las conclusiones de otros entrevistadores por lo que las entrevistas son, a efectos prácticos, completamente independientes. Esta vez la pregunta difícil fue, en realidad, mucho más sencilla que en la anterior entrevista: mi entrevistador me pidió escribir un método que comprobase si 2 palabras (interpretadas como secuencias de caracteres) eran palíndromos. Ya me habían hecho la misma pregunta en una anterior entrevista telefónica con Zappos y, como no tuve ninguna dificultad en responderla, me pidió entrar en más detalles sobre eficiencia y optimización (lo cual tampoco resultó ser excesivamente complejo).
Para mi sorpresa, al final de la entrevista, mi interlocutor me dijo que me contactarían los de recursos humanos para fijar una fecha para una entrevista in situ. Por lo que había leído sobre otros entrevistados, generalmente Amazon no suele ofrecer una entrevista in situ hasta después de 3 ó 4 entrevistas telefónicas (salvo que seas nativo de Seattle, que es donde están sus oficinas), ¡eso era buena señal! Desafortunadamente, no podría concertar tal entrevista hasta después de las Navidades, pero de eso hablaré en una próxima entrada.
12 marzo 2013
Buscando Trabajo en EEUU: Amazon I
Ésta es la primera entrada de una nueva serie relatando mi experiencia entrevistando con Amazon, el gigante del comercio electrónico. Anteriormente he escrito sobre mi experiencia con Zappos, una ramificación semi-independiente de Amazon dedicada exclusivamente a ropa y calzado, en este blog puedes leer la primera, segunda y tercera parte de mi aventura con la empresa basada en Las Vegas.
Poco después de que me contactase Zappos para concertar una entrevista telefónica, tenía el autoestima por las nubes. Pensé que, si me llamaban desde una de las empresas mejor valoradas por los empleados en todo el mundo, ¡podrían llamarme desde cualquier otra empresa! Cabe mencionar que, con la angustiosa sensación de fracaso e insuficiencia que me viene a la mente cuando soy rechazado para lo que sea, el sólo mirar las ofertas de empleo en Amazon fue un acto de valor por mi parte. La razón por la que me decidí por mirar en Amazon fue porque un día, al entrar en su página (debo admitir que compro en Amazon muy habitualmente), me saltó una carta escrita por el CEO declarando lo mucho que miman a sus empleados y todos los beneficios y oportunidades que les dan. Si no hubiese leído con más detenimiento, habría ignorado completamente cualquier reclamo por parte de la empresa relacionado con su trato a los empleados. Pero mi falta de confianza tiene una explicación racional; hace casi año y medio (Ocubre de 2011) un ex-empleado de Amazon cometió un gazapo MONUMENTAL. Steve Yegge, ingeniero de software en Google desde 2005 hasta la fecha, hizo público un post (cuya lectura encarecidamente recomiendo) en la entonces casi nueva red social Google+ que, se supone, iba dirigido sólo a otros empleados de Google. El tema no habría llegado a más si no fuese porque el pobre Steve debía de estar escribiendo con un cuchillo entre los dientes y no dejó a títere con cabeza. Entre otras perlas, acusaba la carencia de una mente visionaria como la de Steve Jobs en Google y se refería el CEO de Amazon, Jeff Bezos, como al "temible pirata Bezos", además de no dejar ninguna duda de lo inestable y estresante que es ser empleado del gigante del comercio electrónico.
Lo que me quedó claro después de leer semejante obra de arte es que trabajar en Amazon debe ser cosa fina. Entonces, ¿por qué decidí buscar trabajo allí de todas maneras? Para empezar, es una empresa con mucho nombre. Si trabajar allí realmente es tan malo, tengo la posibilidad de ir prácticamente a cualquier otra empresa después de marcharme. De hecho, hay una grandísima cantidad de empleados que trabajan en Amazon sólo durante unos 4 ó 5 años hasta que acaban quemados de tan acelerado ritmo de trabajo y se van a trabajar a otras empresas. Otro importante punto a favor estaba en la carta que mencioné antes, que aseguraba que cualquier empleado tenía la posibilidad continuar su formación académica e incluso sacarse un máster en cualquier área, estuviese o no relacionado con su puesto de trabajo, todo pagado por la empresa. Aunque esa ya es una razón de peso por sí misma, me hizo pensar que la cultura de Amazon podría ser más beneficiosa de lo que me había parecido al principio. Armado de valor, me puse a mirar las ofertas de empleo para estudiantes y recién graduados y me llevé una muy agradable sorpresa al leer el perfil que buscaban. Resulta que una de las habilidades que valoran bastante es el conocimiento en optimización matemática, y ponen como ejemplo la programación lineal. Dije que me llevé una agradable sorpresa porque la casualidad quiso que uno de mis proyectos de fin de carrera fuese precisamente sobre programación lineal aplicada a determinados algoritmos relacionados con geometría computacional, ¡bingo! Con muchas esperanzas, rellené los formularios y les envié mi currículo.
Poco después de mi primera entrevista telefónica con Zappos, los de recursos humanos de Amazon me mandaron un correo para decirme que ellos también estaban interesados en una entrevista por teléfono. A decir verdad, mi ego había crecido demasiado pero yo estaba muy contento de tener la oportunidad de entrevistar con una empresa tal calibre. Aunque les dije que estaba completamente libre para cualquier día excepto para mi entrevista con Zappos, deben tener tal cantidad de solicitudes que me no me dieron cita hasta dos semanas más tarde (la cifra es muy posiblemente varias decenas de miles de solicitudes cada semana). Por su tamaño, en Amazon se permiten aceptar currículos para puestos sin determinar. Ellos simplemente buscan a gente que les parezca lo suficientemente buena hagan lo que hagan, y después ya les encontrarán alguna vacante dentro de la empresa. Entonces, cuando yo les envié mi currículo, ellos lo miraron y decidieron que sería un buen candidato para su equipo de desarrollo de software especializado en almacenes, aunque yo todavía no lo sabía.
El momento había llegado, y yo esperaba impaciente la llamada de Amazon... una vez más. Debo reconocer que mi estupidez fue de una magnitud considerable cuando pensé que mi entrevista era una semana antes de la verdadera fecha, pero llegó a un nivel nunca antes alcanzado cuando, una semana más tarde, estaba esperando la llamada ¡6 horas antes de lo previsto! Mi malinterpretación del funcionamiento básico de las franjas horarias fueron la causa de tal despropósito, menos mal que a la tercera va la vencida. Según descolgué el teléfono, incluso antes de presentarse, mi entrevistador se disculpó por haber llamado 1 minuto tarde (sin comentarios) y la entrevista comenzó como las demás: quién soy, qué hago, cómo funciona nuestra empresa, etc. Me explicó que su equipo estaba a cargo de desarrollar software para los dispositivos portátiles usados por los que empaquetan los productos en los almacenes. Al parecer sus almacenes son tan grandes que, en vez de andar buscando "a ciegas", meten un determinado producto en el software y el aparato les da indicaciones de la localización física del producto en el almacén. Me pareció particularmente interesante que, siendo ellos un fabricante de hardware con su familia de productos Kindle, el software era desarrollado para un modelo "anticuado" de PDA (en palabras del entrevistador) fabricado por Motorola cuyo sistema operativo era Windows CE. Pero eso no es todo, la aplicación en cuestión ni siquiera funcionaba en Windows de forma nativa, sino que era una aplicación web desarrollada específicamente para trabajar en una versión determinada de Internet Explorer.
Después de contarme semejante historia de terror, comenzaron las preguntas: quién eres, qué has hecho con la tecnología X o Y (muy habitual que te pregunten sobre cosas que tengas en tu currículo, así que nunca mientas), háblame de alguno de tus proyectos... Y entonces me hizo un par de preguntas muy básicas sobre conceptos fundamentales, por ejemplo: ¿qué es polimorfismo? Durante la entrevista yo, previsiblemente, tenía el ordenador delante mío, y me di cuenta de un nuevo correo entrante con mi entrevistador como remitente, así que me temí lo peor. Una o dos preguntas más tarde, dijo algo así como "te he enviado un link a una página para que me escribas algo de código mientras charlamos...", y fue en ese momento cuando empecé a sentir el miedo. Intenté mantener la calma pensando que no podría preguntarme nada excesivamente complejo, puesto que teníamos poco tiempo y era una entrevista telefónica (en su defensa, los de RRHH me advirtieron de que la entrevista sería de carácter técnico). Se me cayó el alma al suelo cuando abrí el link y me dijo "quiero que escribas una clase que implemente una tabla hash". ¿Una tabla hash? ¿Y eso qué es lo que es? No había hecho nada con tablas hash en toda mi carrera y ni me sonaban de mi asignatura de estructuras de datos, mucho más enfocada en árboles y grafos.
Por desgracia, esta entrada se ha alargado demasiado y tendré que escribir sobre el resto de la entrevista en la siguiente parte de esta serie.
Poco después de que me contactase Zappos para concertar una entrevista telefónica, tenía el autoestima por las nubes. Pensé que, si me llamaban desde una de las empresas mejor valoradas por los empleados en todo el mundo, ¡podrían llamarme desde cualquier otra empresa! Cabe mencionar que, con la angustiosa sensación de fracaso e insuficiencia que me viene a la mente cuando soy rechazado para lo que sea, el sólo mirar las ofertas de empleo en Amazon fue un acto de valor por mi parte. La razón por la que me decidí por mirar en Amazon fue porque un día, al entrar en su página (debo admitir que compro en Amazon muy habitualmente), me saltó una carta escrita por el CEO declarando lo mucho que miman a sus empleados y todos los beneficios y oportunidades que les dan. Si no hubiese leído con más detenimiento, habría ignorado completamente cualquier reclamo por parte de la empresa relacionado con su trato a los empleados. Pero mi falta de confianza tiene una explicación racional; hace casi año y medio (Ocubre de 2011) un ex-empleado de Amazon cometió un gazapo MONUMENTAL. Steve Yegge, ingeniero de software en Google desde 2005 hasta la fecha, hizo público un post (cuya lectura encarecidamente recomiendo) en la entonces casi nueva red social Google+ que, se supone, iba dirigido sólo a otros empleados de Google. El tema no habría llegado a más si no fuese porque el pobre Steve debía de estar escribiendo con un cuchillo entre los dientes y no dejó a títere con cabeza. Entre otras perlas, acusaba la carencia de una mente visionaria como la de Steve Jobs en Google y se refería el CEO de Amazon, Jeff Bezos, como al "temible pirata Bezos", además de no dejar ninguna duda de lo inestable y estresante que es ser empleado del gigante del comercio electrónico.
Steve Yegge escribiendo sobre Amazon. También es aplicable al comentarista medio de Menéame.
Lo que me quedó claro después de leer semejante obra de arte es que trabajar en Amazon debe ser cosa fina. Entonces, ¿por qué decidí buscar trabajo allí de todas maneras? Para empezar, es una empresa con mucho nombre. Si trabajar allí realmente es tan malo, tengo la posibilidad de ir prácticamente a cualquier otra empresa después de marcharme. De hecho, hay una grandísima cantidad de empleados que trabajan en Amazon sólo durante unos 4 ó 5 años hasta que acaban quemados de tan acelerado ritmo de trabajo y se van a trabajar a otras empresas. Otro importante punto a favor estaba en la carta que mencioné antes, que aseguraba que cualquier empleado tenía la posibilidad continuar su formación académica e incluso sacarse un máster en cualquier área, estuviese o no relacionado con su puesto de trabajo, todo pagado por la empresa. Aunque esa ya es una razón de peso por sí misma, me hizo pensar que la cultura de Amazon podría ser más beneficiosa de lo que me había parecido al principio. Armado de valor, me puse a mirar las ofertas de empleo para estudiantes y recién graduados y me llevé una muy agradable sorpresa al leer el perfil que buscaban. Resulta que una de las habilidades que valoran bastante es el conocimiento en optimización matemática, y ponen como ejemplo la programación lineal. Dije que me llevé una agradable sorpresa porque la casualidad quiso que uno de mis proyectos de fin de carrera fuese precisamente sobre programación lineal aplicada a determinados algoritmos relacionados con geometría computacional, ¡bingo! Con muchas esperanzas, rellené los formularios y les envié mi currículo.
Poco después de mi primera entrevista telefónica con Zappos, los de recursos humanos de Amazon me mandaron un correo para decirme que ellos también estaban interesados en una entrevista por teléfono. A decir verdad, mi ego había crecido demasiado pero yo estaba muy contento de tener la oportunidad de entrevistar con una empresa tal calibre. Aunque les dije que estaba completamente libre para cualquier día excepto para mi entrevista con Zappos, deben tener tal cantidad de solicitudes que me no me dieron cita hasta dos semanas más tarde (la cifra es muy posiblemente varias decenas de miles de solicitudes cada semana). Por su tamaño, en Amazon se permiten aceptar currículos para puestos sin determinar. Ellos simplemente buscan a gente que les parezca lo suficientemente buena hagan lo que hagan, y después ya les encontrarán alguna vacante dentro de la empresa. Entonces, cuando yo les envié mi currículo, ellos lo miraron y decidieron que sería un buen candidato para su equipo de desarrollo de software especializado en almacenes, aunque yo todavía no lo sabía.
Son muchos los que recomiendan vestirs ropa formal. Licencia CC Wikimedia Commons
El momento había llegado, y yo esperaba impaciente la llamada de Amazon... una vez más. Debo reconocer que mi estupidez fue de una magnitud considerable cuando pensé que mi entrevista era una semana antes de la verdadera fecha, pero llegó a un nivel nunca antes alcanzado cuando, una semana más tarde, estaba esperando la llamada ¡6 horas antes de lo previsto! Mi malinterpretación del funcionamiento básico de las franjas horarias fueron la causa de tal despropósito, menos mal que a la tercera va la vencida. Según descolgué el teléfono, incluso antes de presentarse, mi entrevistador se disculpó por haber llamado 1 minuto tarde (sin comentarios) y la entrevista comenzó como las demás: quién soy, qué hago, cómo funciona nuestra empresa, etc. Me explicó que su equipo estaba a cargo de desarrollar software para los dispositivos portátiles usados por los que empaquetan los productos en los almacenes. Al parecer sus almacenes son tan grandes que, en vez de andar buscando "a ciegas", meten un determinado producto en el software y el aparato les da indicaciones de la localización física del producto en el almacén. Me pareció particularmente interesante que, siendo ellos un fabricante de hardware con su familia de productos Kindle, el software era desarrollado para un modelo "anticuado" de PDA (en palabras del entrevistador) fabricado por Motorola cuyo sistema operativo era Windows CE. Pero eso no es todo, la aplicación en cuestión ni siquiera funcionaba en Windows de forma nativa, sino que era una aplicación web desarrollada específicamente para trabajar en una versión determinada de Internet Explorer.
Después de contarme semejante historia de terror, comenzaron las preguntas: quién eres, qué has hecho con la tecnología X o Y (muy habitual que te pregunten sobre cosas que tengas en tu currículo, así que nunca mientas), háblame de alguno de tus proyectos... Y entonces me hizo un par de preguntas muy básicas sobre conceptos fundamentales, por ejemplo: ¿qué es polimorfismo? Durante la entrevista yo, previsiblemente, tenía el ordenador delante mío, y me di cuenta de un nuevo correo entrante con mi entrevistador como remitente, así que me temí lo peor. Una o dos preguntas más tarde, dijo algo así como "te he enviado un link a una página para que me escribas algo de código mientras charlamos...", y fue en ese momento cuando empecé a sentir el miedo. Intenté mantener la calma pensando que no podría preguntarme nada excesivamente complejo, puesto que teníamos poco tiempo y era una entrevista telefónica (en su defensa, los de RRHH me advirtieron de que la entrevista sería de carácter técnico). Se me cayó el alma al suelo cuando abrí el link y me dijo "quiero que escribas una clase que implemente una tabla hash". ¿Una tabla hash? ¿Y eso qué es lo que es? No había hecho nada con tablas hash en toda mi carrera y ni me sonaban de mi asignatura de estructuras de datos, mucho más enfocada en árboles y grafos.
Por desgracia, esta entrada se ha alargado demasiado y tendré que escribir sobre el resto de la entrevista en la siguiente parte de esta serie.
Suscribirse a:
Entradas (Atom)