¿Cómo manejar las pruebas técnicas de la entrevista que son absurdas (por ejemplo, una tarea irrazonablemente grande con un límite de tiempo corto)?

Alejándose de ellos.

GS (Goldman Sachs) una vez quiso una pequeña muestra de código de mí, que se redujo a un simulador de libro de pedidos de intercambio. Nada demasiado particular, EXCEPTO que especificaron una cobertura de prueba completa y CALIDAD DE CÓDIGO DE PRODUCCIÓN. Para algo tan crítico se reduce a una semana de trabajo probando cada caso de borde, porque este tipo de código es extremadamente crítico.

Envié al reclutador una oferta y le dije que si no pagan - no hay juego.

Algunas compañías tienen ideas estúpidas y hacen pruebas ridículas. Tu ejemplo es similar, no hay una maldita forma de hacerlo en 2 horas sin tenerlo ya preparado. Me atrevo a decir que esto es un fraude dudoso. Es probable que sea sólo un signo de incompetencia cómica.

Recuerda que esto es IT - y IT es un mercado de vendedores. Toneladas de trabajos, sin especialistas. Compórtese así. No trates con idiotas. Rechazo cualquier trabajo de codificación sin entrevistas PREVIAS, porque hay otro lado: Todos esos proyectos “interesantes y desafiantes” son igual de estúpidos una y otra vez. Quiero saber primero si quiero perder mi tiempo, porque me encanta hacer proyectos que me gustan, y los reclutadores no tienen ni idea de lo que son los proyectos hoy en día.

Recuerde, cuando una compañía lo entrevista, usted también los entrevista a ellos.

Use las pruebas de inane como una herramienta de selección.

Si la TEST le da metas y plazos poco razonables, adivine lo que puede esperar en el trabajo.

No lo tome como algo personal, una mala prueba no es un indicador útil de sus habilidades. Si dicen que tu trabajo no fue lo suficientemente bueno, y sabes que lo fue, entonces obviamente tampoco te apreciarán en el trabajo.

De nuevo, no eres tú, son ellos.

La retrospectiva es 20/20. Esto es lo que deberías decir la próxima vez:

“Como regla general, no hago ninguna tarea para llevar a casa a menos que hable con el cliente primero.”

“¿Es usted el cliente? No, entonces conécteme con el gerente de contrataciones del cliente. Y no, si trabajas para RRHH (no eres el cliente a menos que quieras que construya una aplicación relacionada con RRHH).”

“Ok, ¿qué hace esta persona para tu empresa? ¿Será la persona a la que informaré si su empresa me contrata? Bien, sí. Quiero hablar con esa persona.”

Una vez que finalmente hablas con esa persona, entonces dices algo como:

“Ok, ¿has leído mi currículum?

Suponiendo que el director de contrataciones no quiera saltárselo, entonces podrías decir:

"El problema es que ya me han quemado antes.

Para empezar, no sé si debería construir el proyecto desde cero, o simplemente reutilizar algo del código que tengo por ahí”. Una vez, construí el proyecto desde cero en un par de horas, pero fui criticado por no tener una aplicación lista para producción.

Y otra vez, hubo un pequeño desajuste en la versión, y su IT no supo cómo ajustar el archivo de configuración para hacer que mi proyecto funcionara.“

Pero hagas lo que hagas, no le des esta explicación al reclutador. No le expliques y no te justifiques ante el reclutador. Es inútil tratar de explicarte a un guardián de la puerta. Cuanta más información le des a un guardián, más probable es que use esa información en tu contra, ya que por diseño, un guardián rara vez tiene el poder de hacer concesiones, pero por otro lado, su papel es más bien buscar razones para descartar candidatos.

Así que asumiendo que has estado hablando con el verdadero tomador de decisiones, el gerente de contrataciones al que estarás reportando, y asumiendo que estás recibiendo buenas vibraciones de esta persona, podrías decir:

"Ok, estoy dispuesto a hacer el proyecto para llevar a casa, pero prefiero estar ahí cuando mi proyecto sea instalado y evaluado.

¿Crees que podríamos establecer un momento en el que yo pueda entrar con mi código y podamos configurarlo juntos en una de las máquinas de tu desarrollador? ”

“¿Qué tal el próximo miércoles? […] ¿Estarás allí? ¿Estará uno de los desarrolladores también? ”

Pero de nuevo, sólo hazlo si recibes buenas vibraciones de esta persona. Confía en tus propios sentimientos. Si por alguna razón, sientes que están usando este proyecto para llevar a casa como una forma perezosa de seleccionar muchas docenas de solicitantes. O si por alguna razón, sientes que están tratando de extraerte algo de trabajo gratis, para que lo pongan en producción, no aceptes la tarea.

Lo mismo pasa si apareces y no quieren instalar/revisar tu proyecto cuando estés allí. Si quieren que hagas sus deberes, tienen que invertir algo de tiempo en ti también. Es una muestra de respeto mutuo.

Y si por alguna razón, no estás recibiendo ese respeto. Por ejemplo, si cambian al ingeniero, se supone que te reunirás con una persona de RRHH en el último minuto. Sea educado, pero sea firme. No les des tu proyecto para llevar a casa. Diles que estarás encantado de reprogramar la entrevista y marcharte.

No me gusta referirme a otras respuestas en mis respuestas, ya que las respuestas deben poder ser entendidas por sí mismas. Sin embargo, la respuesta más votada se reduce básicamente a “La compañía es una manada de idiotas”. Huye de ellos". Esto no le da a la OP nada que mejorar sobre sí misma, y nada que cambiar en el futuro. Veo áreas que el OP podría mejorar, independientemente de si la compañía ha hecho algo malo o no, que nosotros como encuestadores no sabemos realmente, ya que sólo hemos escuchado un lado de la historia.

Hasta donde puedo ver, no se comunicó antes de comenzar la tarea que creía firmemente que no se podía hacer en dos horas.

Esta es la secuencia de eventos como yo lo veo:

1. Se le pidió que completara un desafío de codificación
2. Cuando recibiste el reto, en lugar de comunicar tus preocupaciones, empezaste a codificar
3. Te apresuraste en el desafío, tomando atajos
4. Presentaste un proyecto de baja calidad que no funcionó sin muchos retoques
5. Después de recibir la retroalimentación, comenzaste a justificar tu trabajo

Así es como imagino que la compañía lo vio:

1. El candidato aceptó todas las condiciones del desafío
2. El candidato presentó el proyecto a tiempo
3. El proyecto no funcionó
4. Nuestro desarrollador principal dijo que el código era de muy mala calidad
5. El candidato comenzó a inventar excusas para su trabajo

Imagina que estás en una situación de trabajo y tu jefe/jefe de equipo te pide que completes una tarea en una cantidad de tiempo irrazonable. Si no comunicas inmediatamente que no puedes hacer tanto trabajo en tan poco tiempo, entonces cualquier fracaso es tu culpa por aceptar las condiciones iniciales. Tú eres el experto, no ellos, y ellos confían en ti para comunicarse con ellos.

No puedo enfatizar lo importante que es que ambas partes tengan un entendimiento común de la situación. Tenías una brecha insuperable de entendimiento porque perdiste la oportunidad de abordarla. La próxima vez que tengas un problema, comunícalo inmediatamente o la otra parte pensará que todo está bien. No comunicar información importante es mentir por omisión, y cualquier forma de mentir es poco profesional. Cómo reaccionan a la información es su responsabilidad, no la tuya.

Recomiendo leer El Codificador Limpio: Un código de conducta para programadores profesionales por Robert C. Martin (Tío Bob), en particular:

• Capítulo 2: Decir No
• Capítulo 3: Decir Sí
• Capítulo 10: Estimación
• Capítulo 11: Presión

Si la empresa rechaza tu solicitud porque pediste comentarios y aclaraciones antes de comenzar la tarea, no te han filtrado, tú los has filtrado como una empresa para la que no quieres trabajar.

He encontrado algunas pruebas inteligentes y algunas pruebas estúpidas (SQL/BI) y he salido activamente de una que era estúpida, explicando que lo que querían era el enfoque equivocado.

También he visto pruebas que eran en realidad intentos de un proyecto libre, con “trabajo de muestra” que era esencialmente una nueva solución. De nuevo, me negué a completarlas.

Sucede, lo atribuyo a la experiencia y sigo adelante. Siempre programo las entrevistas para después de las horas de trabajo, así que no hay ninguna pérdida real de mi parte.

Bueno, les dices exactamente lo que le dirías a tu jefe si te enfrentas a esa tarea.

O bien no saben lo que hacen, entonces aprenderás mucho sobre la empresa, o quieren ver que no pierdes el tiempo (el dinero de la empresa) haciendo las cosas mal en lugar de hablar con la persona sin los conocimientos técnicos para juzgar esto.

Hay dos resultados, pasas con éxito por hacer lo correcto, o has esquivado la bala y no tienes que volver en dos meses diciéndonos cómo tu jefe exige cosas imposibles ;)

Este es mi enfoque:

1. Comunique a su contacto en la compañía que no cree que sea posible en el tiempo, y lo que planea hacer realmente.

2. Si hay tiempo para esperar una respuesta, espere; si no, haga lo que pretende, y documente sus elecciones en detalle

3. 1. Idealmente, esboza dónde llevarías el resto.

Ten en cuenta que muy pocos entrevistadores realmente calibran y prueban que una tarea lleva 2 horas. Si realmente quieres el trabajo, llévalo a algún nivel de completitud en un tiempo determinado.

Como has descubierto, la calidad normalmente triunfa sobre la adecuación al tiempo, a menos que tengan mecanismos estrictos para asegurar que todos los candidatos encajen en el tiempo.

Esto apesta a falso test para mapear tu personalidad, especialmente como manejas eventos absurdos y estresantes. ¿Eres de los que

1. se molestan y se van o
2. el que intenta silenciosamente resolverlo o
3. intentan discutir y explicar con la dirección qué cosas son irrazonables o
4. se estresan tanto que no saben qué hacer o
5. eres de los que pretenden intentar resolverlo pero devuelven resultados inventados igualmente absurdos porque eso es exactamente lo que cualquiera que se plantee una tarea así se merecería?

En mi opinión experta, nadie diría que esto es como dos horas de trabajo, si se hace bien. Yo pondría unos días al menos para hacer la arquitectura correcta, etc.

Disculpe, pero está perdiendo el punto.

Piense en esto desde la perspectiva del equipo. Quieren a alguien que esté familiarizado con todo el ASP.NET, MVC, REST, hablar con una base de datos, y la característica moderadamente avanzada de un cuadro de texto autocompletado.

¿Podría Yo hacer estas cosas? Sí, eventualmente. Después de todo, he oído de todas estas cosas, así que podría seguir adelante y enumerarlas en mi currículum. Un experto como tú podrá armar un sistema de trabajo bajo el límite de tiempo porque lidias con esta pila todo el tiempo, pero yo tendría que pasar horas escarbando en los manuales.

Un currículum es un pedazo de papel donde listar las viñetas es trivial. Una mala contratación es peor que ninguna contratación. Asumo que no tuvo una recomendación personal de alguien del equipo, así que el gerente de contratación está buscando una demostración de competencia. Es cierto que un sistema real listo para la producción llevaría mucho más tiempo, pero la prueba no pedía listo para la producción porque preguntaba qué habrías hecho con más tiempo. El éxito en la prueba demuestra que se domina todas las capas y, lo que es más importante, que se sabe cómo priorizar. Hazlo funcionar y entonces ¡hazlo bonito!

Una prueba de dos horas no es el momento para la arquitectura astronáutica.

Por otra parte, casi seguro que no eres el primer candidato a ver esta prueba. El equipo ha usado y quizás ajustado su filtro varias veces, y al menos un desarrollador ha pasado. Levantar la nariz, como se ha puesto de moda en los últimos años, en justa indignación o “educarlos” sobre por qué es una mala prueba te pondrá, en su opinión, en la categoría de bozo. Pensarán: “Otro aplazamiento o primadonna con la que no tenemos que lidiar”. Míralo desde la perspectiva de tu cliente potencial. En lugar de descartarlo como absurdo, déle el beneficio de la duda. Para una prueba de dos horas anote brevemente sus suposiciones, haga el caso de los días soleados para el simple trabajo de demostración, y en el tiempo restante documente cómo haría un sistema real robusto.

Como otras respuestas han insinuado al menos, la motivación detrás de la prueba podría ser razonable, particularmente si la prueba:

1. Está bien adaptada a los requisitos del trabajo _real;
2. Es una prueba de la que no se puede prescindir. Minimiza los elementos menos importantes;
3. No es claramente un intento de conseguir “trabajo gratis”; y posiblemente
4. Viene con al menos algunas pistas sobre lo que los revisores están “buscando”.

En un trabajo anterior, diseñé y administré una prueba de programación discutiblemente “absurda”. El trabajo siempre fue un trabajo de nivel superior de desarrollador de pila completa de ASP.NET/SQL Server, y la tarea implicaba crear una aplicación web muy básica que implicaba una página y dos o tres procedimientos simples almacenados. El candidato realizaba la prueba in situ utilizando herramientas estándar:

1. Visual Studio (versión de la elección del candidato dentro de las dos o tres versiones anteriores);
2. SQL Server Management Studio; y
3. Un navegador web, no sólo para la prueba sino también para buscar documentación, recursos, etc, lo cual le dije específicamente a los candidatos que estaban permitidos a hacer.

Proporcioné al candidato una solución “shell” básica (en cada una de las versiones permitidas de Visual Studio), y creé la base de datos y las tablas con antelación.

Le di al candidato una descripción de una página y le dije que volvería en diez minutos para responder a cualquier pregunta al respecto, después de lo cual tendría una hora para completar la tarea.

Cuando volví después de diez minutos, después de contestar cualquier pregunta, le dije a la candidata que si no estaba segura de poder terminar cada parte de la tarea en una hora, podría considerar concentrarse en la parte de la tarea que podría completar y ponerse en marcha en el tiempo asignado. También mencioné que si tenía más preguntas durante la hora, podría encontrarme a dos cubículos de distancia y preguntar.

Como escribí el examen, podría completarlo de principio a fin en unos cuarenta y cinco minutos. No esperaba en absoluto que los candidatos completaran todo el examen en una hora. El límite de tiempo “absurdo” estaba establecido por tres razones:

1. Queríamos ver si el candidato tenía una comprensión razonable de los requisitos del trabajo. Recuerden, esto era para un puesto de nivel superior. (Más de la mitad de las veces, la respuesta fue “no”)
2. El candidato debe ser capaz de analizar los requisitos básicos y dividirlos en tareas manejables y discretas.
3. Extender la prueba más allá de una hora le tomaría más tiempo al candidato sin darnos mucha, si es que la hay, información adicional.

Al final de la hora, le pedí al candidato que me mostrara lo que tenía, si tenía alguna parte de una solución en marcha que demostrar, etc. Generalmente nos tomaba unos cinco minutos repasar el trabajo en este punto, luego el candidato tenía una entrevista personal con el gerente. Durante esa entrevista, el equipo de desarrollo miraría lo que el candidato había presentado. Nosotros realmente esperábamos esta tarea porque nunca era aburrida.

Si el candidato tenía una solución en marcha que manejaba su parte prevista de la tarea general, el candidato casi seguro que pasaba esta fase de la entrevista. Incluso si la solución no se ejecutó todavía, si pudiéramos ver progresos sustanciales y pruebas de la competencia del candidato, normalmente seguiríamos considerando al candidato. Siempre comprobamos el historial del navegador del candidato para ver a qué recursos accedió.

Entre las razones por las que los candidatos reales no tuvieron éxito se incluyen:

1. Literalmente no producen nada después de la hora completa. Me entristece decir que esta situación ocurrió varias veces.
2. Plagiando el código del trabajo actual del candidato e intentando (y fallando) modificarlo para cumplir con los requisitos del examen. Cuando sospechamos esto, el historial del navegador lo delató.
3. Incapacidad de formar una cadena de conexión para conectar la aplicación a la base de datos. Esta puede parecer un poco injusta, pero recuerde que estábamos buscando candidatos de nivel superior, incluyendo experiencia en desarrollo de SQL Server de nivel superior. Ciertamente _no esperábamos que el candidato recordara cómo construir una cadena de conexión, pero sí esperábamos que el candidato fuera capaz de buscarla rápidamente. ConnectionStringBuilder también habría estado absolutamente bien, pero nadie lo usó nunca. El primer ejemplo de https://www.connectionstrings.com/sql-server/ habría funcionado perfectamente.

Había otra parte de la entrevista con el gerente y el equipo de desarrollo juntos, y hacíamos preguntas sobre la solución del candidato, cómo habría enfocado el resto del proyecto, etc.

En resumen, aconsejo considerar las motivaciones del empleador para una prueba “absurda” antes de descartarla de plano.

Esta respuesta no hace ninguna declaración sobre si este tipo de pruebas son buenas o no (o si las apruebo), sino que se centra en la pregunta específica._

¿Cómo puedo decidir si debo tomar pruebas técnicas que considero absurdas (e. por ejemplo, una tarea irrazonablemente grande con un límite de tiempo corto) en el futuro?

Como lo haría en el mundo real:

• Comunique cuánto tiempo tomaría la tarea razonablemente.
• Establezca su plan de qué hacer en el tiempo dado (es decir, hacer menos, o hacerlo peor, o ambas cosas).
• Hacer tanto como puedas, al menor nivel de calidad que puedas soportar. Concéntrate en conseguir una solución de trabajo antes que una solución completa.
• Documenta claramente dónde cortas las esquinas, cuáles son las implicaciones y los TODOs resultantes.

Todo esto me ayudaría enormemente, como empleador o cliente, a juzgar si quiero trabajar contigo.

Dependiendo de la estructura de gestión del empleador/cliente, la persona que te emplea (es decir, tu jefe/cliente directo) podría muy bien estar en una posición en la que no puede influir en el tipo de trabajo que consigas. La gestión matricial existe… en este caso preferiría tener a alguien que pueda manejar esas situaciones con gracia, en lugar de un héroe que entrega el mayor código de todos los tiempos, pero que no es capaz de comunicarse sobre los límites de tiempo/calidad.

La medida exacta de si se debe ir a por más calidad, o a por más contenido, depende. Por ejemplo, en tu caso, probablemente estarás más interesado en que vean que puedes proporcionar un trabajo de calidad. Por lo tanto, podrías recortar algunas características (usando algún marcador de posición, etc.), pero mantén alta la calidad de tu código. Del mismo modo, si el trabajo estuviera, por ejemplo, relacionado con la seguridad, harías lo mismo. Pero si se trata de una prueba de concepto completamente acrítica de algo, entonces uno podría virar más en la otra dirección. Documenta todo esto (sucintamente), y estarás bien encaminado.

PD: Me gusta evitar los juicios “locos o malos”. Es decir, no deberías preocuparte por si el cliente está loco, o si va a por ti (es decir, que hagas el trabajo gratis), sólo a juzgar por el tamaño de la tarea. La cantidad real que te importa es tu tiempo, y eso estaba fijado. Siempre y cuando estés de acuerdo en invertir las dos horas en un potencial nuevo cliente, no debería importar si la tarea se realiza fácilmente, o un trabajo de alta presión, o sólo dos horas de pequeña charla en su oficina.

No hay absolutamente nada malo con la prueba técnica de 2 horas de locura. **_Todos los demás candidatos tendrían que hacer la misma prueba, por lo que su probabilidad de que le ofrezcan el trabajo no es diferente a un ejercicio de programación fácil para principiantes. No había ningún sesgo; se te pidió que lo hicieras simplemente porque habías solicitado el puesto.

Eres el vendedor en el mercado de trabajo, y es tu responsabilidad acomodar a los compradores tanto como sea posible. Tienes poco poder de negociación aparte de ir a por otro puesto. Ciertamente, una prueba de programación que todos los candidatos tendrían que hacer no es irrazonable, independientemente de si realmente puede competir o no. Si estás altamente cualificado para el trabajo, pero no puedes completar la prueba, otros candidatos tampoco podrían completarla. Entonces, ¿cuál es el problema?

Te esfuerzas al máximo. ¿Enfadado por no haber sido ofrecido para el puesto? La compañía tiene que contratar a alguien, así que alguien más podría haber hecho un mejor trabajo. El punto de una prueba de programación imposible es encontrar al candidato con mejor desempeño. Que el mejor candidato complete el ejercicio es irrelevante.

cómo puedo decidir si debo hacer pruebas técnicas que considero absurdas

Deberías sentirte cómodo para cualquier prueba técnica si crees que tienes las habilidades para el trabajo y todos los demás candidatos tendrían que hacerlo. Nunca hagas una prueba loca si crees que es un intento de trabajos de programación libre o/y te la dan por prejuicios (por ejemplo, racismo)

PD: Nunca mencioné que OP no es “bueno suficiente”. @TessellatingHeckler