El título del artículo suena como un epic fail, pero en realidad las cosas no son tan sencillas. Y en general, esta historia terminó de manera bastante positiva, aunque no en Google. Pero ese es un tema para otro artículo. En este artículo, hablaré sobre tres cosas: cómo fue mi proceso de preparación, cómo fueron las entrevistas en Google y por qué, en mi opinión, todo no es tan sencillo como puede parecer.
Cómo todo comenzó
Una fría noche de invierno en Chipre, de repente me vino a la mente que mis conocimientos en Computer Science estaban bastante lejos de ser promedio y que tenía que hacer algo al respecto. Si acaso alguien no ha leído por qué la noche es chipriota y fría, se puede enterar de eso . Después de reflexionar un poco, decidí empezar con un curso en línea sobre algoritmos y estructuras de datos. De un colega anterior había escuchado sobre el curso de Robert Sedgewick en Coursera. El curso consta de dos partes ( y ). Si acaso los enlaces cambian, siempre se puede buscar por el nombre del autor. Cada parte dura 6 semanas. Al inicio de la semana se publican las conferencias, y durante la semana también hay que hacer ejercicios. La primera parte del curso cubre las estructuras de datos básicas, los tipos de ordenamientos y la complejidad de los algoritmos. La segunda parte es más avanzada, comienza con grafos y termina con temas como Programación Lineal e Intráctibilidad. Tras pensar en todo lo anterior, llegué a la conclusión de que eso era exactamente lo que necesitaba. Aquí, por cierto, un lector curioso puede preguntarse, ¿qué tiene que ver Google en esto? Y, de hecho, hasta ese momento no tenía nada que ver. Pero necesitaba un objetivo, ya que estudiar 12 semanas por las noches sin un objetivo es un poco complicado. ¿Y cuál puede ser el objetivo al adquirir nuevos conocimientos? Por supuesto, su aplicación práctica. En la vida cotidiana eso es bastante problemático, pero en una entrevista en una gran empresa es más fácil. Una búsqueda rápida en Google mostró que Google (perdón por la tautología) es una de las empresas más grandes en Europa (y yo estaba considerando precisamente Europa), donde se realizan tales entrevistas. Su oficina está en Zúrich, Suiza. Así que decidido: estudiamos y vamos a la entrevista en Google.
Preparación para el primer intento
Pasaron 12 semanas sin darme cuenta y terminé ambos cursos. Mis impresiones sobre los cursos son más que positivas y puedo recomendarlos a todos los interesados. Me gustaron los cursos por las siguientes razones:
- El profesor habla en un inglés bastante claro.
- El material está bien estructurado.
- Excelentes presentaciones que muestran el funcionamiento interno de cada algoritmo.
- Selección adecuada del material.
- Ejercicios interesantes.
- Los ejercicios se corrigen automáticamente en el sitio, tras lo cual se genera un informe.
Generalmente, mi trabajo en los cursos seguía esta secuencia: durante 1-2 días, escuchaba las conferencias. Luego, hacía una prueba rápida sobre el material. El resto de la semana trabajaba en el ejercicio en varias iteraciones. Después del primero, obtenía entre el 30% y el 70%, y las siguientes intentos llevaban el resultado al 97-100%. El ejercicio normalmente consistía en implementar algún algoritmo, por ejemplo, o .
Después de finalizar los cursos, me di cuenta de que muchos conocimientos también traen tristezas. Si antes sabía simplemente que no sabía nada, ahora comencé a entender exactamente qué es lo que no sé.
Como todavía era mayo y tenía la entrevista programada para el otoño, decidí continuar con mi educación. Después de revisar los requisitos de la vacante, tomé la decisión de seguir dos líneas en paralelo: continuar estudiando algoritmos y hacer un curso básico de aprendizaje automático. Para la primera meta, decidí cambiar de los cursos a un libro y elegí la monumental obra de Steven Skiena "Algoritmos. Guía de diseño". No es tan monumental como la de Knuth, pero aún así. Para la segunda meta, nuevamente fui a Coursera y me inscribí en el curso de Andrew Ng. .
Pasaron otros 3 meses y terminé el curso y el libro.
Empecemos con el libro. La lectura resultó ser bastante interesante, aunque no fácil. En principio, lo recomendaría, pero no tan pronto. En general, el libro proporciona un análisis más profundo de lo que aprendí en los cursos. Además, descubrí (desde un punto de vista formal) cosas como heurísticas y programación dinámica. Evidentemente, antes había utilizado estas cosas, pero no sabía cómo se llamaban. También hay algunas anécdotas de la vida del autor (War Story) que alivian un poco la academicidad del texto. Por cierto, se puede omitir la segunda mitad del libro, que más bien describe problemas existentes y métodos para resolverlos. Es útil si se aplica regularmente en la práctica, de lo contrario se olvidará inmediatamente.
El curso me alegró mucho. El autor claramente sabe lo que hace y cuenta las cosas de manera interesante. Además, recordaba una parte considerable, a saber, álgebra lineal y fundamentos de redes neuronales de la universidad, por lo que no experimenté dificultades especiales. La estructura del curso es bastante estándar. Se divide en semanas. Cada semana, primero hay conferencias mezcladas con breves pruebas. Después de las conferencias, se entrega una tarea que hay que hacer, enviar y que se revisa automáticamente. En resumen, los temas impartidos en el curso son los siguientes:
— función de costo
— regresión lineal
— descenso de gradiente
— escalado de características
— ecuación normal
— regresión logística
— clasificación multiclase (uno contra todos)
— redes neuronales
— retropropagación
— regularización
— sesgo/varianza
— curvas de aprendizaje
— métricas de error (precisión, recuperación, F1)
— Máquinas de Vectores de Soporte (clasificación de margen amplio)
— K-means
— Análisis de Componentes Principales
— detección de anomalías
— filtrado colaborativo (sistema de recomendación)
— descensos de gradiente estocástico, por mini-lotes, por lotes
— aprendizaje en línea
— mapa reducir
— análisis de techo
Después de completar el curso, la comprensión de todos estos temas estaba presente. Después de 2 años, ya casi todo se ha olvidado naturalmente. Lo recomiendo a aquellos que no están familiarizados con el aprendizaje automático y quieren obtener una buena comprensión de las cuestiones básicas para avanzar.
Primera vez
Ya era septiembre y llegó el momento de pensar en la entrevista. Dado que postularse a través del sitio es una tarea bastante difícil, me dediqué a buscar conocidos que trabajen en Google. La elección recayó en , ya que era el único a quien conocía directamente (aunque no personalmente). Aceptó enviar mi currículum, y pronto recibí un correo del reclutador ofreciéndome reservar un espacio en su calendario para una primera conversación. Un par de días después, tuvimos la llamada. Intentamos comunicarnos a través de Hangouts, pero la calidad era horrible, así que cambiamos a teléfono. Primero discutimos rápidamente los motivos, el porqué y para qué, y luego pasamos a la evaluación técnica. Consistió en una docena de preguntas como '¿qué tan complicado es insertar en un hash map?', '¿qué árboles balanceados conoces?'. No es difícil si se tiene un conocimiento básico de estas cosas. La evaluación fue bien y, según los resultados, decidimos organizar la primera entrevista para dentro de una semana.
La entrevista también fue a través de Hangouts. Primero hablamos durante unos 5 minutos sobre mí, luego pasamos al ejercicio. La tarea era sobre grafos. Comprendí rápidamente qué había que hacer, pero elegí el algoritmo incorrecto. Cuando comencé a escribir el código, me di cuenta de esto y cambié a otra opción, que fue la que completé. El entrevistador hizo algunas preguntas sobre la complejidad del algoritmo, preguntó si había una forma más rápida. Me quedé un poco aturdido y no pude responder. En ese momento, se acabó el tiempo y nos despedimos. Luego, unos 10 minutos después, me di cuenta de que en lugar del algoritmo de Dijkstra que utilicé, en este caso se podría haber utilizado una búsqueda en amplitud, lo cual habría sido más rápido. Después de un tiempo, el reclutador me llamó y dijo que, en general, la entrevista había ido bien y que deberíamos organizar otra. Acordamos hacerlo para dentro de una semana.
Esta vez las cosas salieron peor. Si la primera vez el entrevistador fue amigable y comunicativo, esta vez estaba algo sombrío. No pude entender la tarea de inmediato, aunque las ideas que tenía podrían haber llevado a una solución. Después de algunas pistas del entrevistador, finalmente comprendí la solución. Esta vez fue nuevamente una búsqueda en amplitud, pero desde varios puntos. Escribí las soluciones, cumplí con el tiempo, pero olvidé considerar los casos límite. Después de un tiempo, el reclutador me llamó y me informó que esta vez el entrevistador no estaba satisfecho, ya que, en su opinión, necesité demasiadas pistas (3 o 4) y cambiaba el código constantemente mientras lo escribía. Después de las dos entrevistas, se tomó la decisión de no continuar y posponer la siguiente entrevista por un año, si así lo deseaba. Así fue como nos despedimos.
Y de esta historia saqué varias conclusiones:
- La teoría está bien, pero hay que orientarse rápidamente en ella.
- La teoría sin práctica no ayuda. Hay que resolver problemas y automatizar la escritura de código.
- Mucho depende del entrevistador. Y con esto no se puede hacer nada.
Preparación para la segunda oportunidad
Después de pensar en la situación, decidí intentar nuevamente al cabo de un año. Y ajusté ligeramente el objetivo. Si antes el objetivo principal era aprender, y las entrevistas en Google eran una zanahoria lejana, ahora pasar la entrevista se convirtió en el objetivo, y el aprendizaje en el medio.
Así que se desarrolló un nuevo plan que incluía los siguientes puntos:
- Seguir estudiando teoría a través de la lectura de libros y artículos.
- Resolver problemas algorítmicos en una cantidad de 500-1000.
- Seguir estudiando teoría a través de videos.
- Seguir estudiando teoría a través de cursos.
- Investigar la experiencia de otras personas al pasar entrevistas en Google.
El plan lo cumplí en un año. A continuación, describiré lo que hice en cada uno de los puntos.
Libros y artículos
No recuerdo cuántos artículos leí, los leí tanto en ruso como en inglés. El sitio más útil resultó ser probablemente . Aquí se recopilaron descripciones de una gran cantidad de algoritmos interesantes con ejemplos de código.
He leído 5 libros: Algorithms, 4th edition (Sedgewick, Wayne), Introduction to Algorithms 3rd Edition (Cormen, Leiserson, Rivest, Stein), Cracking the Coding Interview 4th edition (Gayle Laakmann), Programming Interviews Exposed 2nd edition (Mongan, Suojanen, Giguere), Elements of Programming Interviews (Aziz, Lee, Prakash). Se pueden dividir en 2 categorías. En la primera entran los libros de Sedgewick y Cormen. Esto es teoría. Los otros son preparación para entrevistas. En el libro, Sedgewick cuenta más o menos lo mismo que en sus cursos. Simplemente de forma escrita. No tiene mucho sentido leerlo detenidamente si has hecho el curso, pero vale la pena revisarlo de todos modos. Si no has seguido el curso, sí tiene sentido leerlo. Cormen me pareció un poco aburrido. La verdad es que lo terminé con dificultad. Solo saqué de ahí , y algunas estructuras de datos poco comunes (Fibonacci heap, árbol de van Emde Boas, radix heap).
Deberías leer al menos un libro para prepararte para la entrevista. Todos están construidos aproximadamente sobre el mismo principio. Describen el proceso de entrevistas en grandes empresas tecnológicas, ofrecen conceptos básicos de Ciencias de la Computación, problemas sobre estos conceptos básicos, soluciones a los problemas y un análisis de las soluciones. De los tres mencionados, probablemente recomendaría Cracking the Coding Interview como el principal, y los otros de forma opcional.
Problemas algorítmicos
Este probablemente fue el punto más interesante de la preparación. Claro, puedes sentarte y resolver problemas sin más. Para esto hay muchos sitios diferentes. Yo principalmente usé tres: , y . En CodeChef, los problemas están organizados por dificultad, pero no por temas. En Hackerrank, por dificultad y por temas.
Pero como descubrí de inmediato, hay una forma más interesante. Y son las competiciones (desafíos de programación o concursos de programación). Los tres sitios los ofrecen. Sin embargo, con LeetCode hay un problema: la zona horaria es incómoda. Por eso no participé en ese sitio. Hackerrank y CodeChef ofrecen una cantidad considerable de varias competiciones, con duraciones que van de 1 hora a 10 días. Diferentes formatos tienen diferentes reglas, pero se puede hablar mucho de eso. La esencia principal de por qué las competiciones son buenas es la introducción de un elemento competitivo (y de nuevo, una tautología) en el proceso de aprendizaje.
En total, participé en 37 competiciones en Hackerrank. De ellas, 32 fueron clasificatorias y 5 fueron patrocinadas (incluso gané 25$ en una de ellas) o por diversión. En las competiciones clasificatorias, estuve en el top 4% diez veces, en el top 12% once veces y en el top 25% cinco veces. Mis mejores resultados fueron 27/1459 en una competición de 3 horas y 22/9721 en la semanal.
Me cambié a CodeChef cuando las competiciones en Hackerrank empezaron a realizarse con menos frecuencia. En total, participé en 5 competiciones. El mejor resultado fue 426/5019 en una competición de diez días.
En total, resolví un poco más de 1000 problemas en competiciones y solo por diversión, lo cual encajaba en mi plan. Lamentablemente, actualmente no tengo tiempo libre para seguir con la actividad competitiva, ni tampoco tengo un objetivo para el tiempo no libre. Pero fue divertido. Recomiendo a quienes estén interesados que busquen compañeros. Es mucho más interesante en pareja o en grupo. Yo disfruté de esto con un amigo, por lo que tal vez por eso me fue tan bien.
Ver videos
Después de leer el libro de Skiena, me interesé en lo que él hace. Al igual que Sedgwick, es profesor en una universidad. Por lo tanto, se pueden encontrar grabaciones de sus cursos en la red. Decidí ver el curso . No diré que me gustó mucho. Primero, la calidad del video no es muy buena. En segundo lugar, no intenté resolver yo mismo los problemas que se presentan en el curso. Así que la participación no fue muy alta.
También, durante el proceso de resolver problemas, tratando de encontrar el algoritmo correcto, me topé con videos de Tushar Roy. Trabajó en Amazon y ahora trabaja en Apple. Como descubrí más tarde, tiene un , donde sube explicaciones de varios algoritmos. En el momento de escribir este artículo, el canal tiene 103 videos. Y debo decir que las explicaciones en su estilo son muy decentes. Traté de ver a otros autores, pero no me convencieron. Así que definitivamente puedo recomendar este canal para verlo.
Tomando cursos
Aquí no hice mucho. Vi videos del Android Developer Nanodegree de Google y completé un curso de ITMO . El Nanodegree está bien, aunque naturalmente no aprendí nada nuevo de allí. El curso de ITMO tiene un poco de teoría desorganizada, pero los problemas eran interesantes. No lo recomendaría como punto de partida, pero en general, el tiempo invertido no fue en vano.
Explorar la experiencia de otras personas
Por supuesto, muchas personas han intentado entrar en Google. Algunos lo lograron, otros no. Algunos escribieron artículos sobre esto. Entre las cosas interesantes, probablemente señalaría y . En el primer caso, la persona preparó una lista de lo que necesitaba aprender para convertirse en Software Engineer y entrar en Google. Al final, consiguió trabajo en Amazon, pero eso ya no es tan importante. El segundo manual fue escrito por una ingeniera de Google, Larisa Agarokova (). Además de este documento, también se puede leer .
Vale la pena leer las reseñas sobre las entrevistas en Glassdoor. Son más o menos similares, pero se puede extraer información útil.
No haré referencia a otros artículos pequeños, ustedes mismos los encontrarán perfectamente en Google.
Segunda ronda
Y así pasó un año. Fue un año bastante intenso en términos de estudio. Pero llegué a este nuevo otoño con conocimientos teóricos mucho más profundos y habilidades prácticas desarrolladas. Con unas semanas restantes hasta el final del año que me habían asignado para prepararme, de repente recibí un correo electrónico de un reclutador de Google, en el que me preguntaba si aún quería trabajar en Google y si no me importaría hablar con él. Por supuesto, no me importaba. Acordamos hacer una llamada una semana después. También me pidieron un currículum actualizado, al que añadí una breve descripción de lo que había hecho durante el año en el trabajo, en general.
Después de hablar sobre la vida, decidimos que en una semana tendríamos una entrevista por Hangouts, como el año pasado. Pasó la semana, llegó el momento de la entrevista, pero el entrevistador no apareció. Pasaron 10 minutos, ya comenzaba a ponerme nervioso, cuando de repente alguien irrumpió en el chat. Como se supo un poco más tarde, mi entrevistador, por alguna razón, no pudo aparecer y le encontraron un sustituto de inmediato. La persona no estaba preparada ni en términos de configurar la computadora, ni en términos de realizar la entrevista. Pero luego todo fue bien. Resolví el problema rápidamente, describí dónde podrían estar los engaños y cómo se podrían eludir. Hablamos de varias opciones para el problema, la complejidad del algoritmo. Luego tuvimos otros 5 minutos de charla, el ingeniero compartió sus impresiones sobre trabajar en Múnich (en Zúrich, parece que no encontraron un sustituto urgente), y así nos despedimos.
El mismo día, un reclutador se puso en contacto conmigo y me informó que la entrevista había ido muy bien y que estaban listos para invitarme a una entrevista en la oficina. Al día siguiente, tuvimos una llamada a través de Hangouts y discutimos los detalles. Como necesitaba tramitar un visado, decidimos programar la entrevista para dentro de un mes.
Mientras preparaba los documentos, también discutía con el reclutador la próxima entrevista. La entrevista estándar en Google consiste en 4 preguntas de algoritmos y una de Diseño de Sistemas. Pero, como me postulaba como desarrollador de Android, me dijeron que una parte de la entrevista estaría enfocada en Android. No logré sacar de mi reclutador qué preguntas exactas y en qué consistiría la especificidad. Según entendí, esto se introdujo relativamente hace poco, y él mismo no estaba muy al tanto. También me inscribieron en dos sesiones de entrenamiento: cómo enfrentar una entrevista de algoritmos y cómo abordar una entrevista de Diseño de Sistemas. Las sesiones fueron de utilidad media. Allí tampoco nadie pudo decirme qué preguntas hacen a los desarrolladores de Android. Por lo tanto, mi preparación durante este mes se redujo a lo siguiente:
- Comprar una pizarra blanca y escribir de memoria 2-3 docenas de los algoritmos más populares en ella. De 3 a 5 cada día. En total, cada uno fue escrito varias veces.
- Refrescar varios conocimientos sobre Android que no uso todos los días.
- Ver varios videos sobre Big Scale y cosas por el estilo.
Como ya mencioné, paralelamente estaba preparando los documentos para el viaje. Primero me pidieron datos para hacer una carta de invitación. Luego estuve mucho tiempo tratando de averiguar quién en Chipre gestiona las visas para Suiza, ya que la embajada suiza no se encarga de eso. Resultó que esto lo maneja el consulado de Austria. Llamé y concerté una cita. Allí me solicitaron un montón de documentos, pero nada especialmente interesante. Foto, pasaporte, permiso de residencia, varios certificados y, por supuesto, la carta de invitación. Mientras tanto, la carta no llegaba. Al final, fui con una impresión simple y eso funcionó bastante bien. La carta llegó tres días después, y el FedEx chipriota no pudo encontrar mi dirección, así que tuve que ir por ella. Aproveché para recoger un paquete que también tenían en FedEx, ya que no pudieron entregármelo porque no encontraron mi dirección, y estaba allí desde junio (5 meses, ¡Carl!). Dado que no sabía de este paquete, no podía suponer que lo tenían. Recibí la visa a tiempo, después de lo cual me reservaron un hotel y me ofrecieron opciones de vuelo. Ajusté las opciones para que fueran más cómodas. Ya no había vuelos directos, así que finalmente volé allí a través de Atenas y regresé a través de Viena.
Después de que se resolvieron todas las formalidades para el viaje, pasaron unos días y finalmente volé a Zúrich. Llegué sin contratiempos. Desde el aeropuerto hasta la ciudad tomé el tren, que es rápido y conveniente. Tras dar algunas vueltas por la ciudad, encontré el hotel y me registré. Dado que el hotel estaba reservado sin comidas, cené en un lugar cercano y me fui a dormir, ya que el vuelo era por la mañana y ya tenía sueño. Al día siguiente desayuné en el hotel (por un costo adicional) y me dirigí a la oficina de Google. En total, en Zúrich Google tiene varias oficinas. Mi entrevista no era en la central. En general, la oficina se veía bastante normal, así que no tuve la oportunidad de ver todas las ventajas de una
Entrevista número uno
La primera entrevista fue sobre Android. No tenía relación alguna con algoritmos. Una sorpresa, sin embargo. Bueno, está bien, ya estaba acostumbrado. Me pidieron que hiciera un componente UI en particular. Primero discutimos qué y cómo. Propuse hacer la solución en RxJava, describí qué haría y por qué. Dijeron que eso era muy bueno, pero que lo hiciéramos utilizando las herramientas del marco de trabajo de Android. Y además, que escribiéramos el código en la pizarra. No solo el componente, sino toda la Activity que utilizara ese componente. Eso no me lo esperaba. Una cosa es escribir un algoritmo de 30-50 líneas en la pizarra y otra cosa es lidiar con el código de Android, aunque sea con atajos y comentarios en el sentido de "bueno, esto no lo escribiré, ya que es evidente". Terminé con una especie de ensalada en 3 pizarras. Es decir, el problema lo resolví, pero se veía raro.
Entrevista número dos
Esta vez la entrevista fue sobre algoritmos. Y había dos entrevistadores. Uno era el entrevistador y el otro un joven padawan (shadow interviewer). Tenía que idear una estructura de datos con ciertas propiedades. Primero, como de costumbre, discutimos el problema. Hacía diferentes preguntas y el entrevistador respondía. Después de un tiempo, me pidieron que escribiera varios métodos de la estructura inventada en la pizarra. Esta vez lo logré más o menos, aunque con algunos pequeños errores que corregí con la ayuda del entrevistador.
Entrevista número tres
Esta vez fue un diseño de sistema que resultó ser también sobre Android. Tenía que desarrollar una aplicación con ciertas funcionalidades. Discutimos los requisitos de la aplicación, del servidor, del protocolo de comunicación. Luego comencé a describir qué componentes o bibliotecas usaría para construir la aplicación. Y al mencionar Job Scheduler, hubo un pequeño bloqueo. La cuestión es que nunca lo había utilizado en la práctica, ya que en el momento de su lanzamiento, justo me había cambiado a soportar aplicaciones donde no había tarea para su uso. Al desarrollar aplicaciones posteriores, fue lo mismo. Es decir, en teoría sé qué es, cuándo y cómo se utiliza, pero no tengo experiencia en su aplicación. Y parece que al entrevistador no le agradó mucho esto. Luego me pidieron que escribiera código. Sí, al desarrollar la aplicación, hay que escribir código de inmediato. Nuevamente, el código de Android en la pizarra. En esta ocasión, también me salió bastante mal.
Almuerzo
Debía haber venido otra persona, pero no lo hizo. También Google comete errores. Al final, fui a almorzar con la entrevistadora anterior, su colega, y un poco después se unió el siguiente entrevistador. El almuerzo fue bastante decente. De nuevo, dado que no era la oficina principal en Zúrich, la cafetería se veía bastante común, aunque muy agradable.
Entrevista número cuatro
Finalmente, algoritmos en estado puro. La primera tarea la resolví bastante rápido y de forma efectiva, aunque fallé en un caso límite, pero con la pista del entrevistador (él dio precisamente ese caso límite) encontré el problema y lo corregí. Por supuesto, tuve que escribir el código en una pizarra. Luego me dieron una tarea similar, pero más complicada. Para esta encontré un par de soluciones no óptimas y casi llegué a la óptima, me faltaron 5-10 minutos para terminar de pensar. Y no tuve tiempo para escribir el código para esta.
Entrevista número cinco
Y de nuevo entrevista de Android. Me pregunto, ¿para qué he estudiado algoritmos todo el año?
Primero hubo algunas preguntas simples. Luego el entrevistador escribió un código en la pizarra y me pidió que encontrara problemas en él. Lo encontré, lo expliqué y lo corregí. Hablamos sobre ello. Después empezaron algunas preguntas inesperadas como "¿qué hace el método Y en la clase X?", "¿qué hay dentro del método Y?", "¿qué hace la clase Z?". Respondí a algo, pero luego comenté que en mi trabajo reciente no me había encontrado con esto y, por supuesto, no recordaba quién, qué y cómo lo hace en detalle. Después de eso, el entrevistador preguntó qué estoy haciendo ahora. Y las preguntas comenzaron a girar en torno a este tema. Aquí ya respondí mucho mejor.
Después de terminar la última entrevista, me retiraron el pase, me desearon buena suerte y me enviaron a casa. Di un pequeño paseo por la ciudad, cené y fui al hotel, donde me fui a dormir, ya que el vuelo nuevamente era temprano por la mañana. Al día siguiente llegué a Chipre sin problemas. A petición del reclutador, escribí comentarios sobre la entrevista y llené un formulario en un servicio especial para el reembolso de los gastos. De todos los gastos, Google solo paga directamente los billetes. El hotel, la comida y el transporte son pagados por el candidato. Luego, llenamos el formulario, adjuntamos los recibos y lo enviamos a una oficina especial. Ellos lo procesan y transfieren el dinero a la cuenta bastante rápido.
Tomó una semana y media procesar los resultados de la entrevista. Después de eso, me informaron que estaba "un poco por debajo del estándar". Es decir, no alcancé del todo. Para ser más específico, 2 entrevistas fueron bien, 2 un poco menos, y el diseño del sistema fue muy malo. Si al menos 3 hubieran ido bien, podría haber competido, pero así no había oportunidades. Me ofrecieron intentar de nuevo en un año.
Al principio, me sentí decepcionado, ya que había invertido mucho esfuerzo en la preparación, y para el momento de la entrevista ya estaba considerando dejar Chipre. Conseguir un trabajo en Google y mudarme a Suiza parecía una excelente opción.
Conclusión
Y aquí llegamos a la parte final del artículo. Sí, no pasé la entrevista en Google dos veces. Es triste. Probablemente, habría sido interesante trabajar allí. Pero se puede ver esto desde otro ángulo.
- En un año y medio, aprendí una gran cantidad de cosas relacionadas con el desarrollo de software.
- Disfruté mucho participando en competencias de programación.
- Pasé un par de días en Zúrich. ¿Cuándo más podré ir allí?
- Obtuve una experiencia interesante en una de las mayores empresas de tecnología del mundo.
Así, todo lo que ocurrió en este año y medio se puede considerar simplemente como aprendizaje o entrenamiento. Y los resultados de este entrenamiento han dado sus frutos. Mi idea de dejar Chipre maduró (por algunas circunstancias familiares), superé con éxito varias entrevistas en otra empresa conocida y me mudé después de 8 meses. Pero esa es otra historia. Sin embargo, creo que aún debo agradecer a Google por estos año y medio que trabajé en mí mismo, así como por los 2 días interesantes en Zúrich.
Lo que puedo decir como conclusión. Si trabajas en TI, prepárate para entrevistas en Google (Amazon, Microsoft, Apple, etc.). Quizás algún día consigas entrar allí. Incluso si no lo deseas, créeme, no te hará daño prepararte. En el momento en que te des cuenta de que puedes (aunque solo sea con un poco de suerte) pasar la entrevista en una de estas empresas, se abrirán muchas más puertas que al principio de tu preparación. Y todo lo que necesitarás en el camino es un objetivo, perseverancia y tiempo. Te deseo mucho éxito 🙂
Fuente: habr.com
