¿Por qué las empresas como Google y FB quieren un código casi perfecto en una entrevista de 45 minutos cuando tienen errores en el producto después de trabajar en él durante 45 meses?

Hay algunas partes en la respuesta:

1. Creo que proporcionar un código casi perfecto en una entrevista muestra que el candidato es capaz de traducir sus ideas en código de manera eficiente, tiene una buena comprensión del idioma y no olvida los detalles. Todas estas habilidades serán necesarias en el trabajo, así que quiero que el candidato las demuestre.
2. Como entrevistador y miembro del comité de contratación en Google, quiero un código casi perfecto en las entrevistas, porque puedo obtenerlo. Es decir, tenemos suficientes buenos candidatos, que pueden demostrar habilidades de resolución de problemas, capacidad analítica, son buenos comunicadores y pueden proporcionar un código casi perfecto en la mayoría de las entrevistas. Por lo tanto, preferimos contratar a esos candidatos a aquellos que luchan por producir código.
3. Como muchos otros mencionaron, resolver un rompecabezas de forma cerrada durante una entrevista es mucho, mucho más fácil que lidiar con una realidad multisistema, en la que está realizando cambios incrementales en un sistema complejo que ha evolucionado con el tiempo. No es sorprendente que los productos escritos incluso por muy buenos ingenieros, especialmente durante un largo período de tiempo y bajo presión de tiempo, tengan errores.
4. También escucho una nota de “es injusto de su parte exigirme cuando no pueden cumplir con su propio estándar” en la pregunta. Sin embargo, eso no es cierto: los “ellos”, es decir, los ingenieros de Google o Facebook que realmente hacen las preguntas, aprobaron el mismo proceso de entrevista con la misma barra, por lo que presumiblemente pudieron escribir un código casi perfecto para -formar preguntas algorítmicas. Se que lo estaba. Y, sin embargo, todavía he introducido errores en nuestros productos, no porque no haya podido traducir mis ideas a código de manera limpia, sino porque no conocía algunas peculiaridades particulares de una llamada API de la que dependía y supuse que no cierto; o porque me perdí una ruta de subprocesamiento no estándar a través del sistema que estaba diseñando; o porque no comprendí completamente el contexto en el que se ejecutaría mi código.

La respuesta es realmente bastante simple.

Las preguntas de la entrevista tienden a ser sencillas, y los productos reales son extremadamente complejos. Si un candidato no puede escribir un código casi perfecto para un problema directo, la cantidad de errores que el candidato introducirá para el producto complejo probablemente se disparará.

Una analogía similar, para alguien que no puede calcular 10 + 10 correcta y rápidamente, ¿desea que esa persona resuelva su problema integral?

Por supuesto, quiero aclarar en realidad que esta no es una decisión clara en blanco y negro. La forma correcta de verlo es mirarlo como una evaluación de probabilidad. Dado el rendimiento mostrado en una entrevista, ¿cuál es el rendimiento previsto en un trabajo real? Esa es la pregunta que el entrevistador intenta responder.

La mayoría de las personas que no se desempeñan bien durante la entrevista, la probabilidad de que esa persona sea fuerte es baja. Sin embargo, también hay personas cuya calidad de código no es excelente en el momento de la entrevista, pero demuestra un fuerte crecimiento y trayectoria de aprendizaje. Todavía podrían tener una oportunidad. Contraté a personas a las que no les fue bien en la entrevista, pero creo que se pueden entrenar y mejorar rápidamente, por lo tanto, aún se contratan y luego se convierten en superestrellas.

Porque quieren que arregles lo que comenzaron al contratar personas estúpidas. ¿Has oído hablar del dicho: una vez quemado dos veces tímido?

¿Sabías que Goggle quería venderse a Yahoo dos veces y el equipo ejecutivo de Yahoo pensó que Google era estúpido? Los propios Google ya no quieren cometer ese error. También leí en alguna parte que Google realmente hizo un estudio de lo que el gerente de contratación calificó a un candidato después de la contratación y lo que los candidatos resultaron: los gerentes de contratación estaban más del 50% equivocados. El artículo también concluyó que incluso Google no puede hacerlo bien. Por lo tanto, no me sentiré desalentadora si no me contrataron, no orgullosa si lo hicieron. Son otra firma en el planeta Tierra dirigida por humanos que en este momento están en un mejor mercado. FB es una gran moda, cuando la gente valorará más su tiempo personal, la moda se levantará.

Imagina que quieres contratar un guardaespaldas. ¿Contratará a una persona que dispare muy bien y sea muy precisa? Probablemente si. ¿Pero su elección solo se basará en tal habilidad? Creo que no. Querrá saber cómo reacciona ante una amenaza, si puede conducir de manera segura y eficiente en una situación crítica, podrá salvar su vida en un asalto en la calle, en un lugar lleno de gente, en su casa, en Cualquier situación posible. ¿Puede esta persona salvar tu vida si no tiene arma de fuego en este momento, puede usar un cuchillo o pelear sin nada? ¿Puede reconocer a un asaltante potencial en un primer vistazo? Y si dispara bien, ¿evitará muertes entre los transeúntes (incluido usted)? Pero solo tiene 45 minutos para ver cómo dispara usando diferentes armas de fuego que le pide que dispare desde las posiciones que le dijo que se pusiera de pie. Y luego, resulta que en cualquier situación crítica el “guardaespaldas” solo podrá sacar un arma y comenzar a disparar. Utilizando entrevistas de codificación tan ampliamente, compañías como Google y FB contratan “tiradores” con todas las consecuencias descritas anteriormente.

La corrección del código es una buena señal que predice si alguien puede tener éxito escribiendo un buen código en general en el entorno de producción normal.

El código correcto es tan importante como otras señales:

• prueba del código
• algoritmos poco notables
• fluidez general de ideas (cuando sostengo entrevistas para Microsoft lo llaman poder intelectual)
• fluidez con el lenguaje de codificación utilizado
• habilidades problemáticas generales

Tener un código correcto es bueno, pero si tiene un problema y lo encuentra y lo arregla usted mismo con un mínimo de pistas del entrevistador, es igual de bueno.

Creo que hay una desconexión entre el código que quieren y el código que los candidatos quieren escribir, pero no se trata de insistir en un código perfecto. Como ejemplo, si dice “está bien, ahora clasifico la lista …” y el entrevistador pregunta “¿cómo?”, Tiene que tomar algunas decisiones. Una opción: nombrar un algoritmo particular, momento en el cual el entrevistador solicita ver el código. Su otra opción es decir “I call` std :: sort` “(o una función apropiada para su idioma de elección). ¡Hecho! Siga adelante. En el primer caso, el entrevistador no busca la perfección, sino todos los casos de error comunes.

El verdadero secreto del código de entrevista es que casi siempre es trivial. Nunca hago una pregunta que no se pueda resolver en aproximadamente 15 líneas de código idiomático utilizando nada más que las bibliotecas estándar para el idioma. (He realizado una encuesta no científica, y nadie afirmó que su pregunta de código toma más de 30 líneas).

El uso de las bibliotecas ya escritas y probadas evita errores y acorta el código. Si algo parece que ya hay una función para hacerlo, pregúntele al entrevistador si existe y si puede usarlo. No evitaré que intentes escribir el tuyo, pero si eliges pasar tu tiempo en la parte menos interesante del problema, y ​​lo haces mal, eso dolerá.

No estoy seguro de que lo hagan, generalmente quieren establecer (1) Puede codificar (2) Cómo abordar un problema (3) Cómo reacciona bajo presión.

Si no lo hacen y solo quieren un resultado perfecto, tal vez quieras trabajar en otro lugar.

Por lo tanto, es posible que quieran verte haciendo preguntas, o al menos documentando tus suposiciones y justificando tu enfoque. Una vez que ven que estás en el camino correcto, el código perfecto es menos importante.

Si no se dan cuenta de que una vez que refactorice su código, debería reducirse y ejecutarse mucho más rápido, entonces tal vez desee trabajar en otro lugar.

Si no conversan contigo y escuchan mientras piensas en voz alta, tal vez quieras trabajar en otro lugar

Piénsalo. Si un programador que trabaja para fb introduce un error cada 45 minutos (suponiendo que es después de que él / ella realizó su propia depuración) y ese programador trabaja de 8 a 10 horas al día. Eso es un promedio de 12 errores por día en el código de producción. Ahora multiplique eso por la cantidad de programadores que trabajan en un proyecto y tendrá un gran problema en sus manos.

Depende de para qué está reclutando la empresa. Para nosotros, SQL y el análisis son importantes. Podrías ser el mejor programador del mundo, pero si no puedes utilizar SQL y depurarlo, entonces no podrás ayudarnos.

Es como pedirle a un buzo profesional que suba una montaña. Es simplemente el ajuste incorrecto, busque un alpinista si tiene que escalar una montaña. Busque un buzo si necesita realizar un trabajo a 200 ‘.

En el caso de Google y Facebook, es probable que estén reclutando para construir algo mucho más complejo que ingresar datos dentro y fuera de una base de datos, por lo que quieren más.

Por supuesto, algunas compañías quieren un buzo que también sea alpinista. Existen, pero son mucho más difíciles de encontrar. Mi consejo al respecto es dejar de perder el tiempo buscando unicornios

Para mantener a las personas que piensan en términos de derecho (“¿Cómo se atreven?”, “No merezco que me hagan esa pregunta”, o “No importa cuán mal hice en esta prueba poco realista, mi título requiere que hagan yo una oferta “) lo más lejos posible del campus.