Después de leer
esta publicación escrita por
Farwayer , al principio solo quería dejar un comentario, pero después de pensar un par de docenas de minutos, decidí que el tema era profundo, y tengo algo que decir para toda la publicación. De todos modos, por un lado, soy uno de los que no mira el código en las entrevistas y que está decepcionado por la falta de conocimiento de la complejidad de la búsqueda de índice en los DBMS relacionales, por otro lado, creo que puedo dar una idea de cómo piensa un grupo bastante grande de entrevistadores, por qué lo hacen (a primera vista) ilógico y destructivo, y qué problemas ellos mismos quieren resolver. Se espera que la comprensión de la imagen del mundo del "enemigo" responda a muchas preguntas.
Para empezar, te contaré sobre mí. Espero que esto te ayude a comprender mejor lo que se describe a continuación. En el desarrollo de software durante 9 años, durante algún tiempo trabajó para sí mismo (creó robots de intercambio y negoció con su propio dinero), la mayoría de las veces fue un desarrollador contratado (incluido el desarrollador principal). Recientemente he estado en la posición de comestibles. Recolectó 2 equipos de nivel superior. Realizó varias docenas (aunque menos de 100) de entrevistas técnicas en los puestos de middle2s Senior, senior, lead. No
trabajé en outsourcing por
un día en mi vida que pasé 18 días. Por lo tanto, puedo decir que toda la experiencia está asociada con el producto (propio o del empleador), y todas las entrevistas se realizaron con la motivación "de encontrar a la persona que aportará el máximo beneficio al producto". Admito que la experiencia del autor del artículo original es mayor que la mía, pero el objetivo no es decirte cómo hacerlo bien, ni darte consejos sobre cómo actuar, sino decir cómo puedes ver las mismas cosas desde otra, alternativa, y no el hecho de que es correcto, punto de vista
Sigamos con los puntos (los nombres se toman de la publicación original).
A nadie le importa tu código
En primer lugar, la pregunta es, ¿qué es un buen código y cuáles son las expectativas del código producido por un programador experimentado? Para mí, un buen código es una función de la tarea, las condiciones en que se establece esta tarea, las pautas adoptadas en el equipo (empresa), las expectativas del gerente técnico (arquitecto), gerente de producto, líder de control de calidad. Por ejemplo, considere varias tareas:
- Para desarrollar una API para su posterior emisión a los quinientos clientes B2B de la empresa para integrar el producto en sus soluciones: se espera una solución bien pensada y bien documentada con la estructura más comprensible, el cumplimiento de los estándares aceptados en el mercado, la validación de datos más estricta, cobertura de prueba completa, extensibilidad, registro pensado, cumplimiento de todos los requisitos de seguridad, escalabilidad en el rendimiento, resistencia a, al menos, ejemplos DoS y DDoS primitivos ;
- Para implementar el cumplimiento del producto con los requisitos del regulador, que entra en vigencia en un mes y puede conducir al cierre de todo el negocio, se espera una solución confiable con énfasis en las pruebas ;
- Se corrigió un error en el producto relacionado con el almacenamiento en caché, que se conoció una hora antes del Black Friday, se espera que la solución se escriba y se implemente en el producto en 30 minutos y no rompa nada. Otros requisitos van por el camino ;
- Pruebe la hipótesis para la que necesita analizar 250 páginas del sitio de un competidor una vez, y luego forme un documento de hoja de cálculo de Google para el analista de negocios: se espera que el programador no haga demasiado trabajo y escriba código de solo escritura sin gastar mucho en él. tiempo
- Para verificar el rendimiento de Aerospike en una tarea para la que PostgreSQL se usa tradicionalmente en la empresa y existen problemas de rendimiento, se espera que se tengan en cuenta los matices algorítmicos y el perfil de carga, pero todo el código se descartará independientemente de los resultados experimentales .
Acuerde que está mal evaluar el código que cierra todas estas tareas en los mismos patrones. Pero después de todo, a menudo se espera que un buen programador en el desarrollo de productos resuelva de manera efectiva todos los problemas anteriores. La práctica muestra que la efectividad de un programador en todos estos casos es más fácil de determinar mediante preguntas de caso y discusión de la experiencia que examinando el código escrito con variables desconocidas para el entrevistador. ¡Además, el código que el entrevistado quiere mostrar! = El código que escribe mientras resuelve problemas de negocios.
El triunfo del conocimiento inútil
Excelente comprensión de la indignación asociada con
¿Y el hecho de que buscar en los índices del árbol B en PostgreSQL tiene complejidad logarítmica? Me enteré ayer, y ahora estás
¿Pero qué por otro lado? Los errores relacionados con la complejidad algorítmica son algunos de los más desagradables para una empresa. No están cubiertos por pruebas unitarias (O (N ^ 2) durante una ejecución de prueba, donde N = 10, esto es realmente rápido), no están cubiertos por pruebas automáticas, de integración, de regresión y manuales por la misma razón. No aparecen en dbe, uat, sit (después de todo, para N = 1000 todavía es rápido). Pueden esperar años para su tiempo, sin recordarse, hasta que un comprador agregue 250 productos a su cesta, o hasta que aparezca un cliente de una empresa de corretaje que decida ensamblar un robot HFT en su rodilla. Pero, cuando aparecen, todo el negocio puede caer enfermo.
Digresión lírica sobre pruebas de rendimientoAnticipando los comentarios sobre la necesidad de las Pruebas de rendimiento, responderé de inmediato que está lejos de estar siempre claro dónde exactamente la N notoria debe elevarse al cielo. Y, dados los intentos maliciosos de organizar DoS a nivel de aplicación, se hace casi imposible prever todas las opciones. Por lo tanto, sí, también estoy a favor de las pruebas de rendimiento, pero esto no niega mi expectativa del desarrollador de que debe comprender intuitivamente dónde la evaluación de la complejidad se vuelve crítica y peligrosa para el negocio.
Esto también incluye preguntas sobre ACID. Errores relacionados con el bloqueo en el DBMS, condición de carrera, transacciones en el DBMS: esta es también la pulpa para los negocios. Ellos, al igual que los errores relacionados con la complejidad algorítmica, pueden permanecer en silencio durante años y golpear muy dolorosamente. Cuando el DBMS operativo principal de una empresa, implementado en un servidor monstruoso con la máxima redundancia para todo, simplemente se detiene con carga cero en la CPU y el IO en el momento de máxima actividad del cliente, créanme, esto es extremadamente desagradable y, sí, puede costar el salario anual de un equipo de programadores. Por lo tanto, no necesita saber cada letra de ACID de memoria (al menos nunca pido conocimiento de descifrar abreviaturas y no las recuerdo de memoria), pero la ignorancia de la esencia de cada letra ya es una aplicación seria para introducir tales errores en el código. Si hay dos programadores con tal ignorancia en el equipo, la revisión del código tampoco será una cura.
Digresión de letras sobre legado y NoSQLQuizás el ejemplo es descabellado (aunque es real para mi experiencia), y es principalmente relevante solo para sistemas antiguos y sistemas de dos enlaces, pero las arquitecturas NoSQL modernas con microservicios tienen sus propios chistes con datos fuera de sincronización y esquemas de datos no coincidentes en diferentes nodos, en diferentes versiones datos No veo ninguna razón para profundizar en eso ahora.
Derribarte
Y aqui esta. Y los chicos parecen ser adecuados. Higo entender. Y luego ves que la vacante está abierta medio año. Bien bien
El hecho de que haya una vacante disponible en el sitio web de la empresa (o en el agregador de empleos) no significa que la empresa esté buscando una persona en un equipo. La realidad de las empresas alimentarias durante el crecimiento es una eterna huelga de hambre. O escala, captura el mercado, exprime a los competidores o muere. Y el gerente de producto tiene un dolor de cabeza eterno: "qué tirar". No "por qué pensarías en uno genial para que 100 programadores puedan descargar durante un mes, para que no te aburras", sino que deberías echar de los planes a los clientes geniales, necesarios, planeados y esperados (y prometidos) para no retrasar el próximo lanzamiento por un año. Por lo tanto, no hay manos adicionales, y el hecho de que la vacante haya estado suspendida durante seis meses no cancela el hecho de que 10 personas ya la han encontrado y contratado, y tomarán lo mismo con placer. De nuevo, no en todas partes y no siempre, pero la situación que describí es normal y aceptable para el desarrollo de productos.
La idea de una amplia expansión.La práctica muestra que la extensa extensión del recurso de los programadores rara vez es efectiva y a menudo destructiva. Pero a pesar de esto, las condiciones actuales del mercado requieren esto del negocio de alimentos. De hecho, si bien la tasa de crecimiento empresarial se valora más que la ganancia operativa (no veo ninguna razón para discutir aquí si esto es correcto), los fundadores aceptan este desafío y (a veces) ganan. La opción “crecer orgánicamente sin perder eficiencia” también está funcionando, pero, por regla general, la efectividad de cada estrategia de crecimiento depende de la situación en el mercado, y una discusión sobre esto atraerá pensamientos y hechos a una gran publicación.
No me importan los proyectos pasados
Siempre pregunto Entonces, aquí estoy completamente de acuerdo con el autor. Pero el punto de vista de algunos que no preguntan también es claro para mí. Estas personas a menudo no entienden cómo comparar las diferentes experiencias de diferentes candidatos entre sí. Las respuestas a las preguntas cerradas son más fáciles de comparar.
Al comparar candidatos entre ellosDesafortunadamente, los RR.HH. y los autores de
libros inteligentes , que se sientan en una corriente interminable de arquitectos y arquitectos seleccionados ansiosos por ingresar a la compañía soñada a toda costa, les gusta construir varios sistemas de comparación que le permitan clasificar a decenas y cientos de candidatos entre ellos y elegir el mejor. Luego, estos enfoques se imponen a los entrevistadores técnicos y, como resultado, aparecen cuestionarios estandarizados que dan el modo de Dios en la entrevista durante el alta. Pero el verdadero problema ni siquiera es esto, sino que, en aras de la comparación, los entrevistadores alargan el proceso, esperan hasta que se reúna la base comparativa y, al mismo tiempo, crean problemas con la velocidad de contratar al propietario del negocio y ponen a los solicitantes en una posición desagradable, obligándolos a esperar semanas para obtener una respuesta. También obligan a los reclutadores a mentir constantemente como un bono, porque la respuesta "parece que eres bueno, pero tendríamos cinco más para comparar" no aparece, y tienes que encontrar algo de la categoría "nuestra bisabuela murió con nuestro techlide, así que volverá en una semana y eso algo decidirá ". Decidí por mí mismo que la comparación es malvada. Es adecuado: ofrezca una oferta (aunque el% de las ofertas para mí son mucho más bajas que para los colegas de comparación).
Desarrolladores experimentados
Hay un punto importante. Eso, sí, un desarrollador experimentado e ingenioso rápidamente profundiza en ello. Pero si una persona afirma que trabajó mucho con OAuth condicional en varios proyectos (es importante, así, y no "lo usó una vez en el prototipo"), y el entrevistador también trabajó con OAuth, entonces ¿por qué no preguntar? La profundidad de las respuestas mostrará cuánto profundizará una persona en las nuevas tecnologías encontradas en el camino, si comprende los principios del compartimento del motor o si copia con SO, si intenta anticipar un rastrillo.
Algunos pensamientos más
Pero aquí puede salir, haciendo una pequeña prueba durante una hora o dos (simplemente no está en su lugar: para muchos, la entrevista sigue siendo estresante).
Puede haber diferentes pensamientos sobre este tema, pero personalmente, encuentro la tarea de prueba ofensiva incluso para el nivel medio. De todos modos, la tarea de prueba es una desproporción muy fuerte en el tiempo dedicado por la empresa y el solicitante. Condicionalmente, el solicitante pasa 3 horas escribiendo un código + 5 más para lamer y buscar las mejores prácticas en Google, y un representante de la compañía da un veredicto en 1 minuto. Para esto, el solicitante necesita motivación. Por lo tanto, es una buena práctica, pero no para la evaluación de programadores experimentados y buscados que están listos para tomar sin una prueba.
Y reflexiones sobre un
comentario interesante de
loppiY si hay un problema para el que no conozco la solución de inmediato, siempre puede estudiar el problema y encontrar esta solución.
Es importante para el entrevistador no solo el hecho de que el solicitante estudiará el problema y encontrará una solución. Es importante cómo hará esto: si considerará todas las opciones o si encuentra la primera que aparezca, cómo reaccionará ante la colisión con el hecho de que la solución elegida no es válida, y tenemos que buscar una nueva, y así sucesivamente. Puede haber diferentes expectativas para diferentes circunstancias.
Solo una entrevista se destacó radicalmente de la multitud, la conversación fue cara a cara con el director técnico, él preguntó con qué tecnologías trabajé, y luego hablamos sobre varios problemas en su proyecto y en mis proyectos pasados, y cómo estos problemas se resolvieron o pueden para decidir
Sí, una excelente manera de entrevistar (creo y usarlo yo mismo), que complementa bien otros problemas. Y, curiosamente, hay un gran% de desarrolladores senior que conocen muy bien la teoría y tienen muchos años de experiencia real, pero al mismo tiempo se muestran muy mal cuando intentan resolver un problema con una gran cantidad de grados de libertad. De los inconvenientes de este método de entrevista, que requiere una larga preparación (es necesario extraer la esencia de los casos reales, omitir detalles innecesarios y resumir) y puede ser ineficaz si los desafíos clave tanto del solicitante como del entrevistador fueron específicos.