No te llamaría un “perdedor”, pero parece que hiciste una cosa que a los entrevistadores no les gusta ver en entrevistas técnicas. Cuando recibes una pregunta técnica en una entrevista, esa pregunta casi siempre va a comenzar vagamente: faltarán algunas piezas importantes, de modo que en realidad NO PUEDES resolver adecuadamente el problema sin más información.
En un caso como ese, el entrevistador está siendo muy deliberado sobre la ambigüedad. Pueden estar simulando una solicitud de un cliente donde el cliente sabe lo que quiere pero no hizo un buen trabajo al comunicarlo. El punto aquí es ver cómo manejas la ambigüedad: ¿haces suposiciones? ¿Te encierras? ¿Vas por un camino hacia una solución sin entender la pregunta? ¿O intenta identificar lo que no sabe y comienza a hacer preguntas para aclarar?
Entrevisté a muchas personas que hicieron lo que usted describió: simplemente se quedaron allí mirando mi pregunta, sin hablar en absoluto, sin dejar entrar su proceso de pensamiento, etc. El problema es que podría estar pensando en el problema, pero el entrevistador no puede decir lo que está haciendo, por lo que para ellos, parece que simplemente está encerrado.
Generalmente entendemos que las personas tienen miedo escénico en algunas situaciones. La entrevista es un proceso estresante y agotador para la mayoría de las personas, por lo que no es sorprendente que tenga un caso en el que simplemente se encierra: algunas personas ni siquiera se dan cuenta de que lo están haciendo. Es por eso que un buen entrevistador tratará de incitarlo, le pedirá que describa lo que está pensando, le dará pequeños consejos, etc. QUEREMOS que tenga éxito, y nos interesa hacer lo que podamos. para ayudarte a tener éxito.
Pero solo hay mucho que podemos hacer. Si resulta obvio que estás completamente perdido en un problema, o tienes que ser manejado por todo el asunto, o simplemente no vas a “rendir” sin importar cuánta ayuda te demos, eso no es bueno. señal de cómo te irá en un entorno de trabajo real. El entorno de trabajo real, especialmente en Amazon, a menudo es más estresante y se mueve más rápido, y su éxito o fracaso en un problema real podría marcar la diferencia entre el éxito y el fracaso del producto en el que está trabajando.
Entonces, esto es lo que siempre recomiendo para entrevistar a los candidatos:
- Repasa tus habilidades para resolver problemas. Recuerde que la mayoría de las entrevistas tratan sobre qué tan bien puede comprender y resolver problemas, no solo qué tan bien se ve su código.
- Siempre, de alguna manera, repite la pregunta que te hacen. Depende de usted decidir la mejor manera de hacer esto: puede parafrasear la pregunta, puede dibujar un diagrama en la pizarra, puede describirlo en términos de comportamientos, etc. Pero deje en claro que lo hace (o no) entienda lo que el entrevistador le pide que haga.
- Si encuentra un punto donde NO PUEDE hacer eso, pídale al entrevistador que lo aclare. Por ejemplo, si le pido que divida dos números, y se da cuenta de que no he especificado lo que debería suceder cuando el segundo número es cero, pregúnteme algo así como “¿Qué debería hacer este método cuando trato de dividir por cero? ? ¿Lanzar una excepción? ¿Qué tipo de excepción debemos lanzar? ”Etc.
- Cuando el entrevistador aclara una pregunta como esa, puede darse cuenta de que tiene aún más preguntas. Explora esos. Tome notas en la pizarra a medida que obtenga estas aclaraciones, ya que informarán su solución.
- Mantén las cosas en movimiento. Siga hablando, piense en voz alta, dibuje, escriba, lo que sea que necesite hacer para mantener informado al entrevistador sobre su proceso de pensamiento.
- Finalmente, no te preocupes por terminar tu solución. La mayoría de las veces, no se trata de escribir y probar completamente una pieza de código terminada; si llega allí, eso es genial, y un buen entrevistador probablemente agregará un poco de complejidad, lo cuestionará sobre las pruebas o la complejidad operativa del solución, etc. Pero la mayoría de las veces, están más interesados en ver cómo abordas los problemas, cómo piensas y qué tan dispuesto estás a buscar ayuda. (Esto incluye casos en los que sabe lo que quiere hacer, pero no necesariamente conoce la sintaxis correcta para hacerlo en el idioma en el que está trabajando. Si puede describir lo que está haciendo, el entrevistador generalmente puede hacer referencia técnica para ti.)
Si sirve de algo, he hecho varias entrevistas (en ambos lados, siendo entrevistado y dando la entrevista) donde nunca llegamos a escribir una sola línea de código. En cambio, pasamos todo el tiempo discutiendo el problema. Personally Personalmente creo que ese tipo de entrevistas son las más divertidas.
Espero que esto ayude. 🙂 Último consejo: no tenga miedo de volver a presentar una solicitud en Amazon en el futuro. Es poco probable que haya sido “incluido en la lista negra”: deje pasar un tiempo (por ejemplo, 6 meses o un año), repase sus habilidades y, si todavía está interesado en intentarlo de nuevo, solicite un puesto nuevo. No puedo garantizar que lo volverán a entrevistar, pero ciertamente podrían hacerlo.
(EDITAR) Recuerdo que alguien en los comentarios hizo una excepción a lo que dije “En cambio, pasamos todo el tiempo discutiendo el problema”, ya que (a esa persona) le parecía que estaba diciendo que las entrevistas son solo sobre conversaciones y no técnico. Quiero aclarar este punto:
Lo que quise decir fue que a veces hacemos (o nos hacen) preguntas que son realmente de naturaleza enorme. Por ejemplo, en una de mis propias entrevistas de trabajo, me preguntaron cómo diseñaría un sistema bancario que pudiera manejar depósitos, retiros y transferencias de cuentas. Cuando comencé a explorar casos extremos, usuarios concurrentes, mecanismos de almacenamiento de datos, bloqueo de cuentas y detección de fraude, etc., el alcance del problema explotó en enormes proporciones. Lo que comenzó como un simple ejercicio para definir algunas interfaces de sentido común para estas funciones individuales se convirtió en una discusión amplia que tocó tanto los conceptos bancarios generales como el diseño de sistemas distribuidos. Dado que donde trabajo me interesan esas cosas, esto fue puntual.
Una vez que fui contratado, la persona que hizo esa parte de mi entrevista mencionó que tenía la intención de que la discusión creciera así, ya que la “prueba” que me estaba haciendo era si solo trataría de resolver el problema directo, o si empezara a mirar el “panorama general”. En muchos casos, he descubierto que esta es una diferencia principal entre los ingenieros “junior” y “senior”, ya que estaba solicitando un puesto de alto nivel, este nivel de discusión era apropiado.
Mi punto aquí es ilustrar lo que se entiende por algunas entrevistas que no involucran codificación, a pesar de que puede estar entrevistando para un puesto de codificación. La ingeniería de software, particularmente el tipo que hace Amazon, implica mucho más que la solución de problemas y algoritmos básicos. A medida que avanza en la cadena, no puede evitar asumir más en el camino del diseño a gran escala, las pruebas, la gestión de proyectos y otras cosas a las que no está acostumbrado. Y estas entrevistas, en parte, se realizan para ver qué tan listo está para salir de su zona de confort.
(Actualización 2, 8 de abril de 2018) Estaba revisando esta pregunta y encontré otra respuesta que no había visto antes, afirmando que debería estar contento de no haber sido contratado en Amazon y vinculando a un sitio de Google que documenta “gestión abuso “y tal. Solo me gustaría decir que, como ex empleado de Amazon, estoy totalmente en desacuerdo con la respuesta de esta persona (deshabilitaron los comentarios, por lo que no puedo responder directamente). Si bien no puedo hablar para todos los departamentos de Amazon, trabajé en un total de cuatro de ellos mientras estuve allí, la mayor parte de eso en AWS, y mi experiencia no tuvo nada que ver con la mayoría de los informes en ese sitio.
Hay un par de grupos en Amazon en los que la mayoría de la gente está de acuerdo con que no son ideales para trabajar, pero mi experiencia fue en gran medida positiva, y las dificultades que encontré tuvieron más que ver con el aspecto de “frugalidad” de la cultura de Amazon, sobre todo en la carrera. Equipos “ajustados” que hacen más trabajo por persona que en la mayoría de las otras compañías. Pero estaba orgulloso de ser parte de los grupos para los que trabajé, hice uno de los mejores trabajos de mi carrera (hasta ahora) en esos grupos, y dejé la compañía en buenos términos y consideraría volver en el futuro.
No le diré que no revise ese sitio de “FACE of Amazon”, pero tenga en cuenta que parece que solo han publicado historias negativas universalmente allí, por lo que el sitio parece sufrir un sesgo de confirmación. Su lenguaje y el uso de un sistema de correo electrónico anónimo sugiere que no están interesados en historias positivas para el equilibrio. Si le preocupa cómo sería trabajar en Amazon, le animo a que visite también sitios como Glassdoor para ver las calificaciones de una muestra más representativa de empleados actuales y anteriores, así como por tipo de trabajo y título.
En mi experiencia, Amazon tiene estándares muy altos para sus empleados, y PUEDE y TE QUEMARÁ si lo dejas . Sin embargo, también lo respetan cuando les dice cuáles son sus límites: si aún puede hacer su trabajo, no debe temer hacerle saber a su gerente que solo puede trabajar 40 horas a la semana.