¿Es aconsejable preguntar sobre las decisiones de diseño tomadas en un producto durante una entrevista? [cerrado]

He estado pensando en las preguntas de la entrevista últimamente y he estado reflexionando sobre las malas experiencias que tuve en el pasado. Una nota particular es cuando le pregunté al entrevistador por qué el equipo eligió usar EJB 3 durante la primavera en su producto. El entrevistador casi me arrancó la cara, gritando "Debido a que Spring no es el principio y el fin de todo el desarrollo de software Java, ¿quieres este trabajo o no?". En respuesta a esto, le dije que probablemente este no era el trabajo para mí y rápidamente salí de la entrevista.

Al principio de la entrevista, me informaron que la compañía tenía una alta rotación de personal, el producto que estaban trabajando se creó inicialmente en Modula-3, luego se transfirió a Perl y finalmente a Java. Me entregaron un folleto de 10 páginas de preguntas técnicas sobre Java, EJB, SQL y JDBC y me hicieron preguntas sobre las pilas de tecnología con las que he trabajado. Cuando se me solicitó hacer preguntas, sentí que era razonable preguntarles acerca de su tecnología y obtener respuestas razonables, no enviar al entrevistador a las llamas.

Pregunta: ¿Es una buena idea investigar las opciones arquitectónicas tomadas en una entrevista? Si no, ¿por qué?

Desde mi propio punto de vista, una entrevista es un proceso bidireccional. Si los entrevistadores me ponen a prueba en mis habilidades técnicas, tengo todo el derecho de hacerles las mismas preguntas para:

1) Averigüe cuál es su mentalidad y actitudes hacia el desarrollo de software. 2) Determinar si su enfoque está en línea con cómo abordaría problemas de ese tipo.

Es posible que el entrevistador que se enojó tuviera malas habilidades para la entrevista y olvidó que una entrevista es un intercambio de ida y vuelta. Si me hubieran preguntado esto, habría dado una respuesta razonable, pero ciertamente no habría tratado de poner a un entrevistado en un estado de capitulación mansa donde la cabeza se balancea de arriba abajo sin ninguna conversación.

Personalmente, encuentro que entrevistar a las personas es casi tan agotador y estresante como ser entrevistado. Pero eso es porque estoy de acuerdo con usted en que el proceso de la entrevista es un intercambio bidireccional.

No me importa lo bueno que seas, no quiero contratarte si no vas a ser feliz trabajando allí. Es un juego costoso para jugar. Por lo tanto, quiero responder cualquier inquietud que pueda tener y mostrarle el equipo y el producto tal como son, para que pueda tomar una decisión informada.

Cuando busco trabajo, quiero trabajar con alguien que comparta esa actitud. E, incluso si sospecho que sé las respuestas a las preguntas, les preguntaré solo para ver la reacción. La agresión nunca es una señal de que alguien se sienta cómodo con una situación.

No miento en una entrevista, a ambos lados del escritorio, porque piensan que están contratando a alguien diferente / van a trabajar a otro lugar. Y espero lo mismo a cambio, de la persona al otro lado de la entrevista.

Desafortunadamente, eso significa que ocasionalmente me encuentro con entrevistas como la que describiste. ¿Son experiencias horribles? Si. ¿Salgo de allí sabiendo exactamente dónde salió mal la entrevista? Si.

¿Pero estoy muy seguro de que cada experiencia horrible hubiera sido considerablemente peor si hubiera conseguido el trabajo o contratado a la persona equivocada? Oh sí.

Sí, está bien preguntar si eres realmente curioso y si la respuesta es importante. Creo que preguntar muestra que entiendes que hay más de una forma de hacer las cosas, y muestra que estás interesado en cómo se escribió el software.

Dicho esto, debes tener mucho cuidado al formular la pregunta y ser doblemente cuidadoso sobre cómo continúas la conversación. Es fácil parecer desafiante en sus decisiones. Lo último que desea es que el entrevistador crea que cree que es más inteligente que ellos. Si eres realmente curioso, pregunta. Si crees que hicieron una mala elección, mantén la boca cerrada.

Si hubiera estado en la situación descrita en la pregunta, en lugar de salir podría haber dicho algo como "oh sí, estoy de acuerdo en que la primavera definitivamente no es la solución correcta para todo. ¡Gracias por informarme un poco sobre su arquitectura! Siempre estoy buscando información sobre cómo elegir las herramientas adecuadas ". (sin embargo, su pregunta es extraño - le preguntas por qué eligieron la primavera, y se eligió porque era no el todo final de todo?)

Como alguien que frecuentemente entrevista a personas, personalmente agradecería una discusión sobre por qué se hicieron elecciones particulares de tecnología o diseño, qué haríamos de manera diferente ahora si tuviéramos el lujo de los recursos o comenzáramos un nuevo proyecto. En general, lo veo como una señal de que alguien se preocupa por su oficio, y a menos que sus dogmas y los nuestros no sean compatibles, probablemente calificaría a ese candidato más que a alguien que solo responde preguntas técnicas de manera competente.

Actualmente estoy trabajando en un proyecto para un cliente que tiene un legado de algunas decisiones arquitectónicas bien intencionadas pero mal implementadas, y los candidatos que expresan curiosidad sobre el mundo tal como es, y el camino a seguir tal como lo vemos, generalmente son tipos de personas con las que nos gustaría trabajar. Queremos personas que puedan realizar la debida diligencia y validación apropiadas en las decisiones de diseño e implementación de nuestro equipo. Generalmente valoramos a las personas que aportan algo a la mesa que no tenemos, o que no tenemos suficiente.

Cuando he sido candidato en una entrevista, tomo cualquier signo de hostilidad o actitud defensiva cuando este tipo de discusiones suceden como una mala señal, ya que una organización que no es capaz de autoexamen generalmente también se encuentra en un proceso tecnológico y de confusión. son incapaces y probablemente no están dispuestos a salir. Si no veo motivación para la mejora continua en el equipo existente, hay una buena posibilidad de que no sea feliz allí.

que se acostó con un vendedor de Oracle una vez y decidió que todo el desarrollo futuro se realizará utilizando los servicios web Java 1.4, Oracle ERP y una interfaz de Borland C ++ con componentes de GUI de terceros en su mayoría descontinuados y preferimos gastar $ 60,000 al mes en tapar agujeros para mantener a los clientes desde saltar el barco que revisar cualquier decisión y hacer mejoras permanentes que podrían traer nuevos ingresos si tenemos suerte. No muevas el bote, ¿qué te pasa?

Suponiendo que se encuentre en un área con otros trabajos tecnológicos, o que esté dispuesto a mudarse, es probable que tenga el lujo de elegir. Ningún concierto es perfecto, pero quieres trabajar con personas que quieran trabajar contigo. (Me preocupa más esto que las opciones tecnológicas específicas la mayor parte del tiempo). Si algo huele mal, probablemente lo sea.

Así que sí, pregunta lejos. Cuanta más curiosidad sobre nuestro negocio, nuestro proceso y nuestro diseño, más en serio es probable que tome un candidato. Pero no trabajo en una tienda de Blub, así que no puedo decir si te ayudará a conseguir un trabajo de Blub. Solo puedo decir que funcionaría para usted si desea trabajar con otras personas que se preocupan por su oficio.

Pregunta: ¿Es una buena idea investigar las opciones arquitectónicas tomadas en una entrevista? Si no, ¿por qué?

Está absolutamente bien, lo vería como algo positivo.

Si su entrevistador no puede manejar eso, dice mucho sobre ellos, no usted.

Me preocuparía si un junior NO estuviera interesado en las decisiones de diseño, mostraría una falta de curiosidad / interés en el área temática y no muestra ningún deseo de mejorar.

Soy de la mentalidad es esencial . He trabajado en demasiados trabajos con decisiones de diseño sin sentido, ya sea porque nadie sabía nada mejor, no le importaba aprender, o había un mandato de la gerencia para usar lo que el CEO leyó en una revista / vio en línea / tenía a alguien dígale que fue la "próxima gran cosa" sin ninguna consideración de alternativas. Estos trabajos eran todos lugares miserables para trabajar.

No necesariamente debe criticar una decisión de diseño a menos que sea algo que escupe frente al sentido común o simplemente suene como una locura, pero es común cuestionar cosas que parecen "desagradables" para descubrir si hay una razón heredada o algo que surgió eso facilitó la necesidad de utilizar un enfoque poco ortodoxo.

Hacer preguntas como esta también tiene el efecto de medir el interés de la compañía en la mejora y la competencia. Como alguien más dijo anteriormente, es una cosa si obtiene una respuesta como (No sé Java pero uso .NET, así que usaré ejemplos .NET) Cuando escribimos la aplicación no había ORM maduros, por lo que usamos procedimientos almacenados con una capa de puerta de enlace de datos. Nos gustaría pasar a Entity Framework en el futuro y otra cosa por completo para obtener una respuesta como Solo usamos procedimientos almacenados. Entity Framework parece aterrador y puede requerir trabajo para refactorizar, y no podemos refactorizar nada porque el CEO tiene una larga lista de nuevas características en las que quiere que trabajemos, y si pasamos el tiempo mirando Entity Framework nos despedirá por perder el tiempo. Uno indica comprensión y un deseo de mejorar, el otro indica un entorno mediocre en el mejor de los casos en el que todos hacen lo mínimo para sobrevivir.

Una compañía que se ofende al cuestionar sus decisiones o querer discutir por qué eligieron usar el Producto A en lugar del Producto B está jugando su mano y mostrando que no quieren un libre pensador sino un dron que no cuestionará, y lo más probable es que no sea el tipo de empresa para la que un desarrollador competente quiera trabajar.

respuesta: es una buena idea preguntar sobre la toma de decisiones arquitectónicas. Pero debes tener cuidado de cómo haces esas preguntas.

En pocas palabras: debe preguntarse " ¿Cómo hizo para elegir la tecnología X sobre la tecnología Y? ".

Desea expresarlo de una manera que comunique que generalmente está interesado en el proceso de toma de decisiones dentro del equipo. Nadie querrá repasar cada decisión heredada que la compañía haya tomado con un candidato.

Cuando preguntas " ¿Por qué elegiste la tecnología X sobre la tecnología Y? ", Puede ser que no estés de acuerdo con su decisión (lo cual está bien ... pero puede ser tomado como hostil) o que quieres alardear de cuánto Conozca las tecnologías en cuestión (lo que sería molesto para cualquiera), a pesar de sus buenas intenciones.

Me gusta pedirle a un entrevistador que me cuente sobre una decisión de diseño fallida que tomaron y lo que se hizo a continuación. Esto le da algunos buenos datos:

1. Si el jefe no puede admitir ningún error de forma o falla temporal, es probable que no quiera trabajar para ese jefe.
2. Puede saber cómo la empresa maneja una situación estresante.

Puede que no sea popular, pero siempre tengo un gran respeto por los gerentes con las piedras para reconocer que un proyecto va a fallar y matarlo para dejar de malgastar dinero, o que algo va en la dirección equivocada y necesita ser asesinado o reiniciado .

En última instancia, si habla de satisfacción laboral, la tecnología (lenguaje / plataforma / compilador / lo que sea) no importa tanto como las personalidades involucradas y el entorno laboral.

Hace unos años, estaba en una entrevista y me hicieron varias preguntas técnicas sobre un lenguaje de programación ... que no había hecho bien (60/40 correcto / incorrecto). La discusión pasó al proyecto que tenían a mano y comencé a hacer preguntas sobre el diseño y luego señalé un par de problemas y limitaciones que presentarían.

Me ofrecieron el trabajo al día siguiente. Lamentablemente no pude retomarlo por razones personales.

Hacer preguntas sobre el diseño no debería ser un problema si son preguntas inteligentes, especialmente si puede relacionarlas con su negocio.

No he hecho muchas entrevistas, pero, por su experiencia, concluiría:

a) Está bien si desea tomar una decisión informada sobre si desea el trabajo;

b) No está bien si ya decidió que quiere el trabajo.

Las personas pueden ofenderse fácilmente por las preguntas benignas sobre sus elecciones. Ese es un rasgo terriblemente malo, pero común.

Aquí hay algunos consejos

1. Preguntar por qué eligieron alguna solución existente podría ser una mala pregunta, porque probablemente el equipo de desarrollo no tuvo la oportunidad de cambiarlo o elegirlo.
2. También es probable que el equipo ya sepa por qué la tecnología no era la mejor opción
3. Pero desafortunadamente, lo último que necesita cualquier equipo de desarrollo es que las personas intenten cambiar la arquitectura o cuestionen las elecciones que se tomaron hace 10 años: da la impresión de que su tecnología ya es un legado antiguo y que los mensajes que circulan en el equipo pueden hacer que los desarrolladores estén descontentos sobre la situación actual
4. Por lo tanto, en una entrevista, lo último que debe hacer es dar la impresión de que se va a quejar todo el tiempo sobre las opciones sobre las que el equipo no tiene control