¿Debo señalar que la respuesta que se me ocurrió también fue una respuesta correcta después de la entrevista?

Entonces tuve una entrevista técnica y el entrevistador me hizo una pregunta que puede tener múltiples respuestas. Se me ocurrió una solución y se la expliqué, pero él tenía otra solución en mente y no aceptó mi solución, incluso si le di un razonamiento lógico detrás de mi enfoque. No estaba 100% seguro porque se me ocurrió el enfoque y no tenía antecedentes del problema dado.

Después de la entrevista confirmé que la solución que se me ocurrió es perfectamente aceptable y una de muchas soluciones. Entonces, ¿debería enviarle un correo con las referencias adecuadas de que mi solución fue correcta? ¿Es esa una buena práctica?

Si no hago esto, me temo que podría ser rechazado por esto y después del rechazo no tiene sentido enviarle un correo.

Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .
Mi primera entrevista de trabajo Conseguí el trabajo. 6 meses después, mi jefe me mencionó que en una de las preguntas encontré una laguna que simplificó la pregunta significativamente, y cambió la pregunta de la entrevista debido a mi respuesta, para cerrar la laguna :) así que es posible que te contraten de todos modos.
¿Estás seguro de que "no aceptar" tu solución a un problema de respuestas múltiples no fue parte de la entrevista? ¿Para ver cómo manejaste la adversidad? Ser capaz de manejar una solución con la que no está de acuerdo es una parte importante de estar en un equipo...
@WernerCD El problema con la interpretación de las preguntas de los juegos mentales es que también puede ser al revés. ¿Qué pasa si está probando qué tan resuelto es el OP en su opinión de que sabe que tiene razón o si simplemente será un hombre de sí para los superiores?
@Jack, bueno, no dije que estaba de acuerdo con ese tipo de preguntas; mucho depende de cómo haces la pregunta y cómo desafías al entrevistado y todo eso. Pero sí, la interpretación podría ser multifacética: tratar de interpretar el juego en equipo (mi sugerencia) o tratar de determinar si es un pusilánime (su sugerencia) o cualquier otra determinación de personalidad. Así que supongo que mi pensamiento no es realmente sobre el "juego de equipo" en sí, sino sobre el rechazo de ser parte de la entrevista en su conjunto para tratar de obtener algún juicio sobre las reacciones.
Realicé toneladas de entrevistas para muchas empresas. Algunos con buenos colegas, algunos con menos buenos colegas. Sin embargo, una cosa común es que todas las personas con las que me asocié para dar una entrevista conocían el problema al pie de la letra. A lo largo, en profundidad. ¿Por qué? Porque no hay manera de que puedas manejar dar una entrevista de otra manera. Entonces, lo que me hace pensar es cómo reconciliar "él tenía otra solución en mente y no aceptó mi solución" con su historia. Entonces, o hubo una falla importante en su solución, o simplemente detectó una gran señal de alerta para esta empresa.

Respuestas (10)

Las posibilidades de que esto ayude a su situación son escasas o nulas. Dependiendo de cómo se redactaría el correo electrónico, incluso podría perjudicar significativamente sus posibilidades.

Si fuera solo una de muchas preguntas, no me preocuparía demasiado. Si el resto de la entrevista salió bien y mostró un conocimiento general en otras situaciones, me sorprendería un poco si lo rechazaran solo por esa pregunta.

Del poco conocimiento que tengo en la contratación de personas. Incluso en una entrevista técnica, estaría más interesado en sus habilidades de comunicación y en cómo intenta resolver un problema, en lugar de saber la respuesta o no.

En este caso, lo mejor es esperar y ver qué sucede.

A veces, el punto es ver cómo el candidato defiende su solución y reacciona a las críticas más que si obtuvo la respuesta "correcta".
@ColleenV Si, después de una explicación del razonamiento, el entrevistador aún insiste en que la respuesta es incorrecta. No hay mucho más que hacer aparte de discutir, algo que nunca querrías hacer. OP también declaró que no hubo una crítica real o una explicación de por qué la respuesta correcta es la que es. Si era el plan de los entrevistadores medir la respuesta a la crítica de esa manera, era una forma bastante mala de hacerlo.
Hablaba más en general que sobre esta situación en particular. Voté a favor de su respuesta: solo estaba agregando un pensamiento adicional, no criticando.
Creo que tu punto es cierto en muchos casos. Sin embargo, entrevisto a personas todo el tiempo y si recibo un correo electrónico CORTE que dice algo como "Hola, pensé más en el problema que discutimos en la entrevista, y el enfoque x que tomamos PUEDE ser correcto PORQUE" me haría reconsiderar. Sin embargo, otra cosa a tener en cuenta es que generalmente brindamos comentarios de una entrevista técnica INMEDIATAMENTE, por lo que sería un gran esfuerzo para el técnico volver a pasarlo a la cadena.
@VSO Si bien podría funcionar para usted, incluso entonces una o dos diferencias en la forma en que se escribe el correo o incluso tener una mañana mala y ocupada mientras lee puede cambiar la forma en que se recibe ese correo, incluso si tiene a alguien para quien podría funcionar en un buen día sus posibilidades no son grandes. Y puramente un sentimiento mío. Si se niegan a dar explicaciones en el momento, probablemente no apreciarán que presiones tu respuesta.
Tengo que estar de acuerdo con @BobMeijer. Si puedes defender tu diseño durante la entrevista, ¡es increíble! Pero si tiene que enviar un correo electrónico al respecto más tarde, todo lo que hace es recordar a los entrevistadores que no presentó una defensa durante la entrevista, que habría sido el momento adecuado.
@VSO "sería un gran esfuerzo para el técnico volver a pasarlo a la cadena". Nah... sería reenviar el correo electrónico OP enviado al entrevistador... casi cero esfuerzo. No digo que OP deba enviarle un correo electrónico, pero la idea de que es mucho esfuerzo no es cierta.
Leer el correo electrónico. Evalúa si el correo electrónico tiene sentido. Haga un seguimiento con el reclutador y los entrevistadores posteriores para informarles que cambió de opinión sobre las calificaciones técnicas debido a información adicional, no un correo electrónico estándar, mientras se toma un tiempo de su día para hacer lo que sea que haga. Eso me parece bastante lento. ¿De verdad quieres añadir media hora a tu jornada laboral? Creo que esa es parte de la razón por la que las personas dicen que es poco probable que sea útil: las personas tienden a enojarse cuando necesitan hacer un trabajo adicional, especialmente sin una buena razón.
¿Realmente querrías trabajar en un lugar donde enviar un correo electrónico así hubiera impedido que te contrataran? Trabajar para alguien que estaba tan arruinado parece terminar en lágrimas.

Parece ser un hecho poco conocido entre la sociedad pero muchos problemas tienen más de una solución. Tal vez decirte que tu respuesta fue incorrecta fue la prueba. A veces los empleadores te buscan para que retrocedas y digas "Mira. Mi respuesta también es correcta y he aquí por qué..." o tal vez te buscaban para considerar la posibilidad de la respuesta del entrevistador y considerar que puede ser la mejor manera. ir.

Están midiendo tu respuesta a cierto estímulo. Quieren ver cómo maneja la situación porque es probable que surjan situaciones similares de manera regular en su lugar de trabajo y deberá poder manejarlas de manera efectiva. En muchos casos, esto requiere ser un artista de improvisación excepcional para manejar situaciones inesperadas con gracia.

Solo depende de lo que estén buscando y es por eso que ayuda investigar al empleador tanto como sea posible de antemano o tener experiencia en la industria. Si no tiene idea de lo que están buscando, es casi imposible encontrar una respuesta aceptable. Debe preguntarse cómo alguien en este rol manejaría la situación y la investigación/experiencia ciertamente lo ayudará a resolverlo.

Una entrevista técnica es un mal lugar para hacer una "prueba de interacción personal", pero definitivamente es posible. Es posible que quieran ver si el OP los molestará sobre su propia solución correcta, en lugar de recibir comentarios y aprender. Si este es el caso, enviar un correo electrónico es una muy mala idea, ya que no quieren que las personas siempre "aboguen" por qué su código es correcto cuando un revisor de código dijo que no lo era.
@computercarguy, Las soluciones a los problemas de entrevistas técnicas de codificación generalmente se juzgan según dos criterios: complejidad de tiempo y complejidad de espacio. En la mayoría de los casos, encontrar una solución que funcione simplemente no es suficiente. Debe saber qué solución es la más eficiente, en términos de tiempo y espacio. Dado que el OP solo habla sobre la lógica de su solución y no sobre su eficiencia, supongo que esta es la razón por la cual el entrevistador prefirió otra solución a la suya. Vea mi respuesta para una explicación más larga.
Este. Y a veces, discutiendo los méritos de dos soluciones, surgirá una tercera que mejora ambas. Pero eso ahora es agua debajo del puente.
@StephanBranczyk, su respuesta también hace muchas otras suposiciones, con la mayoría de las cuales no estoy de acuerdo. Sí, podrían ser ciertas, pero tienen la misma probabilidad de estar equivocadas. Como tales, ofrecen poco en cuanto a ser la respuesta, especialmente porque esas suposiciones se basan en un WAG de lo que el OP y el entrevistador tenían como soluciones o incluso como una pregunta. Esperaría que una revisión de código tuviera ese tipo de requisitos, pero una pregunta de entrevista simplemente no tiene el tiempo o las capacidades de prueba de unidad para requerir una respuesta tan detallada.
Y si lo único que buscas es alguien que ya sepa la Respuesta en una entrevista, probablemente estés sofocando la creatividad y el ingenio.
@computercarguy, "una pregunta de entrevista simplemente no tiene el tiempo o las capacidades de prueba unitaria para requerir una respuesta tan detallada". Lo siento, pero las pruebas unitarias no tienen nada que ver con la complejidad del tiempo o la complejidad del espacio. Nuevamente, dije esto en mi último comentario sobre la otra respuesta, pero vale la pena repetirlo: como entrevistadores técnicos, no esperamos una respuesta perfecta durante las entrevistas técnicas, pero si va a contradecirnos o enviarnos un correo electrónico sobre qué enfoque que deberíamos haber tomado, es mejor que esté listo para respaldar su razonamiento con algunos argumentos sólidos basados ​​en la complejidad del tiempo y el espacio.

Desafortunadamente, es un caso de "simplemente olvídalo".

( SI fuera alguien a quien conocieras muy bien y con quien conversaras mucho, podrías enviarle un correo electrónico y decir "Estaba pensando en X, y...". Pero parece que este es solo otro entrevistador corporativo).

Entonces, ¿debería enviarle un correo con las referencias adecuadas de que mi solución fue correcta?

Desafortunadamente, en el 99,99% de los casos, simplemente eliminarían el correo electrónico.

Al igual que los CV solo se miran durante 2 segundos, los entrevistadores simplemente revisan las entrevistas técnicas y tachan a las personas de las listas.

¿Es esa una buena práctica?

Yo diría que es inofensivo . No molestará, digamos, a la persona. Pero, lamentablemente, en el 99,99 % de los casos, simplemente eliminarían el correo electrónico.

Desafortunadamente, la respuesta general a su pregunta es "En el 99,99% de los casos, es completamente inútil hacer un seguimiento de una pregunta de entrevista técnica".

"los entrevistadores simplemente revisan las entrevistas técnicas y eliminan a las personas de las listas". -- Sin embargo, eso suponiendo que el grupo de candidatos sea grande. Incluso si es grande, es posible que no estén "girando" a través de ellos. Esto es solo una suposición y creo que la conclusión es la misma sin ella, así que no veo cómo es relevante.
@CaptainMan: es un buen punto; debido a la escasez extrema de programadores en muchos campos, puede que solo haya 1 o 2 candidatos de todos modos

Tenga en cuenta que los entrevistadores no son perfectos. En particular para su caso, los entrevistadores no siempre son programadores fuertes. No está fuera de discusión que simplemente no entendieron su solución.

En ese sentido, parte de la mayoría de los trabajos de programación es justificar su solución a los demás. Si no puede hacer eso en el transcurso de una reunión, su solución realmente tendría que ser superior para justificar volver a mencionarla.

Si su entrevistador es un codificador fuerte, tenga en cuenta que una solución "correcta" puede no ser lo suficientemente buena. Prefieren algo legible, comprobable, eficiente e idiomático. Otra cosa que he visto que hacen los entrevistadores de codificadores fuertes es mostrar una solución alternativa para ver si puede señalar las compensaciones entre esta y la suya.

En cualquier caso, no hay mucho beneficio para que lo menciones ahora. Tómalo como una experiencia de aprendizaje y trata de pensar en cómo podrías manejarlo mejor la próxima vez.

¿Deberías enviar un seguimiento sobre esto? Sí. No, quizás.

No esperaría que esto haga una gran diferencia (si es que hace alguna diferencia) en su decisión en cualquier caso, pero repasemos las opciones.

No.

Si lo explicaste lo suficientemente bien durante la entrevista y aún así no lo aceptó, es muy probable que no responda positivamente si sigues adelante.

Algunas personas están menos abiertas a la retroalimentación que otras. También puede ser que lo entendiera perfectamente bien, pero había algún otro problema con eso.

¿Estás 100% seguro de que tienes razón? Si hace un seguimiento y en realidad se equivocó, eso enviará el mensaje de que usted es el que no está tan abierto a recibir comentarios (a menos que tal vez lo diga con mucha, mucha gracia).

Si puede haber pasado por alto alguna restricción oculta o podría haber alguna otra razón válida por la que no aceptó su enfoque, tampoco sería una buena idea hacer un seguimiento. Por supuesto, es de suponer que no sepa esto, pero tal vez pueda llegar a una suposición razonable de qué tan probable podría ser.

Sí.

Si lo explicaste mal durante la entrevista o es una explicación que se beneficiaría mucho de algunos enlaces, podría ser útil hacer un seguimiento.

Algunas personas agradecerían mucho que un candidato pensara en el problema después de la entrevista y dedicara algo de tiempo a ello. Demuestra que realmente te preocupas por el trabajo.

Es posible que otros no lo aprecien tanto, o que ya haya tomado la decisión, pero en esos casos probablemente no duela.

  • Probablemente intentaría incluir algún código de trabajo ejecutable o un enlace o dos a un sitio de buena reputación, si corresponde.

  • No haga su respuesta demasiado larga ni incluya demasiados enlaces e intente mantener el código al mínimo necesario.

  • No lo enmarques como "estás equivocado". En caso de duda, simplemente evite por completo abordar cómo respondió. Podrías ir con algo como:

    Estaba pensando un poco más sobre el problema y se me ocurrió este código para demostrar que funciona.

    (Esa es una respuesta bastante rudimentaria para dar una idea básica. Agregue estilo y ajuste la redacción según el gusto).

En conclusión: tal vez.

Si la entrevista salió bien, además de este problema , deberá elegir si desea realizar un seguimiento usted mismo en función de su situación, cómo fue exactamente la entrevista, qué tan significativa fue esta pregunta, cómo cree que recibirán su seguimiento. y para qué tipo de empleador desea trabajar (y para qué tipo de empleador no desea trabajar, aunque también vale la pena tener en cuenta que un entrevistador no siempre será representativo de la cultura general de la empresa).

Si la entrevista salió bien, pero no lo suficientemente bien como para recibir una oferta, no hay mucho riesgo en el seguimiento. No tienes mucho que perder.

Sin embargo, si la entrevista fue terrible, es muy poco probable que esto la salve, por lo que el seguimiento probablemente solo sería una pérdida de tiempo para ambos. Aunque todavía no tienes mucho que perder y probablemente estarías desperdiciando más tu tiempo que el de ellos (ya que probablemente simplemente lo ignorarían).

Aunque también puede haber juzgado mal cómo fue, lo que puede suceder, por lo que tendría cuidado de no sacar conclusiones precipitadas.

Creo que diste en el clavo aquí: "Si lo explicaste lo suficientemente bien durante la entrevista y aún así no lo aceptó, es muy probable que no responda positivamente si sigues adelante".

No le mandes mail, ese tiempo ya pasó y ya lo explicaste. Si es un profesional serio, es posible que lo haya buscado él mismo para verificar su respuesta. Ciertamente lo hago si alguien cuestiona lo que creo que es correcto.

Habiendo dicho eso, si hay múltiples respuestas posibles y estoy buscando una en particular, entonces no importa si su solución es viable, no es la solución que estoy buscando por el motivo que sea. En su escenario específico, la probabilidad es que estaba buscando la solución más simple.

En cualquier caso, existe un riesgo potencial con una posibilidad insignificante de un resultado favorable del envío de correos electrónicos.

No, y no acepte una oferta de esta empresa.

Hay una expresión que se usa cuando se contrata gente: gente de calidad "A" contrata gente de calidad "A", gente de calidad "B" contrata gente de calidad "C". La explicación detrás de esto es que las personas que son realmente buenas quieren seguir aprendiendo y contratar a personas de las que puedan aprender, mientras que las personas que son inseguras en sus puestos dejarán pasar a alguien mejor que ellos.

El entrevistador no buscaba saber qué tan bueno eras en la entrevista, buscaba saber qué tan bueno era él. No está interesado en contratar por diversidad de pensamiento, solo está interesado en contratar personas que piensen en los problemas y los vean y resuelvan los problemas exactamente de la misma manera que él, pero no mejor.

Después de una entrevista como esta, si recomienda contratarte, es solo porque piensa que eres peor que él y estás entrando en un ambiente de trabajo ya tóxico que permite que las personas se clasifiquen a sí mismas, y donde la jerarquía claramente importa ( o alguien no estaría entrevistando de esta manera).

Las entrevistas son una calle de dos sentidos

No se trata solo de que te conozcan, se trata de que tú los conozcas y descubras si este es un lugar en el que quieres trabajar. Cómo entrevistan, y cómo tratan las respuestas que les das, dice mucho sobre lo que es importante en la empresa. De esta entrevista, puede deducir que pensar fuera de la caja probablemente no sea bienvenido.

Tenga en cuenta la posición de los entrevistadores en la empresa. Si este fuera el líder técnico del equipo al que estarías reportando, puedes esperar que cualquier opinión diferente sea aplastada si aceptas este trabajo. No está buscando propuestas o nuevas ideas, solo un mono de código para golpear la computadora como un esclavo todo el día.

El problema con las preguntas Gotcha

La mayoría de los trabajos (y usted menciona específicamente la tecnología, y he estado en el campo de la tecnología durante casi 20 años y es especialmente cierto allí) son completamente situacionales. Encontrará a lo largo de una carrera que las personas usarán la misma tecnología y las mismas pilas de tecnología y las mismas herramientas de maneras muy diferentes. La exposición a la mayor cantidad posible de estas cosas es clave para una buena carrera.

Sin embargo, la mayoría de las preguntas de la entrevista son igualmente situacionales y se basan en la experiencia de los entrevistadores. (Esta es la razón por la que recomiendo encarecidamente hacer una "investigación de oposición" sobre su entrevistador si tiene el nombre y el tiempo; comprender cuáles son sus antecedentes puede ayudarlo a prepararse para la entrevista para que coincida con sus posibles preguntas).

Este tipo de preguntas de situación son útiles SOLAMENTE si se trata de una pieza de tecnología rara, única y específica (generalmente heredada) en la que un candidato ha propuesto tener un conjunto de habilidades. Hacer preguntas con una sola solución o con un bucle El agujero que hace que la pregunta sea una trampa no ayuda a evaluar qué tan inteligente es un candidato. Es frustrante para el candidato y lo hace parecer extremadamente arrogante. Es un guardián literal en la industria de TI.

Si su respuesta a esto es "Todos los que trabajaron en tecnología deberían saberlo". usted es parte del problema y también lo es cualquier pregunta que esté haciendo. Si escuchas eso en una entrevista, es una gran señal de alerta.

Telegrafiar sentimientos en una entrevista es una mala idea

Al entrevistar a un candidato, nunca debe proporcionar ningún tipo de retroalimentación durante la entrevista. Alterará el estado de ánimo de los candidatos y cambiará la forma en que te responde. Los entrevistados que están nerviosos tendrán problemas para responder preguntas, y si creen que estás buscando algo específico, intentarán darte la respuesta que creen que quieres para conseguir el trabajo. Esto es malo porque no le da la oportunidad de entrevistar adecuadamente al candidato.

Una de las formas más seguras de decirle a un Candidato cómo le está yendo en una entrevista es decirle cuál es la respuesta 'correcta' (y uso este término vagamente). Transmitirle a un candidato que es poco probable que consiga el trabajo, en el mejor de los casos inconscientemente hará que lo haga peor y, en el peor de los casos, intencionalmente hará que se vaya. Que alguien haga esto en una entrevista muestra que, para empezar, carece del tipo de habilidades interpersonales necesarias para evaluar candidatos.

Lo que debería haber pasado

En este caso, suponiendo que su respuesta fuera técnicamente correcta (y quizás el entrevistador creía legítimamente que no lo era), debería haber seguido con más preguntas. "¿Por qué tomarías ese enfoque?" "¿Qué ventajas trae esta solución que otras soluciones no tienen?" "¿Cuál es una debilidad potencial de este enfoque?"

Si de hecho solo hay una respuesta correcta, la respuesta debe presentarse en lugar de pedirse y luego la pregunta debe formularse de la siguiente manera: "¿Qué problemas ve con este enfoque y qué enfoque tomaría en su lugar?"

Sin embargo, como mencioné anteriormente, eso requiere que un candidato se divorcie de su pregunta engañosa que se le ocurrió por su cuenta y la mayoría de las personas tienen dificultades para hacerlo.

Un ejemplo, en la práctica

Recientemente, durante un proceso de entrevista, le hice una pregunta a alguien (¿Cómo cambiaría el nombre de un archivo en Git?). Esta pregunta tiene muchas respuestas, y ninguna de ellas es intrínsecamente correcta o incorrecta, pero algunas tienen más beneficios que otras (usar el comando mover en Git conserva el historial adjunto a ese archivo, en lugar de cambiar el nombre del archivo y volver a confirmarlo). Esta pregunta se diseñó para determinar el nivel de habilidad de alguien que se entrevista en la empresa. Un usuario avanzado comprenderá las sutilezas involucradas y alguien en una etapa más intermedia no comprenderá la desventaja del enfoque que elige tomar.

Cuando el candidato respondió con la respuesta 'incorrecta' (a los efectos de esta conversación), seguí preguntándole sobre el escollo de su solución en comparación con la otra (en este caso, "Perdería el historial de archivos aunque si hicieras eso, ¿no es así?").

Esto no les dice cuál es la respuesta correcta o si necesariamente se equivocaron, solo expande la conversación para transmitirme cómo piensan sobre el problema, que como otras respuestas han aludido y explicado mejor, es el objetivo de la entrevista:

El propósito de una entrevista es evaluar el nivel de habilidad de los candidatos para determinar si pueden realizar las funciones descritas.

No es necesario que se apliquen las preguntas Gotcha.

historia divertida: git conserva la historia incluso si cambia el nombre del archivo manualmente. en realidad no tiene ninguna noción de un cambio de nombre comprometido en absoluto; se da cuenta de los cambios de nombre basados ​​en archivos similares que se eliminan y agregan en la misma confirmación
Simplemente cambiar el nombre del archivo sin git mv"conserva el historial" tanto. Puede estar pensando en git log --followcuál se necesita para ver el historial de un archivo renombrado a través de cambios de nombre (incluso si usa git mv). Si esta pregunta fue diseñada para descubrir la habilidad de los candidatos, asegúrese de entenderla para no convertirse en el entrevistador del que se queja OP. Puede probar esto creando un archivo con texto, moviéndolo con y sin git mvy viendo que ambos "pierden historial" con git log -- filepero "mantienen historial" si usa git log --follow -- file.
esta respuesta me enseño mucho

Esto me pasó una vez en una entrevista con una empresa FAANG. Me encontraba muy molesto. Sin embargo, realmente no vale la pena. Se considera un comportamiento poco profesional ponerse en contacto con cualquier persona involucrada en el proceso de reclutamiento, excepto directamente con su reclutador, a menos que se especifique lo contrario, por cualquier motivo, y en este caso específicamente se presenta como una intimidación argumentativa y límite (aunque tiene razón).

Habiendo pasado por la capacitación para entrevistas de FAANG (en una empresa de FAANG), a los entrevistadores (al menos en esas empresas) se les dice específicamente que no se desvíen hacia una o un pequeño subconjunto de respuestas "aceptables", y que escuchen honestamente lo que el candidato tenga que decir. ; como lo hizo usted, a veces la respuesta dada por el candidato es correcta pero no la esperada. Sin embargo, desafortunadamente, como en mi situación, a veces los entrevistadores no cumplen con ese entrenamiento. Apesta, pero sucede.

Si se siente realmente molesto por esto, es posible que desee mencionárselo a su reclutador. Es poco probable que hagan algo para ayudarte, pero es posible y no te hará daño.

Cabe destacar que otro punto en la capacitación de entrevistas de FAANG que tomé es que el hecho de que el candidato presente una respuesta funcional no es tan importante como crees. Diría que tal vez el 20% de su "calificación" para la entrevista (tal como es) es si su respuesta es correcta o no. Más importante es cómo abordaste el problema. ¿Hizo preguntas aclaratorias y/o expuso sus suposiciones? ¿Dividiste el problema en partes o simplemente trataste de conquistarlo todo a la vez? Cuando el entrevistador lo aguijoneó con sugerencias y comentarios orientadores, ¿los aplicó y reaccionó de la manera que el entrevistador esperaba? Esas cosas son mucho más importantes (al menos en la empresa en la que hice mi entrenamiento para entrevistas) que si realmente obtuviste o no la respuesta "correcta".

¿Le importaría editar esta respuesta para explicar qué significa el acrónimo FAANG? Gracias.
"Facebook, Apple, Amazon, Netflix, Google". Básicamente es una jerga que significa "empresas de alta tecnología", y es tan común que la mayoría de la gente lo sabe (o puede buscarlo en Google).
Sí, lo busqué en Google. Pero es mejor si las respuestas pueden ser independientes. Y "la mayoría de la gente lo sabe" probablemente se refiere a la mayoría de las personas en el desarrollo de software. Hay muchas otras ocupaciones representadas en este sitio.

No:

  • Si te rechazan por eso, no quieres trabajar para ellos.
  • Si te rechazan por otras razones, no importa.
  • Si te aceptan de todos modos, no importa.

Se me ocurrió una solución y se la expliqué, pero él tenía otra solución en mente y no aceptó mi solución, incluso si le di un razonamiento lógico detrás de mi enfoque.

Puede enviarle un correo electrónico si lo desea, pero si lo hace, le recomiendo que especifique la complejidad de tiempo y la complejidad de espacio de su enfoque deseado frente a la complejidad de tiempo y la complejidad de espacio de su enfoque sugerido.

No digo que tu desempeño en la entrevista tuviera que ser perfecto. No tiene por qué serlo, pero si va a contradecir y posiblemente enviar un correo electrónico a un entrevistador sobre un posible error que haya cometido, realmente debe asegurarse de que su solución sea la más óptima tanto en términos de eficiencia de tiempo como de en cuanto a la eficiencia del espacio.

Después de la entrevista confirmé que la solución que se me ocurrió es perfectamente aceptable y una de muchas soluciones.

Dudo que. Solo para darte un ejemplo, mira lo que hizo esta persona:

Buscó la respuesta en HackerRank y pensó que su solución era perfectamente adecuada para un problema de entrevista de codificación que alguien más había publicado.

Su respuesta: https://codereview.stackexchange.com/a/212530/7219

Pregunta original: https://codereview.stackexchange.com/questions/212492/bracket-matcher-in-python

Desafortunadamente, no se dio cuenta de que el mismo problema puede tener muchas variaciones leves y que la solución que encontró puede haber sido óptima para el problema que encontró en HackerRank, pero seguro que no fue óptima para el problema de la entrevista de codificación que el OP tuvo que resolver. resolver.

Por favor, no seas ese tipo.

Hasta el día de hoy, no sabe lo que hizo mal y sigue negándolo, a pesar de que dos ingenieros superiores le señalaron su error.

Copiar y pegar una respuesta sin entenderla es completamente diferente a lo que dice el OP. Además, no entran en los detalles de cuál fue la pregunta real o su respuesta, por lo que hacer declaraciones generales sobre cuán "básica" fue su respuesta es peor que inútil. Y comparar su código con el "90% de otras personas" tampoco es una suposición válida. Todo lo que hace es reforzar el síndrome del impostor de las personas, y eso nunca es bueno. Ignora la posibilidad de que el entrevistador estuviera enamorado de su propia respuesta, por lo que todo lo demás estaba "obviamente" mal.
@computercarguy, ¡Por favor, no me malinterpreten! Nadie espera una respuesta perfecta durante una entrevista de codificación técnica. Dicho esto, si justificar sus decisiones en función de la complejidad del tiempo y la complejidad del espacio aún no se le ha metido en la cabeza, no contradiga ni envíe un correo electrónico a su entrevistador técnico sobre el enfoque que debería haber tomado.
@computercarguy, esta noche voy a modificar mi respuesta completa para reafirmar lo que dije en mi comentario anterior. Ten paciencia conmigo mientras hago eso.