tl; dr En las últimas décadas, la moda para entrevistar a los programadores ha cambiado varias veces, y cada uno de ellos se ve ridículo en retrospectiva. O finalmente encontramos el verdadero secreto de las entrevistas efectivas, o nos dejamos llevar por la próxima tendencia de la moda, que en diez o veinte años parecerá igual de ridícula.

Cuando le pregunto a la gente de las grandes compañías de tecnología por qué es tan necesario preguntar sobre algoritmos en una entrevista, la respuesta más común es algo como: "Tenemos una escala así, no podemos permitir que nadie escriba accidentalmente el O(n^2) y golpeó todo el sistema " ¹ . Lo que es especialmente divertido, últimamente he aplicado mucho estos algoritmos en la práctica y resuelto problemas reales, ¡pero no puedo pasar por entrevistas en las que la gente pregunta por ellos! ¿Crees que estoy fallando la mitad de las entrevistas o algo así? No, más de la mitad. Participé en unas 40 entrevistas "reales" y tal vez pasé una o dos. O ni un solo ² .

Cuando escribí un borrador de este artículo, mis amigos lo encontraron aburrido porque fallé demasiadas entrevistas. Dicen que todas las fallas deben tabularse porque nadie leerá diez páginas de texto con una larga lista de fallas. Buen consejo Ya estoy trabajando en una mesa.

Veamos algunos ejemplos.

En una gran empresa donde trabajé, el equipo escribió una biblioteca base con su propia implementación de una matriz dinámica. Si no hubo suficiente tamaño durante la operación, la implementación agregó un número fijo de filas a la matriz, y luego copió la matriz anterior a una nueva matriz de tamaño ligeramente mayor. Este es un ejemplo clásico de implementación incorrecta de una matriz dinámica , ya que conduce a un aumento lineal en el tiempo en lugar del tiempo constante amortizado . Este es un ejemplo tan clásico que a menudo se usa como canónico para explicar el análisis de depreciación.

En las grandes empresas de TI, las entrevistas telefónicas típicas se dividen en tres categorías:

1. Una pregunta de programación / algoritmo "simple", quizás primero con una pregunta de calentamiento "muy simple".
   
2. Una serie de preguntas de programación / algoritmos "muy simples".
   
3. Un montón de hechos conocidos (rara vez para buenas posiciones, pero a menudo para posiciones de bajo nivel o no creativas).

Este problema de implementación de matriz se considera tan simple que cae en la categoría de "muy fácil" y es un calentamiento para una pregunta "real" o viene con un montón de las mismas preguntas simples. Y, sin embargo, en nuestra empresa, dicha matriz dinámica era responsable de aproximadamente el 1% de la carga total en el recolector de basura en el código JVM (era la segunda fuente más grande de asignaciones de memoria en todo el código), así como de una parte significativa de la carga de la CPU.

Afortunadamente, esta implementación no se usó como una matriz dinámica universal, sino que se creó solo con la ayuda de un shell semi-especializado, por lo tanto, fue responsable de "solo" el 1% de la presión sobre el GC. Si se les pregunta en la entrevista, la mayoría de los miembros de ese equipo responderían correctamente. Mi parche trajo al empleador más dinero en un año de lo que gané en mi vida.

Era la segunda fuente más grande de asignaciones de memoria, la principal era la conversión de un par de valores long en matrices de bytes de la misma biblioteca base. Aparentemente, alguien escribió o copió una función hash que tomó una matriz como entrada, y luego cambió el código para tomar dos matrices y trabajar con ellas en una secuencia de una antigua función hash como byte[], byte[] . Para llamar a esta función en dos largos, utilizaron la conveniente función de conversión de long a byte[] en la biblioteca de utilidades ampliamente utilizada. Además de resaltar el byte[] y pegar long allí, esta función también cambia el orden del byte long (aparentemente, la función fue diseñada para convertir valores long al orden de los bytes de la red).

Desafortunadamente, cambiar a una función hash más apropiada se consideró un cambio demasiado serio, por lo que mi parche fue cambiar la interfaz de la función hash para tomar un par de longs en lugar de un par de matrices de bytes y eliminar un paso separado para cambiar el orden de los bytes (ya que la función hash ya cambió él, no se requería un paso separado). La eliminación de estas operaciones innecesarias trajo al empleador más dinero en un año de lo que he ganado en mi vida.

La optimización no es técnicamente una cuestión de algoritmos, pero en la práctica se pregunta constantemente. En respuesta a una pregunta sobre algoritmos, generalmente me preguntan: "¿Puedes acelerarlo?" La respuesta a esa pregunta a menudo incluye una optimización simple, que acelera el código varias veces.

Un ejemplo específico que me preguntaron dos veces en la entrevista: almacena identificadores como ints, pero por el contexto se deduce que los identificadores están estrechamente empaquetados, por lo que pueden almacenarse como un campo de bits. Pero la solución existente en el mundo real está tan lejos de la respuesta esperada sobre el campo de bits que apenas es posible lograr la aceleración varias veces. Lo más probable es que la entrevista termine allí.

Otro ejemplo de una pregunta simple sobre algoritmos es la configuración real de BitFunnel , el índice de búsqueda utilizado en Bing ³ .

Describir el contexto completo de esta empresa en particular llevará demasiado tiempo, pero en resumen, debe configurar un conjunto de filtros Bloom. Una forma es escribir una función de optimización de acuerdo con el modelo de caja negra, que, utilizando el descenso de gradiente, intenta encontrar la solución óptima. Lo hicieron, pero la función mostró algunas propiedades extrañas, y la configuración de salida nunca funcionó perfectamente. Esto se corrigió diluyendo los filtros Bloom, es decir, asignando aún más recursos (y, por lo tanto, dinero) al problema.

Al analizar las oportunidades de optimización, puede observar que la operación fundamental en BitFunnel es equivalente a multiplicar las probabilidades. Por lo tanto, para cualquier configuración específica, simplemente puede multiplicar algunas probabilidades y determinar cómo funcionará la configuración. Dado que el espacio de configuración no es tan grande, puede recorrer todas las opciones posibles y luego elegir la mejor. En realidad, esto no es del todo cierto, porque la multiplicación de probabilidades implica cierta independencia, lo que no tiene lugar en la realidad, pero el método todavía funciona bien por la misma razón por la que el ingenuo filtrado de spam bayesiano funcionó bastante bien, lo que supone incorrectamente una probabilidad independiente de ocurrencia en la carta cualesquiera dos palabras arbitrarias. Para una solución completa, puede analizar las interdependencias. Aunque esto probablemente esté más allá del alcance de la entrevista.

Estos son solo tres ejemplos que me vinieron a la mente, y constantemente encuentro cosas similares y puedo encontrar docenas de ejemplos, tal vez más de cien, si me siento y trato de enumerar todo lo que trabajé. Y más de cien ejemplos en los que alguien más (o nadie) trabajó. Ambos ejemplos, así como los que omití, tienen las siguientes propiedades:

1. Un ejemplo puede formularse como una pregunta para una entrevista.
   
2. Si se formula la pregunta, espera que la mayoría (o todos) los empleados del equipo relevante sepan la respuesta correcta.
   
3. Ahorrar dinero con esta solución le dará al empleador más dinero en un año de lo que he ganado en mi vida.
   
4. El problema del ejemplo persistió el tiempo suficiente, de lo contrario no se habría notado.

Al comienzo del artículo, notamos que las grandes empresas de TI hacen preguntas sobre algoritmos, ya que la ineficiencia a gran escala les costará caro. Mi experiencia muestra que en cada empresa entrevistadora, hay un millón de ejemplos de tales ineficiencias. Resulta que las preguntas sobre los algoritmos en la entrevista no ayudan a resolver problemas algorítmicos reales en el trabajo.

Una de las razones es que las grandes empresas están tratando de encontrar personas que puedan resolver acertijos de algoritmos, pero prohíben ese razonamiento en la producción.

De las tres soluciones para los ejemplos anteriores, dos fueron al producto. Para mí, este es un porcentaje normal si simplemente me invitaron a un proyecto aleatorio, que no sigo constantemente. Los cínicos pueden decir que el porcentaje es incluso alto. En un equipo aleatorio, los resultados podrían ser peores, porque no es beneficioso para ellos implementar ninguna solución, ni siquiera efectiva. Después de todo, les exige probar, integrar e implementar cambios. Se crean nuevos riesgos. Es decir, le pido al equipo que haga un trabajo y asuma algunos riesgos para hacer algo útil para la empresa, pero inútil para ellos mismos. A pesar de todo esto, las personas generalmente aceptan el código, aunque no están muy inclinados a dedicar tiempo a la optimización (su tiempo de trabajo se dedicará a cosas que sean consistentes con los objetivos del equipo) ⁴ .

Supongamos que una empresa se niega a ofrecer rompecabezas de entrevistas a los candidatos y alienta a los desarrolladores a usar algoritmos más simples y relativamente eficientes. Es poco probable que alguno de los ejemplos anteriores pase desapercibido durante muchos años. El problema probablemente se solucionará. Algún desarrollador hipotético en una empresa con perfil de código vería los elementos "más populares" en el perfil de la biblioteca con mayor consumo de recursos.

En dos casos, la solución práctica no es algún tipo de magia de algoritmos, sino solo un análisis exhaustivo. El tercer ejemplo es menos obvio ya que no existe una herramienta estándar para analizar el problema. Puede intentar presentar el resultado como una especie de dominio supremo, después de todo, este ejemplo se basa en un artículo científico que recibió un premio al mejor artículo en la conferencia más prestigiosa en su campo, pero en realidad hay matemáticas de secundaria, es decir, para resolver realmente el problema, solo necesita para estudiar dónde son aplicables estos métodos matemáticos.

Realmente trabajé una vez en una empresa que no hacía preguntas sobre algoritmos en las entrevistas, sino que se concentraba en preguntas prácticas. Durante mi estadía allí, encontré solo una oportunidad de optimización que casi cumple con los criterios anteriores (debido a su pequeño tamaño, no avanza un poco en el tercer punto, es decir, en ese momento había ganado más en mi vida que los ahorros anuales de arreglar este error)

¿Por qué esta empresa casi no tuvo problemas con los tapones de rendimiento? Creo que la razón principal es que mucha gente pensaba que mejorar su empresa era su trabajo. Por lo tanto, los sistemas fueron diseñados originalmente de manera casi óptima. Con raras excepciones, hubo suficientes especialistas que trataron de seguir beneficiando a la empresa, en lugar de personalmente a sí mismos y a su equipo (que es completamente diferente del beneficio global para la empresa). Por lo tanto, siempre hubo alguien que resolvió el problema antes de que se me ocurriera.

En las grandes empresas de TI, la entrevista en algoritmos con pruebas de habilidades de codificación suele ser más simple que la evaluación inicial por teléfono. Por lo general, los problemas de diseño del sistema no se abordan aquí.

Hace algún tiempo, intentamos hacer una pregunta sobre algoritmos en una entrevista cara a cara. Una pregunta bastante difícil, pero dentro del marco de lo que puede encontrar en la investigación telefónica en grandes corporaciones (pero aún más fácil de lo que cabría esperar de las entrevistas personales). Abandonamos esta práctica, porque absolutamente todos los candidatos fallaron esta parte (no les preguntamos a los candidatos experimentados sobre los algoritmos). Nuestra empresa no es tan conocida como para conseguir que los recién llegados puedan responder fácilmente a estas preguntas, por lo tanto, estos filtros de selección de candidatos de moda no funcionan para nosotros. En los artículos de contratación modernos, lo que hemos hecho a menudo se llama "bajar la barra", pero no entiendo por qué deberíamos preocuparnos por la altura máxima del salto del candidato si su trabajo casi (o nunca) implica saltos altos. Y en aquellos casos en los que realmente necesita saltar, la barra se establece a una altura de unos cinco centímetros.

A juzgar por el rendimiento real, fue la empresa más productiva en la que trabajé. Creo que las razones están en la cultura, y son demasiado complejas para ser completamente desarmadas en un artículo, pero probablemente nos ayudó a no filtrar buenos candidatos con la ayuda de pruebas de algoritmos. Sugerimos que las personas puedan estudiar este material en el trabajo si tenemos la cultura adecuada y los empleados hacen lo correcto en lugar de centrarse en las tareas locales para ellos o para su departamento.

Si otras compañías quieren que las personas resuelvan en el trabajo problemas de algoritmos del mismo nivel que solicitan en las entrevistas, entonces básicamente debe alentar a las personas a resolver problemas de algoritmos (cuando sea apropiado). Esto se puede hacer además o incluso en lugar de seleccionar candidatos para problemas teóricos.

Apéndice: ¿cómo llegamos a esto?

En los viejos tiempos, se hacían preguntas "triviales" en las entrevistas. Las versiones modernas podrían verse así:

• ¿Qué es el MSI? MESI? MOESI? MESIF? ¿Cuál es la ventaja de MESIF sobre MOESI?
  
• ¿Qué hace un destructor? ¿Y si es C ++ 11? Y si llama al destructor de subobjetos desde el destructor de nivel superior, ¿qué otros destructores de subobjetos se ejecutarán? ¿Y durante la promoción de la pila? ¿En qué circunstancias puede evitar llamar a std::terminate ?

Escuché sobre estas entrevistas simples en la escuela e incluso vi en algunas compañías la "vieja escuela". Esto fue durante el liderazgo de Microsoft, cuando todos los demás admiraban a una compañía exitosa y copiaban a Microsoft. El blogger de programación más leído (Joel Spolsky) dijo que todos deben adoptar algunas prácticas de desarrollo de X porque Microsoft lo hace. Por ejemplo, en uno de los artículos de programación más influyentes de la época, Joel Spolsky introdujo la llamada prueba de Joel, que determina cuánto te mantienes al día con compañías como Microsoft:

12 puntos es excelente, 11 puntos son tolerables, pero con una calificación de 10 o menos tienes serios problemas. La verdad es que la mayoría del software funciona en un nivel de 2-3 puntos, y necesitan una ayuda seria , porque compañías como Microsoft trabajan en el nivel 12 a tiempo completo.

Según las leyendas populares de la época, Microsoft preguntó sobre esas preguntas en las entrevistas (y realmente hice una de estas tareas durante una entrevista en Microsoft en la región de 2001, sin preguntas sobre algoritmos o programación):

• ¿Cómo salir de una licuadora si su altura es de 1 cm?
  
• ¿Por qué son redondas las tapas de alcantarilla?
  
• La sala sin ventanas tiene tres lámparas, cada una de las cuales está controlada por un interruptor desde el exterior. Estás fuera de la habitación y solo puedes entrar una vez. ¿Cómo determinar qué interruptor controla qué lámpara?

Desde que fui entrevistado en una era de cambio, me hicieron muchas preguntas simples y un montón de tareas (incluidas todas las anteriores). En las entrevistas de esa época, las preguntas de Fermi , que técnicamente no son acertijos, todavía eran populares. Otra tendencia de la época fueron las entrevistas conductuales sin un solo problema técnico.

Sea como fuere, la gente intentó copiar entrevistas al estilo de Microsoft. Cuando pregunté qué tipo de rompecabezas o las preguntas de Fermi eran buenas, me respondieron que de esta manera es posible verificar si el candidato es capaz de reflexionar, a diferencia de las preguntas de conocimiento que solo dicen que una persona ha recordado alguna información. ¡Y necesitamos candidatos que realmente puedan pensar!

Mirando hacia atrás, ahora está claro para todos que esto fue ineficiente, y copiar cada truco de Microsoft no haría que su empresa sea tan exitosa, porque Microsoft usó muchos otros trucos: solo fueron efectivos juntos debido al efecto de red. Al copiar las entrevistas de Microsoft, será una empresa que simplemente realizará entrevistas con el mismo estilo, pero no podrá aprovechar los efectos de red que Microsoft usó.

Para los candidatos, el procedimiento de entrevista fue básicamente el mismo que ahora con los algoritmos. Solo para prepararse para una entrevista, en lugar de "Hackear una entrevista de programación", tenía que leer "Cómo mover el monte Fuji". Es decir, tenía que aprender mucho sobre tareas que nunca usará en el trabajo, en lugar de conocimientos sobre algoritmos que nunca usará de la misma manera.

En esos días, los entrevistadores encontraron preguntas de entrevistas en los libros de preparación para entrevistas, como Cómo mover el monte Fuji. Estas preguntas se hicieron a los candidatos que aprendieron las respuestas en los mismos libros. La juventud moderna considera esto ridículo: es obvio que las preguntas no tienen nada que ver con el trabajo, y la probabilidad de una buena respuesta depende más de la preparación para la entrevista que de la competencia del candidato. Pero el enfoque de hoy no es tan diferente.

En las últimas décadas, la moda para entrevistar a los programadores ha cambiado varias veces, y cada uno de ellos se ve ridículo en retrospectiva. O finalmente encontramos el verdadero secreto de las entrevistas efectivas, o nos dejamos llevar por la próxima tendencia de la moda, que en diez o veinte años parecerá igual de ridícula.

Sin tener en cuenta la eficiencia, los métodos de entrevista en el nivel meta no han cambiado (con la excepción de la tecnología de alto nivel de la empresa más prestigiosa), por lo que todo es muy similar a otro pasatiempo de moda, que no difiere de las prácticas ridículas anteriores. La investigación empírica o una verificación independiente de la efectividad de los diferentes métodos puede sacudir mi opinión.

Inspirado por el comentario de Wesley Pharmacist-Cassels , recientemente pregunté específicamente a los representantes de los empleadores cómo verifican la efectividad de sus entrevistas y cómo manejan el sesgo. Esto es lo que respondieron (en orden decreciente de frecuencia):

• Que? Nada, ¿por qué es esto?
  
• Realmente no sabemos si nuestro proceso es efectivo.
  
• Solo sabemos que todo funciona.
  
• No tenemos prejuicios.
  
• Habríamos notado sesgo si hubiera habido un proceso de evaluación.
  
• Alguien ha estudiado y / o realizado investigaciones, pero no puede decir nada concreto sobre cómo se estudió y por qué metodología se realizó el estudio.

Aplicación: Entrenamiento

Como con la mayoría de los problemas reales, es imposible encontrar la única razón por la cual los errores que valen decenas y cientos de millones de dólares permanecen sin cerrarse en la producción. Por un lado, nos encontramos con una especie de defensa en profundidad con incentivos no coincidentes. Por otro lado, el aprendizaje es tristemente subestimado .

Ya he mencionado que en casi todas las empresas, el sistema no alienta a las personas a dedicar tiempo a mejorar la eficiencia, incluso si un simple cálculo muestra que corregir errores puede ahorrar fácilmente decenas o cientos de millones de dólares. Y en ausencia de incentivos, los desarrolladores no tienen dónde obtener experiencia para realizar dicho trabajo. El trabajo desconocido siempre parece más complicado de lo que realmente es. Por lo tanto, incluso si un día de trabajo puede generar $ 1 millón por año en forma de ahorros o ganancias (esto es bastante común en las grandes empresas, en mi experiencia), las personas no entienden que esto es solo un día de trabajo y se puede hacer sin distracción del resto de los casos. Una forma de resolver este último problema es a través de la capacitación. Sin embargo, es aún más difícil para un gerente justificarlo que aumentar la eficiencia, ¡lo cual no es parte de las tareas principales!

Por ejemplo, una vez que escribí una pequeña guía (4500 palabras, menos que este artículo, excepto la imagen) sobre cómo encontrar varias ineficiencias en el sistema: cómo usar el generador de perfiles para asignar memoria y tiempo de CPU, cómo configurar nuestro GC para tareas especializadas, cómo usar algunas de mis herramientas para encontrar automáticamente cuellos de botella en configuraciones JVM, contenedores, etc. Estos son trucos básicamente simples y muy efectivos que son fáciles de realizar. Un par de personas pudieron depurar y solucionar el problema por su cuenta, y de segunda mano escuché que alguien más había aumentado la eficiencia de su servicio. Bueno, si el 10% de los ingenieros se beneficiaron de este manual, espero que haya ayudado a docenas de ingenieros, y tal vez más.

Si, en lugar de una guía, pasara una semana en un trabajo "real", obtendría algo específico, con valor cuantitativo, que se ve hermoso en un paquete promocional o en una evaluación del desempeño. En cambio, tengo algún tipo de logro vago, que en el mejor de los casos se puede considerar en parte como un "mérito extra". No me quejo, este es exactamente el resultado que esperaba. Pero en promedio, las empresas obtienen lo que ellas mismas estimulan a los empleados. Si esperan que la capacitación provenga de los propios desarrolladores (sin financiar la producción de materiales de capacitación), pero no la valoran tanto como el trabajo de los desarrolladores, entonces la capacitación se convertirá en una rareza.

Creo que es fácil notar la baja calidad de los materiales de enseñanza pública debido a la relativa dificultad de monetizar la educación y la capacitación. Si desea monetizar los programas de capacitación, existen algunos buenos métodos. Aparentemente, la monetización de cursos de video valiosos funciona bien (cientos o miles de dólares por un curso corto). Los entrenamientos corporativos, cuando las compañías lo invitan a hablar con 30 personas, y usted recibe $ 3,000 de cada uno, también funcionan bastante bien.

Si desea llegar (y potencialmente ayudar) a un gran número de personas, publicar en Internet es efectivo, pero no espere monetización. En cuanto a los temas técnicos, es poco probable que la audiencia sin bloqueadores de anuncios sea lo suficientemente grande como para monetizar el contenido a través de la publicidad (a diferencia del acceso pago).

Por ejemplo, Julia Evans.ingresos suficientes para la venta de cómics informáticos, que recientemente generan alrededor de $ 100 mil por año. Un especialista en capacitación corporativa puede ganar esto en uno o dos días.

Apéndice: defensa en profundidad con desajuste de incentivos, parte 3

De los tres ejemplos anteriores, en dos casos recibí algún estímulo para ahorrar el dinero de la empresa. En mi experiencia, esto rara vez ocurre en grandes empresas, pero aun así, la distribución de incentivos resultó ser bastante pobre. En algún momento, después de la promoción y el aumento salarial, calculé la proporción de mi aumento y los ahorros que traje a la empresa. La proporción fue de aproximadamente 0.03% directamente en dinero, sin tener en cuenta las herramientas desarrolladas por mí, para las cuales es difícil calcular un valor específico. Probablemente este valor sea en realidad más que un valor cuantificable. Por lo tanto, podemos concluir que recibí significativamente menos del 0.01% del monto que trajo la compañía. Y esta es una evaluación sobreestimada: en realidad, sospecho fuertemente que, de hecho, el trabajo realizado no me trajo nada,y el aumento no tiene nada que ver con este proyecto, que le ahorró a la compañía decenas de millones de dólares. Después de los primeros $ 10 millones al año, o tal vez $ 20 millones al año, ya no hay ningún incentivo para hacer el trabajo en términos de evaluación de efectividad, promoción, mejora, etc. Debido a que no hay ventajas, pero hay algunas desventajas (puede involucrarse en intrigas encubiertas, derribar accidentalmente el sitio, etc.), de modo que el rendimiento de realizar un trabajo opcional sea negativo.pero hay algunas desventajas (puede involucrarse en intrigas encubiertas, derribar accidentalmente un sitio, etc.), por lo que el rendimiento de realizar un trabajo opcional probablemente sea negativo.pero hay algunas desventajas (puede involucrarse en intrigas encubiertas, derribar accidentalmente un sitio, etc.), por lo que el rendimiento de realizar un trabajo opcional probablemente sea negativo.

Algunas compañías regularmente otorgan bonificaciones muy grandes, pero yo no tenía una compañía así, y en realidad, el empleador no puede evaluar a un empleado para trabajo adicional, excepto como la calificación máxima en la revisión de desempeño, y ella representa una cantidad de trabajo "suficiente". En términos del diseño de mecanismos , la compañía en realidad les pide a los empleados que dejen de trabajar tan pronto como hayan hecho "suficiente".

Por lo tanto, incluso en este equipo relativamente profesional, el sistema de recompensas de la compañía limita a las personas sin estimularlas para maximizar la eficiencia.

También sucedió que los gerentes reciben un presupuesto de equipo para aumentar los salarios, que depende principalmente de la cantidad de empleados, y luego se distribuye entre los empleados. Básicamente, el equipo solo tiene desarrolladores productivos, por lo que nadie se destacará entre otros. Al mismo tiempo, la rotación de personal es muy baja porque a los programadores les gusta trabajar con buenos colegas. Para alentar a las personas a pasar a equipos menos efectivos, la compañía utiliza una de las palancas más poderosas: la compensación.

Dado que este es un esquema común, en algunas empresas, los gerentes tratan de mantener a los empleados inofensivos pero ineficaces para evitar las restricciones de bonificación. Si uno se pregunta teóricamente si las empresas necesitan contratar y retener personas ineficaces, la respuesta es no. Pero en la práctica, el esquema de bonos universales para un equipo estimula indirectamente esto.

Enlaces relacionados

• Contras del culto al culto de las tendencias de reclutamiento.
  
• Normalización de la desviación.
  
• El libro de Zvi Mousovitsa "Laberintos morales" sobre problemas sistémicos que causan inconsistencias incoherentes en todos los niveles de la corporación.
  
• Randomsong escribe sobre cómo puedes enseñar programación a casi cualquier persona. La idea es que la programación no es tan difícil como a muchos programadores les gustaría creer.
  
• , — ,
  
• ,
  
• 
  
• HN Google, 10% ,

---

1. En primer lugar, las entrevistas de Google a menudo copian pequeñas empresas para las cuales este argumento es inapropiado. Pero incluso ninguna de las grandes empresas desarrolla o implementa algoritmos a gran escala (Google pudo haber hecho esto por última vez alrededor de 2003, pero en las grandes y modernas empresas de TI nadie está particularmente enfocado en desarrollar algoritmos). [volver]

2. Lo "real" está entre comillas porque pasé por varias entrevistas por razones no relacionadas con el proceso de la entrevista. Tal vez tuve muy buenas recomendaciones, o tal vez alguien leyó mi blog o hizo preguntas de antiguos colegas, o miró mis proyectos de código abierto (que yo sepa, esto sucedió una o dos veces). Por lo general, después de un claro fracaso en la entrevista, pregunto por qué me ofrecieron un trabajo, así que ya reuní una colección de tales razones.

También sugiero la posibilidad de un resultado nulo, porque la única entrevista de programación "real" fue en Google, pero los tipos equivocados vinieron a entrevistarme. Fui a trabajar con hardware, y los programadores me entrevistaron, así que básicamente obtuve una entrevista estándar de programador, excepto que un entrevistador hizo algunas preguntas sobre la máquina de estado y la coherencia de caché (o algo así). Luego organizaron una entrevista telefónica con un ingeniero de hardware para asegurarse de que no mentía sobre trabajar en una startup de hardware de 2005 a 2013. Es posible que haya fallado la parte de programación de la entrevista y haya sido contratado solo debido a la conversación telefónica posterior.

Tenga en cuenta que mis resultados débiles se refieren solo a entrevistas de programación, no a hardware. Soy muy bueno entrevistando para hierro, aunque no he practicado en este trabajo durante mucho tiempo. Un amigo mío dice que las entrevistas de hardware son muy buenas para mí debido a la jerga específica: "hablo como un ingeniero de hardware" y, de hecho, hablamos el mismo idioma con los ingenieros electrónicos. Por otro lado, decimos algunas cosas de tal manera que suenan increíblemente estúpidas para la mayoría de los programadores, pero el problema es con vocabulario, jerga y no con conocimientos o habilidades reales. [volver]

3. Esta es una pregunta un poco más complicada de lo que podría haber esperado por teléfono, y tal pregunta se puede esperar en una entrevista en persona. Aunque a mi amigo en una entrevista telefónica con Google una vez le hicieron una pregunta de las finales mundiales de Google Code Jam , por lo que para la máxima complejidad realmente no hay límite, dependiendo de quién le pregunte.

Por cierto, si estás interesado, mi amigo realmente sabía la respuesta, porque resolvió este problema en Google Code Jam. En la competencia, no encontró la respuesta correcta, pero luego la buscó por diversión. Sin embargo, no consideró razonable responder de inmediato por teléfono, pero le pidió al entrevistador que hiciera otra pregunta. Él se negó, por lo que mi amigo falló una entrevista telefónica. Aunque dudo que haya más de un par de cientos de personas en el mundo que puedan responder correctamente a esa pregunta por teléfono, y casi todos probablemente entenderían lo absurdo de la situación. Después de suspender la entrevista, mi amigo estuvo buscando trabajo durante casi medio año antes de comenzar una entrevista para una startup, para lo cual eventualmente desarrolló varios sistemas clave (en términos del impacto en el negocio y las dificultades técnicas). Él continúa trabajando allí despuéscómo la compañía realizó una salida a bolsa de más de mil millones de dólares. La compañía comprende lo difícil que es reemplazar a esta persona y la trata muy bien.[volver]

4. Además de los problemas arquitectónicos evidentes que simplemente conducen a una caída en el servicio, hay otro punto. Los equipos a menudo resuelven problemas de rendimiento simplemente solicitando recursos informáticos adicionales. Algunas compañías están tratando de lidiar de alguna manera con esto. Escuché que en Facebook, muchos equipos que trabajan para mejorar la eficiencia informan a un departamento especial que les permite bloquear las solicitudes de expansión de capacidad si notan una ineficiencia extrema en un equipo que se niegan a arreglar. Pero personalmente, no encontré tales compañías. Google trató de resolver este problema con un sistema que, entre otras cosas, correlacionaba el número de empleados con recursos informáticos, pero escuché que finalmente se abandonó a favor de un sistema más tradicional por alguna razón.. [volver]