¿Cómo puedo responder a lo que fue desafiante en mi último papel sin arruinar mis posibilidades? [duplicar]

Estoy tratando de encontrar una respuesta decente a esta pregunta de la entrevista: '¿qué fue lo más desafiante de mi último papel?'

Básicamente fui un mono de widgets de interfaz de usuario durante más de un año en la empresa con muy poco aprendido además de ReactJS. Estaba en un equipo de 4 desarrolladores. Fuimos contratados para arreglar un lío totalmente roto de un mal proyecto de subcontratación.

Aprendí mucho sobre ReactJS, JavaScript, estándares de estilo de código, estándares de calidad de código, pero eso es todo y estaba aburrido hasta las lágrimas después de 6 meses. No fue un buen ajuste. No se me permitió tomar casi ninguna decisión independiente, o si lo hiciera, probablemente tendría que volver a hacerlo en un momento posterior, o enfrentar críticas sobre cómo lo hice. Pero si tratara de hablar de ello en el momento en que surgiera, algunas personas se molestarían porque no pudiera tomar una decisión o tendría que esperar nuevas especificaciones y cambiar de marcha. Fue realmente agotador. Nunca sentí que mis sugerencias fueran tomadas en serio.

Lo que encontré desafiante:

  1. No tenía ningún conocimiento de dominio. Esto hizo que sea difícil ofrecer sugerencias o mejoras a la interfaz de usuario.
  2. No conocía ninguna de las tecnologías necesarias. No conocía JavaScript, ReactJS, SASS, Gulp, Webpack ni ninguno de los ecosistemas modernos de JS. Me arrojaron al fondo y tuve que aprender. Aprendí rápidamente y comencé a programar muchos widgets.
  3. A menudo me encontraba en esta situación: comenzaba a trabajar en una función, solo para encontrar 2/3 del camino que los casos extremos no estaban especificados y tenía que parar, hablar con el gerente del proyecto, esperar sus nuevas especificaciones y, a continuación, inicie una nueva función. Cambiar constantemente de marcha era agotador, ya que tendría que comprender lo que estaba haciendo antes de sumergirme en la siguiente tarea. Era difícil ser eficiente y escribir código de la más alta calidad en estas situaciones. Fue difícil invertir tanto tiempo en una función y luego tener que dejarla y cambiar de marcha ese mismo día.
  4. A menudo me encontraba en esta situación: encontraba un problema de patrón de diseño/problema de rendimiento y lo discutía con los desarrolladores senior. Charlábamos al respecto, pero luego descubrí que siguieron adelante y lo implementaron, por lo que nunca tuve la oportunidad de participar en algo así a un nivel significativo.

Algunas cosas desafiantes en las que trabajé pero que no tuve la oportunidad de hacer solo:

  • validación
  • problemas de desempeño

Cosas que hice solo pero que no pensé que fueran las partes más desafiantes de la aplicación:

  • preferencias del usuario (especificaciones complicadas con muchas permutaciones)
  • permisos (especificaciones complicadas con muchas permutaciones)
  • formulario de pedido (especificaciones complicadas con muchas permutaciones)

Rendimiento frente a patrón de diseño frente a capacidad de mantenimiento Dado que teníamos muchos widgets ReactJS anidados, a veces los componentes principales solo transmitían datos a los componentes secundarios. Si usa este método junto con shouldComponentUpdate, el código puede volverse imposible de mantener, aunque probablemente sea la mejor manera de manejar el problema. La solución fue usar el contexto o crear otras vistas de la interfaz de usuario como "proveedores de datos". No se me ocurrió la solución final, pero identifiqué el problema y lo discutí con los desarrolladores senior.

Los desarrolladores senior me dijeron que los permisos eran la parte más complicada de la fase 1 del proyecto, pero no me pareció un desafío. Fue principalmente un poco de pensar en algunas especificaciones complicadas y luego trabajo pesado.

¿Qué respuesta puedo dar?

No, busco una respuesta específica a mi situación y no genérica.
@AudraQuinn contempla la ley no dicha de SE: "todo es un duplicado hasta que se demuestre lo contrario"
Además, SE tiene que ver con respuestas genéricas que pueden ayudar a tantas personas como sea posible. No una persona específica.

Respuestas (2)

Puede interpretar "desafiante" de dos maneras: una es hacer una lista de las cosas que le resultaron difíciles y espera no tener en el nuevo trabajo, y la otra es hacer una lista de las cosas en las que mejoró a lo largo del trabajo. No recomiendo mezclar y combinar estas dos posibles definiciones. En su lugar, elija uno, dígale al entrevistador la definición de desafío que está usando y luego enumere algunos, una oración cada uno.

Si vas por el primer camino:

Varias cosas en mi trabajo actual son frustrantes, y esa es una de las razones por las que estoy buscando uno nuevo. Un patrón que ocurría con frecuencia era que se le pedía que comenzara antes de que se tomaran todas las decisiones y tener que rehacer el trabajo más tarde cuando se comprendían completamente las especificaciones. Otro fue encontrar problemas de rendimiento pero no poder participar en la implementación de las correcciones. Espero que en este puesto los equipos compartan información y [cualquier otra cosa que desees es diferente con este trabajo].

Si vas por el segundo camino:

Cuando comencé, no sabía mucho sobre ReactJS, JavaScript, estándares de estilo de código o estándares de calidad de código, así que aprendí mucho durante el tiempo que estuve en esa posición. Ahora siento que yo [declaración fuerte sobre saber mucho o ser sólido en la tecnología que pide el nuevo trabajo].

Observe cómo en cada caso:

  • no dices "fue un reto" porque es ambiguo: aclaras lo que vas a describir
  • mantienes las quejas, o la lista de lo que no sabías o no podías hacer, agradable y breve
  • cierras con una fuerte transición que dice "Quiero que este trabajo tenga X" o "Soy realmente bueno en Y". Casi todas las preguntas que le hacen en una entrevista deben incluir una de estas dos declaraciones, cada vez.

El énfasis al responder esto debe estar en cómo superó ese desafío. Elige cualquier desafío que te permita hacer eso.

Yo me quedaría con el n.° 1 o el n.° 2. Asumiendo, por supuesto, que realmente adquirió el conocimiento del dominio y aprendió JavaScript y otras tecnologías, probablemente querrá hablar sobre cómo lo hizo; si elige el n. ° 2, quédese con "Me arrojaron a la parte más profunda, y pude nadar".

No digas algo como "No tenía ningún conocimiento del dominio, por lo que no pude hacer sugerencias de la interfaz de usuario". Solo menciónalo si, de hecho, superaste ese desafío (es decir, aprendiste el conocimiento del dominio).

Recomiendo encarecidamente evitar los números 3 y 4 porque suena como si estuvieras hablando mal de tu antiguo empleador, lo que generalmente se considera poco profesional y tiende a ser un gran desvío (porque luego se preguntarán qué es lo que estás haciendo). diré sobre ellos cuando finalmente te vayas, además de que puedes parecer un llorón).