¿Por qué las entrevistas de ingeniería de SW son desproporcionadamente difíciles (vs. entrevistas de investigación)? [cerrado]

Primero, algunos antecedentes sobre mí. Tengo un doctorado en CS y he tenido trabajos como ingeniero de software y como científico de investigación de I + D, ambos en Very Large Corporations que conoces muy bien. Recientemente cambié de trabajo y me entrevisté para ambos tipos de puestos (como lo he hecho en el pasado).

Mi observación: las entrevistas de trabajo de ingeniero de SW son mucho más desproporcionadamente más difíciles que las entrevistas de trabajo de investigador de CS, pero el trabajo de investigador es mejor remunerado, más competitivo, más gratificante, más interesante y tiene una ventaja más alta.

Aquí hay un típico bucle de entrevista para el investigador:

• Entrevista telefónica para ver si mi investigación está alineada con la investigación del laboratorio.
• En persona: dar una presentación sobre mi investigación reciente durante una hora (que representa quizás 9 meses de trabajo) y responder preguntas de la audiencia
• Entrevistas personales en persona con unos 5 investigadores, donde me hacen preguntas muy razonables sobre mi trabajo / publicaciones / patentes, que incluyen: preguntas técnicas, dónde encaja mi trabajo en el trabajo relacionado y cómo puedo extender mi trabajo a nuevas áreas

Aquí hay un bucle de entrevista típico para el ingeniero SW:

• Entrevista telefónica donde me hacen preguntas sobre algoritmos y tal vez haga algo de codificación. Bastante estándar
• Entrevistas en persona en la pizarra donde te sacan el F *** con minucias esotéricas de C ++ (por ejemplo, cómo funciona una llamada de función virtual polimórfica), algoritmos (hacen que el algoritmo de ruta más corta de todos los pares funcione para vértices 1B) , diseño del sistema (diseño de un balanceador de carga de la base de datos), etc. Esto continúa durante seis o siete entrevistas. Ridículo.

¿Por qué alguien estaría dispuesto a soportar esto? ¿Cuál es el punto de preguntar sobre curiosidades en C ++ o escribir código para demostrar tu valía? ¿Por qué no hacer que la entrevista SE se parezca más a la entrevista con el investigador en la que das una charla sobre lo que has hecho?

¿Cómo son las entrevistas técnicas de trabajo para otros campos, como física, química, ingeniería civil, ingeniería mecánica?

Es relativamente fácil establecer si usted es lo suficientemente competente técnicamente para hacer la investigación: tiene publicaciones que los gerentes de contratación pueden leer y esas publicaciones probablemente sugieren a otras personas con las que pueden hablar para que lo revisen.

La ingeniería de software, por otro lado, es una disciplina tan llena de desperdicios de espacio incompetentes que uno debe hacer mucha diligencia debida para asegurarse de que el tipo que está contratando pueda escribir el código que planea contratar para que escriba.

Saliendo de una rama aquí.

Como investigador con un doctorado, ya ha demostrado a múltiples organizaciones reconocidas su valor y cualidades mínimas como investigador. Defendió con éxito una tesis frente a una junta de sus pares y ha convencido al menos a una publicación revisada por pares para publicar su trabajo.

El desarrollo de software, por otro lado, no tiene estándares de calificación. Las personas habitualmente inflan su base de conocimiento. Como resultado, las entrevistas de desarrollo de software tienen que hacer todo el trabajo que hacen la defensa de doctorado y la revisión por pares en la academia. Te hacen demostrar que realmente sabes de lo que estás hablando.

Considera esto por un momento.

Si intentara postularme para este trabajo de investigador de CS, no vería mi CV / Currículum. No llegaría a una entrevista en primer lugar. Recibía una carta estandarizada de "sin título avanzado" que me decía que ni siquiera estaba calificado para que mi CV fuera examinado.

Mis preguntas son estas: "¿Por qué es tan difícil obtener un doctorado?" Y "¿Por qué necesito un doctorado para ser investigador de CS?" "¿Por qué tantas barreras y obstáculos?"

¿Por qué alguien estaría dispuesto a soportar esto?

¿Cuál es el punto de hacer todo el trabajo del curso y obtener la investigación impresa en revistas y conferencias? ¿Por qué no puedo simplemente investigar y cobrar más de lo que hago por la ingeniería?

¿Por qué confiar en las escuelas de posgrado y publicaciones para establecer credenciales? ¿Por qué no hacer que la entrevista de investigación se parezca más a las entrevistas de SE donde todo depende de lo que pueda recordar en este momento durante la entrevista?

Bueno, tengo una teoría. La investigación generalmente se paga con subvenciones, por lo que el suministro de efectivo es alto. Tienen un montón de dinero para gastar, y solo necesitan encontrar a alguien para gastarlo. Ya sea que realmente logre algo en esa posición o no, la compañía / institución no registra una pérdida neta porque de todos modos solo fue un gasto contabilizado. Hay poco riesgo en contratar a la persona equivocada. El peor de los casos es que tiran todo lo que hiciste.

Por otro lado, el éxito o el fracaso de los productos existentes descansa sobre los hombros de los desarrolladores del día a día. Particularmente si estás en el desarrollo de productos, eres un centro de ganancias para la empresa. Los desarrolladores buenos o malos tienen un gran impacto que va mucho más allá del costo de su salario. Un mal desarrollador en realidad causa daños. Pueden retrasar un equipo, el lanzamiento del producto, etc. Las consecuencias de contratar a un mal ingeniero de software son mucho mayores.

Nuestra compañía también "hace muchas preguntas difíciles" y explicaré por qué. Nos importa si realmente sabe cómo se realiza una llamada de función virtual, pero no porque sea tan crítico para el trabajo que realizará.

En cambio, nos importa porque necesitamos saber qué tan rápido puedes aprender cosas fundamentales. ¿Reclamas X años de experiencia? Bien, haremos preguntas difíciles para saber si tienes un conocimiento sólido.

No sabe cómo se realiza una llamada de función virtual bajo el capó, pero ¿sabe todo sobre la creación de perfiles y la optimización? Genial, es probable que lo contratemos: ha adquirido un conocimiento sólido en un campo y, por lo tanto, seguramente obtendrá un conocimiento sólido en otro.

Reclama X años de experiencia "desarrollando, depurando y arreglando código C ++" y no puede explicar con palabras simples cómo un puntero apunta a un objeto? Lo sentimos, no podemos contratarlo. Si no puede hacerlo, ¿cómo explicará los problemas más difíciles cuando necesitemos tomar decisiones técnicas complejas?

Respuesta corta: hay muchas personas en el mercado que afirman conocer la programación, pero no pueden programar.

Comentario secundario: me sorprende que nadie haya publicado un enlace al ensayo FizzBuzz .

Voy a tomar una ruta diferente y decir que el problema puede no ser tanto que las entrevistas de ingeniería de software sean inherentemente más difíciles, sino que diferentes sectores están buscando diferentes cosas que se muestran en su estilo de entrevista.

Me entrevisté en una amplia gama de sectores (por ejemplo, una empresa nueva, una pequeña empresa, una gran empresa, un departamento interno de TI, una empresa de software, una organización de investigación) y todos tienen una forma diferente de entrevistar que, según he encontrado, suele tender a sigue el siguiente patrón:

• Las nuevas empresas tienden a preocuparse por saber que puede comenzar a escribir código en este momento y puede manejar un entorno de ritmo rápido. Como tal, tienden a preocuparse por la cantidad de información que sabes de la parte superior de tu cabeza, ya que aparentemente no quieren verte pasar mucho tiempo buscando lo que consideran conocimiento "básico". Admitir que no sabes algo puede no ser tan bueno en este entorno si es algo que esperan que sepas.
• Las pequeñas empresas tienden a buscar las mismas cosas que las nuevas empresas en lo que respecta a cuánto sabe, pero no les preocupa qué tan bien maneja los entornos de ritmo rápido (depende del trabajo) y más con qué tipo de habilidades blandas traer y qué tan bien encajará con la compañía.
• Las grandes empresas y los departamentos internos de TI parecen estar más preocupados por garantizar que tenga un determinado estándar de conocimiento técnico, pero no están tan preocupados si no sabe todo de su cabeza ya que anticipan que habrá algunos tiempo involucrado en capacitarlo sobre lo que la compañía espera. Por lo tanto, este es un entorno en el que admitir que no sabes algo pero que estás dispuesto a aprender y estudiar puede verse como un beneficio.
• En el entorno de la investigación (es decir, el apoyo al desarrollo de software para científicos en mi experiencia) tienden a preocuparse si puede escribir software, pero más aún si está dispuesto a hacer lo que sea necesario para asegurarse de que puede aprender lo que está haciendo. no tienen que tomar tu mano mientras intentas resolver un problema. Como también es un entorno de investigación, también parecen interesados ​​en lo interesado que está en aprender cosas nuevas.

Ahora, no mencioné a las compañías de software (es decir, Google, Microsoft), ya que tienden a hacer sus propias cosas y dependiendo de qué tan madura sea la compañía y para qué grupo está entrevistando, están buscando cosas diferentes.

Al final del día, sin embargo, y como con la mayoría de las cosas en la vida, todo depende. Personalmente, he descubierto que algunas empresas se centran mucho en el "conocimiento del libro", lo que podría ser a expensas de poder resolver realmente los problemas de nivel superior, mientras que otras empresas parecen estar muy preocupadas por lo bien que manejan los problemas de nivel superior. (es decir, puede diseñar un esquema para x ) y operar bajo el supuesto de que están dispuestos a invertir de tres a seis meses para que esté completamente actualizado antes de que sea completamente productivo.

Soy un desarrollador de software (c / c ++) con más de 20 años en el campo. El tipo de entrevistas que habitualmente vemos ahora (los acertijos, la implementación de estructuras de datos, algoritmos de búsqueda, etc. en la pizarra) no solía ocurrir mucho, excepto para los recién graduados. Si una persona trabajaba para una empresa de buena reputación durante un período de tiempo razonable, eso se consideraba una prueba de su capacidad para escribir código. Ahora se ha vuelto muy escolar y no estoy seguro de por qué. Realmente, las cosas típicas que le piden que codifique, PUEDEN ser memorizadas, por lo que hacerlo en la pizarra realmente no prueba nada. En un proyecto de trabajo, usaría Internet para investigar algo y no escribiría btrees o listas vinculadas desde cero.

Creo que es otra moda de gestión, al igual que Scrum, con esta probablemente iniciada por Google, Amazon y Microsoft. Todos los demás copiaron tal como lo hicieron con el rango y el tirón de Jack Welch ... ¿recuerdas a GE?

Si usted es un gerente de contratación que lee mis comentarios, lo que DEBE preguntarles a los candidatos es CÓMO harían para resolver ciertos problemas. En lugar de pedirles que codifiquen una tabla hash, denles un problema relacionado con una tabla hash y pregúnteles cómo la resolverían.

¡También estoy de acuerdo con el desarrollador que aparece arriba de esta publicación que dijo: "¡Dadles un problema del mundo real que la empresa tuvo que resolver"!

"pero tendería a bombardear las preguntas de OOP / Herencia. ¿Por qué? Porque una vez que se agregó soporte para plantillas, he usado C ++ casi exclusivamente para la programación genérica".

También estoy de acuerdo con lo anterior. Cuando trabajas para una empresa, escribes el código A SU MANERA. A veces todavía me cuesta recordar la llamada de C ++ por sintaxis de referencia porque el arquitecto principal de la empresa para la que trabajé durante 15 años prefería usar punteros, no referencias. Era un viejo programador de C, ya ves. Eso es lo que todos usamos.

Nuevamente, las entrevistas tecnológicas son arbitrarias y caprichosas.

Hay una gran diferencia entre interrogar a una persona por las minucias o ver si conocen su CS. Como dije anteriormente, tengo más de una década de experiencia con C ++, pero tendería a bombardear las preguntas de OOP / Herencia. ¿Por qué? Porque una vez que se agregó soporte para plantillas, he usado C ++ casi exclusivamente para la programación genérica .

Me entrevisté con varias compañías de BigHouseHoldNameTech en el área de la Bahía y Seattle, y una de las mejores entrevistas involucró preguntas reales con las que tuvieron que lidiar en el trabajo, involucrando estructuras de datos y algoritmos [es decir: tiene 300 mil millones de puntos de datos que consiste en XYZ. ¿Cómo almacenar y buscar eficientemente? ]

Eso te permite saber cómo un candidato podría intervenir y ayudarte a resolver los problemas reales que estás enfrentando. Lo peor fue también con otra compañía de BigHouseHoldNameTech, pero le hicieron horas de preguntas increíblemente arcanas que realmente debería buscar en un manual [ es decir, describa las principales diferencias entre la PCB en Windows frente a Linux, y esto no fue así ''. t para una posición de nivel de kernel ]

Los fondos de cobertura son extraños con su intención de torturar ... espere 8 horas para resolver problemas de tipo mochila en una pizarra.