Necesitas una prueba de programación. Pero debería ser de 5 a 10 minutos. 30 minutos como máximo. No hay una prueba de 2 horas que le diga exactamente qué tan bueno es un programador. No podrá saber si continuamente escriben código mantenible, o si siempre comentan correctamente, o si presentan problemas ilegibles de soluciones 'inteligentes' a problemas, etc. En 2 horas, lo único que podrá lograr es descubrir quién está mintiendo abiertamente acerca de conocer un lenguaje/programación.

Excepto que debería poder detectar fraudes absolutos en mucho menos tiempo que 2 horas. 5 minutos escribiendo FizzBuzz y 2-3 preguntas rápidas sobre características específicas del idioma le dirán si son absolutamente inútiles. Y eso es lo mejor que puedes hacer en una entrevista de trabajo.

Déjame decirte lo que pensaría si me hicieran un examen de 2 horas por el privilegio de realizar una entrevista:

"Estas personas piensan que esto tiene valor, lo que significa que no tienen idea de lo que están haciendo, O saben que esto es una pérdida de tiempo, pero por alguna razón (probablemente siguiendo ciegamente los trámites burocráticos de Recursos Humanos), están dispuestos a desperdiciar la oportunidad del candidato". tiempo antes de que el candidato sea contratado Imagínese lo que pensarán que pueden salirse con la suya una vez que me estén pagando.

De cualquier manera, no quiero trabajar allí".

Hay otra cosa que podría alejar a los candidatos : la duración de su proceso de entrevista. Tienes gente haciendo una entrevista telefónica. Luego, una prueba para llevar a casa que tienen una semana para terminar. Luego pasas las pruebas. Luego establece una entrevista cara a cara con la gerencia. Luego (supongo) haces un par de entrevistas cara a cara. Luego vuelves con el tipo que quieres contratar. ¿Qué lleva eso? ¿2 semanas? ¿Más extenso?

En ese tiempo ya he recibido 3 ofertas. Acepté uno y empiezo la próxima semana. ¿Crees que voy a ir a hacer tu prueba de 2 horas?

Permítanme comenzar diciendo que contratar empleados en general es una ciencia patéticamente inexacta, y obtendrá varios resultados sin importar lo que intente. Habiendo dicho eso, sentí que debía compartir mis pensamientos sobre esto.

Creo que los ejercicios de programación son un fracaso, principalmente porque obtendrás personas que están desesperadas y tienen demasiado tiempo libre para completarlos. Si tienen un trabajo de tiempo completo, tendrías que preguntar cuánto tiempo/energía mental están tomando de su empleador actual para trabajar para alguien que ni siquiera les paga. ¿Quieres que te hagan cosas así?

Además, si son buenos, lo más probable es que se entrevisten con muchos empleadores. ¿Adivina cuáles priorizarán? Los que no piden completar proyectos antes incluso de hablar por teléfono con un gerente de ingeniería.

También está el problema del plagio. Claro, se descubrirán en la entrevista en persona, pero para entonces ya habrá perdido el tiempo de personas (presumiblemente) bien pagadas en la empresa entrevistando a esta persona.

Mi compañía actual lo hizo bien, y esta es la ruta que seguiría en su posición. Asígneles una pequeña tarea que solo debería tomar entre 90 y 120 minutos y dígales que justifiquen en los comentarios por qué eligieron esa forma de resolver el problema. Esto es algo que se puede hacer en una noche y le dará una idea de su forma de pensar.

Puedo decirles ahora mismo que si obtengo un proyecto que toma más de 8 horas, les doy las gracias pero no estoy interesado. Tengo un buen trabajo y una vida. Si un gerente ve eso como un problema, eso me dice que no le importaría mi equilibrio entre el trabajo y la vida en el trabajo (especialmente si no le importa antes de que lo tenga). Ninguna empresa, excepto quizás Google, Apple o Facebook, podría salirse con la suya.

En mi experiencia, los proyectos para llevar a casa no eliminan a los malos codificadores y probablemente hacen que los buenos codificadores encuentren un trabajo en el que no tengan que pasar por un aro para hablar con el gerente de contratación.

Piensa en ello de esta manera. Un buen codificador puede obtener fácilmente entrevistas telefónicas y en persona. Cada aro adicional que tengan que atravesar significará que tomarán la ruta más fácil y serán entrevistados (y serán contratados) por otra persona que pagará lo mismo. Si hace que las personas salten a través de los aros, asegúrese de que vean que vale la pena desde el principio.

Un mal desarrollador puede tardar todo el tiempo que quiera. No los verá tomar 4 veces más tiempo; solo verás la prueba completada. Tampoco los verá ir a Google o a su amigo para obtener ayuda con una ifdeclaración.

Mi última empresa hizo esto, y la gran mayoría de las personas que trajimos para una entrevista en persona fallaron en Fizz buzz (alrededor del 65%). Creo que esto sucedió porque, sin darnos cuenta, eliminamos a personas buenas y ocupadas que no necesitaban la entrevista de otra empresa y, al mismo tiempo, colgamos una entrevista fácil frente a programadores malos.

Lo que creo que deberíamos haber hecho en su lugar

En lugar de dar a las personas una tarea para llevar a casa que tomó de 15 a 20 minutos para calificar, deberíamos haber hecho una entrevista de Skype de 15 a 20 minutos en la que hicimos preguntas como Fizz buzz. Esto habría llevado la misma cantidad de tiempo, pero probablemente habría eliminado a los malos programadores antes de una entrevista en persona de dos horas.

FYI -> Aquí hay un artículo muy detallado sobre Fizz-buzz y prácticas generales de entrevistas.

Una visión contrastante, de alguien en las trincheras a ambos lados de esta cuestión. Sospecho que esta respuesta atraerá votos negativos, pero es una opinión muy informada, desarrollada durante varias décadas en este negocio. Como me gusta hacerlo, todavía escribo código todos los días para ganarme la vida y como pasatiempo en mi "abundante tiempo libre", pero también he sido quien tomó la decisión final sobre la contratación de un par de docenas de programadores, y he ayudado a entrevistar y asesorado en la contratación de un número bastante grande más.

Lawrence tiene razón: la contratación es lamentablemente inexacta. Pero estamos mejorando con el tiempo. Más que chats cara a cara, más que preguntas de trivia, los desafíos cortos de programación en el sitio son una parte cada vez más esencial de eso: no solo por habilidad, sino por actitud.

Tenga en cuenta que dije "corto" . Les damos a los candidatos una computadora portátil configurada con un Eclipse correctamente instalado (nuestro IDE elegido) cuando vienen a la entrevista. La configuración adecuada significa que tienen acceso a la fuente jdk, pero no tiene Internet, y se les pide que no usen teléfonos celulares durante la prueba. Tienen una hora para resolver de cero a cinco problemas, comenzando desde "FizzBuzz" y subiendo en complejidad hasta algo del orden de un sistema simple de productor/consumidor múltiple de subprocesos múltiples.

Nadie ha resuelto los cinco en una hora, y no espero que nadie lo haga nunca (puedo escribir soluciones para cinco en menos de una hora, pero por supuesto he visto los problemas y los he resuelto todos anteriormente, así que estoy no es una prueba justa).

Por cierto, hemos tenido programadores ostensiblemente experimentados que no lograron hacer bien FizzBuzz. Permítanme decirlo nuevamente: hemos tenido un puñado de candidatos que no completaron FizzBuzz correctamente. Por lo general, al no seguir las instrucciones, pero leer las especificaciones es una parte esencial de ser un desarrollador.

Les pedimos que escriban código mientras están aquí en las instalaciones en lugar de darles tarea por varias razones, en parte por el riesgo de hacer trampa y en parte para darles a cada candidato la misma oportunidad de resolver los problemas. También rotamos los problemas dentro y fuera del conjunto de desafíos, y luego discutimos las soluciones con los candidatos.

Me siento extremadamente fuerte en este tema. Nunca he visto a un candidato rechazar un puesto o abandonar el proceso de entrevista debido a nuestra prueba de programación. Pero eso puede estar influenciado por el hecho de que les decimos a los reclutadores que nos atienden que el proceso incluye programación en el sitio. Por lo tanto, es posible que no veamos a los candidatos que piensan que pedirles que escriban una hora de código es "trabajo no remunerado". Si es así, buen viaje. Si piensan que una hora de codificación es más "trabajo" que una hora de responder preguntas de trivia, o que sus respuestas a problemas de prueba pueden producir algo útil, no necesito su actitud.

Una vez tuvimos un candidato que se quejó de la prueba, porque pensó que era demasiado mayor para tener que probarse a sí mismo (eso no es especulación, lo dijo). Y lo hizo bien en los desafíos, y tenía toda la experiencia que queríamos. Pero era un empleado terrible : aparentemente también pensó que era demasiado mayor para recibir instrucciones o aprender, y finalmente tuvimos que despedirlo.

Una de las cosas que he decidido a lo largo de los años que hemos estado haciendo esto es que cualquier empresa que no haga pruebas tiene menos probabilidades de contratarme como empleado. Al igual que sus respuestas a preguntas como qué utilizan para el control de fuente, etc., si una empresa realiza pruebas, me dice mucho sobre qué tan buenos son en el negocio del desarrollo de software.

Entonces, ¿qué debes hacer? Debe hacer lo que funcione para su organización, pero mi consejo es que continúe con las pruebas, pero hágalas en el sitio, como parte de la entrevista. Dígales con anticipación que eso es parte del proceso y hágalo antes de que se reúnan con la alta gerencia (pero debe reunirse con ellos primero para ayudarlos a sentirse cómodos). Y realmente: omita la entrevista con la alta gerencia si fallan. No se preocupe por la popularidad con los candidatos o carteles en Internet. El costo de una mala contratación es mucho peor que el costo de retrasar hasta que haga una buena contratación .

¿Por qué no hacer pruebas en casa?

Incluso si ignoramos la posibilidad de hacer trampa y el filtro inverso que hace que los candidatos buenos y honestos eviten las empresas con pruebas de codificación en el hogar, el valor de las pruebas de codificación en el hogar es limitado.

Si es para un puesto sénior , un desarrollador sénior con don de gentes podrá saber en menos de 10 minutos si el desarrollador sénior al otro lado de la línea es bueno o simplemente está inventando cosas. No sabremos qué tan bueno exactamente, pero sabremos tanto, si no más, de lo que nos dice cada prueba de codificación en el hogar concebible.

Si es para un puesto junior , no esperamos mucho en términos de experiencia técnica. Estamos buscando entusiasmo, disposición para aprender y talento, ninguno de los cuales se detecta en una prueba de codificación en el hogar. Hay demasiadas cosas que los jóvenes pueden ignorar. Si los contratamos, debemos capacitarlos de todos modos.

¿Cómo probar en su lugar?

Como filtro, dales 10 minutos para resolver una variación de FizzBuzz en el sitio durante la primera ronda de entrevistas o, si te abruman con buenos CV y ​​necesitas otro filtro, hazlo por Skype antes de la primera ronda real de entrevistas.

Una vez que hayan pasado los filtros, necesita saber más sobre las habilidades de codificación de sus candidatos. Recomiendo pasar de 30 minutos a un máximo de 2 horas de programación en pares o revisiones de código: trabajo real real, en lugar de un ejercicio. Repita 1-2 veces con diferentes compañeros. La ventaja de la programación en pareja y las revisiones de código es que el desarrollador ya tiene suficiente conocimiento para contribuir.

No se preocupe de que la prueba sea diferente para cada empleado: el objetivo del proceso de contratación no es encontrar a la persona que obtenga la mejor puntuación en un par de pruebas medibles y repetibles. El objetivo es contratar a una sola persona que haga bien el trabajo.

Aquí hay otro punto que no veo cubierto en las respuestas existentes (que creo que cubren bien el tema en general). Echaría un vistazo de cerca y seriamente a cuánto tiempo le toma a la gente completarlo. Tuve cuatro entrevistas de trabajo durante las cuales tuve que completar un ejercicio de programación, cada uno de los cuales se hizo de manera diferente (y cada uno tenía sus propias ventajas y desventajas). Dos de los cuatro (números 3 y 4 a continuación) tomaron mucho más tiempo de lo que dijeron que debería, y terminé renunciando a ambos debido al nivel de dificultad involucrado. Los describí a continuación y los clasifiqué de mejor a peor desde mi perspectiva.

1. Durante la entrevista técnica, me sentaron frente a una computadora que tenía una versión reducida de su código base y me pidieron que resolviera tres problemas relativamente breves relacionados con él (encontrar y corregir un error que habían agregado a propósito, agregar un nuevo campo a una tabla de información, etc.). Me dieron exactamente una hora para hacerlo, y después de una hora repasaron mi solución y cómo abordé los problemas. Esto les dio más información sobre mí como programador, mientras respetaban mi tiempo manteniéndolo breve y directo.
2. Durante la entrevista técnica, me pidieron que trabajara en un problema que habían encontrado durante el desarrollo en una pizarra mientras podía intercambiar ideas con ellos. Esta fue la opción más corta, al mismo tiempo que les daba la oportunidad de ver cómo soluciono los problemas y cuánto puedo hacer realmente el trabajo necesario.
3. Durante la entrevista técnica (para un puesto junior de desarrollo web de Ruby on Rails) me encargaron crear una aplicación web desde cero que navegaría a un sitio web, completaría múltiples formularios a medida que se presentaran, extraería datos de la página resultante y presentaría eso al usuario. Dijeron que este debería ser un ejercicio rápido, y puede haber sido para un desarrollador web de alto nivel, pero habiendo tenido solo un año de experiencia profesional en ese momento, pasé cuatro horas tratando de hacer que todo funcionara antes de darme por vencido y continuar. casa (todos los entrevistadores se habían ido horas antes que yo porque era una entrevista por la tarde, dijeron que debería guardar el programa terminado cuando terminara). Esta es una asignación ridícula para el puesto indicado, no les dio idea de mis habilidades de codificación, y me pareció que solo estaban tratando de obtener trabajo gratis del acuerdo. No hace falta decir que ni siquiera quería el trabajo cuando me fui ese día.
4. Incluso antes de tener una entrevista técnica, me asignaron la tarea de crear una aplicación web que aprovecharía una API que usaba su empresa para "hacer algo interesante". Esto era exactamente tan amplio como suena. Esto me obligó a hacer lo siguiente incluso antes de intentar crear la aplicación: crear una cuenta de desarrollador para la API, descargar el kit de desarrollo de la API, crear una aplicación web de acceso público (con otra cuenta de desarrollador), aprender la API y crear un archivo de datos. repositorio para acceder con la API. Esto, por supuesto, tomó muchas horas solo para comenzar, y poco después de comenzar con la aplicación web en sí, obtuve una entrevista de trabajo diferente y poco después una oferta de trabajo, por lo que descontinué el trabajo en la asignación.

Entonces, para responder más directamente a su pregunta, ¿debería tener un ejercicio de programación? Sí, pero asegúrese de que esté diseñado para evaluar lo que realmente le interesa y que no requiera una tonelada de trabajo superfluo para el entrevistado. ¿Quieres saber sobre su pensamiento algorítmico? Plantéeles un problema de algoritmo. ¿Quieres saber sobre su estilo de codificación? Dales un problema de codificación. ¿Quieres conocer su proceso de desarrollo? Discuta su proceso con ellos mientras resuelven un problema.

Permítanme comenzar con:

• Me dieron pruebas para completar en casa que oscilaron entre 15 minutos y 10 horas.
• Me han dado pruebas en línea para ejecutar.
• Me han encargado que escriba la respuesta a FizzBuzz y otras pruebas de Internet de moda en pizarras.
• Me han preguntado acerca de las tapas de alcantarilla cuadradas vs redondas.

En resumen, he tratado prácticamente todas las formas diferentes en que a los desarrolladores les gusta manejar las entrevistas. Para ser honesto, dudo seriamente que la gran mayoría de las personas que me entrevistaron siquiera entendieron cuáles eran los resultados potenciales de cada una de esas pruebas y, en última instancia, solo contrataron a personas sobre si les "gustaban" o no.

Antes incluso de publicar una lista de trabajos, debe sentarse y analizar exactamente qué es lo que está tratando de contratar y "desarrollador" no es una respuesta, al menos, no es adecuada. Una buena respuesta a esto sería algo así como "experto en dominio hipotecario".

Encontrar a alguien que pueda escribir un poco de código o buscar en Google cómo aplicar un patrón en particular es trivial en comparación con encontrar a alguien que haya estado en el negocio en el que está y pueda aprovechar ese conocimiento. En otras palabras, si estuviera contratando para una compañía de documentación hipotecaria, elegiría a alguien que pudiera hablar sobre la diferencia entre un préstamo fijo de 15 años y un préstamo ARM en lugar de alguien que pudiera escribir un algoritmo de clasificación de burbujas en 2 minutos. La razón es que la gente de negocios "normal" hace todo tipo de demandas extrañas y los expertos de dominio pueden llegar más fácilmente al corazón de lo que se necesita, mientras que alguien que no sabe nada felizmente agregará cosas que son inútiles o harán que la aplicación sea realmente mala.

Volviendo a las preguntas, solo haga preguntas de si/no .

¿Es fundamental que la persona pueda decirle la diferencia entre un método virtual y abstracto? Podría ser, por lo general no lo es. Apuesto a que una buena parte de los desarrolladores apenas saben cuándo usar esas palabras clave, pero no son sus superestrellas, son el rango y el archivo que usan no pueden codificar sin los diseñadores visuales.

¿Es crítico detectar cuándo una consulta está abierta para la inyección de sql? Para una posición Sr - absolutamente; para una posición Jr. no. Esto es algo que se puede entrenar y manejar fácilmente a través de la revisión del código. De ahí la razón por la que quieres el sr. saberlo por dentro y por fuera, para que puedan entrenar a los juniors.

¿Es fundamental que conozcan el valor máximo exacto de un Int32tipo de datos? Normalmente no: ese nivel de conocimiento trivial es para lo que está Google; pero tal vez su requisito sea codificar en dispositivos con memoria limitada; en ese caso: absolutamente.

Entrevisto y contrato a desarrolladores. No envío pruebas a casa; es demasiado fácil tener la ayuda de un amigo. No utilizo sitios de prueba en línea; dado que la puntuación debe automatizarse, es trivial jugar. No pido a los candidatos que escriban la respuesta a fizzbuzz; casi todos han visto esa prueba y deberían saber la respuesta de memoria; todos los demás ingresaron al campo en el último año y son jr. de todos modos. Tampoco hago preguntas triviales: ser capaz de recitar la respuesta generalmente solo significa que has escuchado la pregunta antes.

Lo que hago para entrevistar a la gente:

• Les pido que describan uno o dos proyectos anteriores. Todo lo que me importa en este punto es hacerlos sentir cómodos y hacerlos hablar. Esto es un sí/no porque si no puedo entender lo que están diciendo, entonces no puedo trabajar con ellos.

• Les hago algunas preguntas específicas sobre la tecnología que necesito que usen. Si es un servidor SQL, preguntaré sobre la actualización en una unión. Si es HTML, les entregaré un archivo html de 10 líneas con un par de clases CSS y les preguntaré cuál es el resultado. Estas son preguntas triviales para personas con experiencia en esas áreas y eliminan rápidamente a los pretendientes.

• Si busco un desarrollador sénior, le haré preguntas sobre el conocimiento del dominio. No se trata de casos extremos, sino de principios básicos. Si necesito que dirija un proyecto en un back-end de contabilidad, es mejor que tenga una comprensión de los principios básicos de contabilidad.

• Si estoy buscando un desarrollador Jr., le preguntaré sobre proyectos favoritos. todo lo que quiero saber es el tipo de tecnología utilizada. Esto debería darte una idea de lo que realmente quieren hacer. En otras palabras, no es probable que un desarrollador de C# esté haciendo proyectos favoritos en php. Sinceramente, no espero demasiado de un desarrollador jr, excepto que sea entrenable. Si están trabajando activamente en un proyecto favorito, entonces puedo capacitarlos. Si son del tipo que necesita gente que les diga qué hacer, hay empresas mucho más grandes en las que estos tipos pueden trabajar.

No hago estas preguntas sobre la marcha, las posibles respuestas se consideran con anticipación y se ajustan a un patrón de ir/no ir. Si una pregunta no se ajusta a eso, entonces no es relevante. También le pregunto a todos los candidatos lo mismo a menos que esté 100% convencido de que no los contrataré, momento en el cual detendré la entrevista.

Si por alguna razón aún insiste en enviar una prueba a casa, asegúrese de que las habilidades requeridas para completar con éxito esa prueba en un tiempo razonable sean realmente habilidades que le interesen.

Una empresa me hizo una prueba para llevar a casa que implicaba escribir un proveedor de servicios criptográficos personalizado. Completé la prueba porque era algo interesante; me contrataron En ningún momento de mi tiempo hice nada ni remotamente relacionado con la seguridad, la criptografía o incluso las matemáticas más allá de agregar algunos números. Me pregunto a cuántas personas expulsaron con esa prueba.

Desde el punto de vista de una persona que busca trabajo, generalmente evito los lugares que tardan más de 1 hora en codificar. Una vez fui a este lugar que requirió un proyecto de codificación java de casi 3 días. Lo hice todo y el chico incluso quedó impresionado con eso, pero me dijeron que contrataron a alguien más después de la segunda etapa de la entrevista. Después de eso, si llego a una empresa, ignoraría o aprobaría cualquier proyecto que requiera más de un par de horas para completarse. Mi tiempo es tan valioso como el de ellos y prefiero no desperdiciarlo en cosas que no me llevarán a ninguna parte.

Dicho esto, si su ejercicio de codificación es demasiado largo, tal vez las personas no estén dispuestas a dedicarle tiempo. Intentaría reducirlo de modo que tome una hora como máximo, pero al mismo tiempo demuestra una comprensión de la codificación y tal vez poniendo una fecha límite como, "Por favor complete antes de COB mañana" o algo así. Todavía pueden "copiar y pegar" algo en línea, pero lo dificultan al ser específicos en lugar de algo que lee en línea.

Solía ​​​​creer firmemente en las pruebas de codificación y la codificación de pizarra, pero comencé a darme cuenta de que son bastante inútiles, porque

¿Qué estás probando, de todos modos?

Una prueba de pizarra o una breve prueba de programación le brinda una idea del individuo, pero en realidad no tanto. A menos que planee que alguien pase su tiempo escribiendo código en una pizarra o código de estilo FizzBuzz.

¿Qué quieres ?

Quieres a alguien que sea:

• apasionado
• dispuesto a aprender
• capaz de resolver problemas*
• razonablemente técnico
• va a ayudar a su equipo a mejorar

* _{Tenga en cuenta que la mayoría de los desarrolladores resuelven sus problemas sabiendo qué términos buscar en Google.}

Lo último que desea contratar es a alguien que no encaja bien en su equipo porque lo arrastrará hacia abajo.

¿Cómo se puede probar para estos?

• Pregúnteles acerca de un proyecto que disfrutaron. Si parecen reacios a hablar de ello, intente expresar una leve incredulidad, por ejemplo, "No puedes hacer X, ¿verdad?" Si es algo que les apasiona, te corregirán. Esto también te ayudará a saber si son técnicos o no.
• Pregúnteles acerca de las cosas que han aprendido recientemente. O lo que aprendieron del proyecto en el que trabajaron disfrutaron.
• Pregúnteles sobre la última vez (o una vez) en la que les faltaba algún conocimiento. ¿Cómo obtuvieron la información que necesitaban? ¿Fueron a un compañero de equipo? ¿Buscaron en internet?
• Pregúnteles si hay algo que les gustaría ver mejorado en su equipo actual/último. ¿Necesitaban mejores mensajes de confirmación? ¿Más revisiones de código? ¿Más pruebas? ¿Más automatización?
• Pregúnteles qué tecnología los emociona y por qué.

Si tiene a alguien que es técnicamente competente en esta conversación, será lo más fácil del mundo saber si esta persona será la peor. Un ejemplo: tuvimos a un niño que vino y nos entrevistó; dijo que en una escala del 1 al 10, sus habilidades en Java eran como un 7-8. No creo que ni siquiera supiera que Java se compiló en un archivo jar que luego JVM compiló en lenguaje de máquina. Me clasificaría tal vez como un 2 o un 3 y lo sé.

En realidad, nuestro CTO le hizo la misma pregunta en una entrevista el día anterior, y nuestro CTO lo llamó y le explicó que no había forma de que fuera un 7-8.

Nuestro CTO también le preguntó sobre su proyecto favorito, que tenía que ver con los escáneres portátiles. Pero no pudo explicar nada acerca de cómo funcionaban, o el hecho de que usaron el sondeo para evitar las esperas ocupadas. No podía explicar una sola cosa técnica.

Ese tipo no fue contratado.

Averigüe el tipo de atributos que está buscando y luego descubra cómo probarlos

¡Pero realmente necesito ver cómo codifica!

Está bien, está bien, pero a menos que vaya a codificar en un silo, lo mejor que puede hacer es contratarla como contratista para un proyecto pequeño y bien definido. Tal vez esté agregando la capacidad de descargar algunos archivos de un FTP y luego volcarlos en su base de datos. Algo simple, que no requiere mucho/ningún conocimiento del dominio.

Haz que tus candidatos trabajen con uno o dos empleados existentes y págales por su tiempo. Podrás ver exactamente cómo trabajan y qué tan bien trabajan con el equipo. ¿Se comunican bien? ¿Se frustran fácilmente? ¿Son persistentes?

Hay cosas que puede hacer para contratar mejores empleados... pero una competencia de programación probablemente no sea una de ellas.

Como otros han señalado, algunos desarrolladores pueden desanimarse por un ejercicio de programación de 1 a 2 horas para solicitar un trabajo. Lo que puede funcionar mejor es tener una sesión de pizarra, donde el candidato resuelve un problema en una pizarra durante la entrevista. Esto le brinda la oportunidad de tener una entrevista en persona y al mismo tiempo asegurarse de que tengan habilidades técnicas.

Estos problemas no deberían ser extremadamente difíciles o diseñados para hacer tropezar a un desarrollador. Un ejemplo clásico es FizzBuzz . Esto le permite ver cómo piensan y también saber que al menos pueden programar y no necesitan buscar en Google cómo hacer un bucle.

NO TE LIBRES DE LA PRUEBA DE CODIFICACIÓN!!!!

Si quieres ser programador, tienes que escribir código que haga algo. Responder preguntas de trivia no es tan importante. Conversar sobre experiencias pasadas es bueno, pero de ninguna manera reemplaza la capacidad de codificar.

Haz lo que sea necesario para atraer a la gente a querer tomar la prueba y obtener este trabajo. Hazlo más corto o págales. Tráigalos un fin de semana para que todos tengan tiempo de observar a esta persona en acción.

Esto realmente depende de tener personas que puedan interpretar los resultados de las pruebas/observaciones. Es posible que desee contratar a un tercero para que realice esta evaluación si no sabe cómo hacerlo. Solo obtener la respuesta correcta es solo la mitad de la batalla. Los desarrolladores necesitan habilidades para buscar en Google, pero hay mucho más. Si un programador puede hacer la prueba más rápido, eso es una ventaja.

Dependiendo de su proyecto, puede preferir la fluidez en un idioma, para que el desarrollador pueda comenzar a trabajar de manera eficiente de inmediato. Por otro lado, podría sufrir a largo plazo si opta por el programador menos hábil que se va a quedar atascado con una característica clave de su aplicación o si construyen una estructura tan pobre que es difícil de modificar y mantener. Es posible que haya estado mejor con un buen programador que esté dispuesto a adaptarse y aprender el lenguaje necesario. Hay muchos desarrolladores que huirán absolutamente de ciertas pilas, marcos, lenguajes, herramientas y sistemas operativos.

Los desarrolladores son puestos críticos que son muy costosos de cubrir. Entiendo tu preocupación por ahuyentar demasiados buenos, pero solo necesitas uno. No escatimes.

En mi opinión, el problema que tienes aquí no es necesariamente la prueba de programación. Primero tiene la entrevista técnica telefónica y luego una prueba de trabajo desde casa antes de una entrevista cara a cara. Parece que estás manteniendo a tus candidatos a distancia y dejándolo hasta el último minuto antes de conocerlos. ¿En qué momento espera que los candidatos decidan que quieren trabajar para usted?

Supongo que su anuncio de reclutamiento es similar a la mayoría y, por lo tanto, se enfoca en la ubicación, el salario y una lista (de deseos) de habilidades. Los candidatos no saben realmente en qué estarían trabajando, nada sobre el entorno o las personas con las que tendrían que interactuar. Todavía no les ha vendido el trabajo, aquí les está pidiendo que demuestren sus capacidades técnicas dos veces antes de que puedan hacer una sola pregunta sobre el trabajo.

Le sugiero que intente cambiar el formato de la entrevista telefónica técnica para que sea una conversación de 30 a 45 minutos sobre el trabajo que incluya muchas oportunidades para preguntas de los candidatos, luego 15 minutos de preguntas técnicas como pantalla para que aún tenga la oportunidad de elegir los mejores solicitantes sin hacerlo demasiado oneroso.

También consideraría mover el desafío de la programación para que se haga en el sitio antes de las entrevistas. Les parecería más alcanzable a los candidatos, dales un incentivo para mantenerse al día con el proceso y obtendrías el beneficio de observar el tiempo real dedicado al desafío (creo que podrías sorprenderte).

No me gustan las pruebas para llevar a casa como parte de las entrevistas, por muchas de las razones que la gente ya ha mencionado: extiende el proceso de contratación, devalúa el tiempo del solicitante, es posible que no le devuelvan la llamada de todos modos, etc.

Mi principal problema es que no es realista cómo funciona realmente el equipo y hace que el proceso de entrevista sea unilateral. Un solicitante quiere saber si este lugar es adecuado para él, incluida la cultura, cómo el equipo aborda y resuelve los problemas. Principalmente, también busca el ajuste, incluido cómo funcionan y si tienen el conjunto de habilidades adecuado. Una prueba para llevar a casa no le brinda al solicitante la oportunidad de evaluar las cualidades blandas de un lugar de trabajo, y los empleadores no pueden aprender cómo el solicitante abordó el problema.

Una mejor solución podría ser darle al solicitante un problema más abierto que pueda resolverse de cualquier forma creativa. Incluso podría restringirlo al lenguaje X. En lugar de enviarlo por correo electrónico, invítelos a que se lo presenten a usted y a la alta dirección. Les da autonomía e incentivo para hacerlo bien, porque promete otra entrevista y demuestra que te importa saber lo que piensan.

Si debe usar una prueba para evaluar qué candidatos logran entrevistarse con la alta gerencia, incluiría la prueba en la entrevista para que puedan discutir su proceso de pensamiento juntos.

¿Quieres contratar programadores que no saben programar ?

Me voy a aventurar que tú no.

Contratar programadores que en realidad no pueden resolver problemas y escribir código es una buena manera de arruinar una empresa de tecnología. Y no va a ser efectivo para eliminar a los programadores que en realidad no pueden programar (y hay muchos de esos por ahí) si su proceso de contratación no incluye algún tipo de prueba de programación.

¿Estás dispuesto a bajar tus estándares porque todos están tratando de contratar programadores?

Tal vez lo seas, pero no creo que debas serlo. Como se ha señalado en los comentarios y respuestas, hay candidatos que no se molestarán en hacer ejercicios de programación como parte de un proceso de entrevista porque simplemente no es necesario para conseguir un trabajo .

Pero, ¿son esas realmente las personas que desea contratar de todos modos? ¿Los que siguen el camino de la menor resistencia, hacen lo que sea más beneficioso para ellos a corto plazo y realmente no se preocupan lo suficiente por su empresa como para completar un simple ejercicio de programación? Esos no parecen atributos positivos y no brindan mucha confianza en términos de poder retener a esos candidatos a largo plazo (lo que también es importante para una empresa de tecnología, ya que las curvas de aprendizaje tienden a ser pronunciadas y el costo de reemplazar al personal existente es muy alto).

Así que deje que esas otras empresas tengan programadores que ni siquiera pueden molestarse. No querrás contratarlos de todos modos. A diferencia de ellos, tú tienes un plan. Uno que no se base en la falacia de "un programador es un programador". Su enfoque debe estar en la calidad y la sostenibilidad, no en el recuento de cadáveres.

¿Es un problema asustar a los candidatos?

Por lo general, no, siempre que los asusten por una buena razón. No querrás contratar a personas que no estén a la altura. Y algunas de las personas que dicen que "no se les puede molestar" debido a la gran demanda en realidad podrían estar usando eso como una excusa para encubrir un "realmente no es tan bueno programando, así que necesitaría toda la semana para completar un ejercicio de 1 hora". situación.

Es bueno ahuyentar a esos candidatos. Desea contratar a los candidatos capaces y motivados. Mientras no asustes a esos también, estás bien.

Cada candidato que no asustas es uno que tienes que probar y evaluar. Y eso puede ser difícil de hacer si no les está dando a sus candidatos técnicos ningún ejercicio técnico para usar en la evaluación.

¿Cómo puedo mejorar nuestro proceso de contratación?

Revisa el contenido de tu ejercicio de programación. ¿Es razonable y apropiado para un contexto de entrevista?

No desea algo que va a tardar días (o incluso horas) en completarse. Lo que quiere es algo simple para eliminar a las personas que simplemente no pueden programar , idealmente con suficiente espacio para los matices para que las personas que pueden programar realmente bien puedan diferenciarse. Tenga en cuenta lo que está tratando de lograr (eliminar candidatos no calificados y no serios) y asegúrese de que su contenido se adapte a ese objetivo. No te excedas.

Si ya tiene personal técnico, puede usarlo para verificar la cordura (y/o ayudar a diseñar) su ejercicio.

Y también considere cómo administra el ejercicio. Si solo les da algo de documentación y dice "aquí, haga esto durante la próxima semana y envíemelo por correo electrónico", probablemente solo será mínimamente efectivo.

Sería mejor si puede ejecutar el ejercicio a través de un portal web, en el que los candidatos pueden registrarse y comenzar el ejercicio, y una vez que comienzan, un temporizador comienza una cuenta regresiva desde 1 hora. Luego, o envían algo dentro de esa hora, o no. Eso es menos abierto, retiene mejor el enfoque del candidato y proporciona una fecha límite/calendario claro para que 1) no tenga que esperar toda la semana por un resultado que nunca llegará, y 2) los candidatos no calificados no desperdiciar una semana de su tiempo tratando de completar su ejercicio de programación. Obtienen 1 hora, resuelven el problema o no, y usted sabe el resultado de inmediato.

Y aún mejor sería traerlos para una entrevista en el lugar. Preséntelos a un miembro de su equipo de desarrollo. Enciérrelos en una habitación junto con una estación de trabajo. Haga que su desarrollador comience con algunas preguntas de entrevista generales/suaves, y luego puede programar en pareja con el candidato para resolver el ejercicio de programación. Esto le dirá no solo si el candidato puede codificar o no, sino también qué tan bien trabaja con su equipo. Su desarrollador también debería poder obtener mucha información adicional que simplemente no obtendrá al mirar un montón de código que un candidato escribió y luego le envió por correo electrónico.

Línea de fondo

No, no querrás deshacerte de tu ejercicio de programación. Pero es posible que desee revisarlo en busca de contenido apropiado, asegurarse de que no tome mucho tiempo resolverlo y también ver cómo lo está adaptando a su proceso general de entrevista.

Un ejercicio autodirigido para llevar a casa probablemente no sea el mejor enfoque. Pero la solución a eso no es desechar el ejercicio por completo. No, a menos que estés de acuerdo con contratar programadores de mierda, en cualquier caso.

Es mejor ahuyentar a muchos malos candidatos y un puñado de buenos que abrir las compuertas y contratar a unos pocos malos.

Como respuesta directa a la respuesta de Bobo (que es la respuesta aceptada porque el tipo la escribió y la aceptó él mismo, lo que, francamente, creo que es un poco patético):

Vienes de una premisa totalmente equivocada. No quiero trabajar para ti. ¿De dónde sacas esa idea de que alguien quiere trabajar para ti ? Usted es solo una de las muchas empresas que ofrecen un trabajo. No quiero trabajar para ti. Quiero evaluar su empresa, y si sale por encima de todos los demás, ahí es cuando quiero trabajar para usted.

Hay una docena de empresas en las que puedo trabajar, estás en algún lugar de la cola. Primero miro qué empresas hay, les envío mi CV, pueden leerlo y quedar impresionados o no, luego normalmente tienes una conversación telefónica rápida en la que me muestran que tienen un trabajo interesante y yo demuestro que tengo las habilidades. , y cualquier prueba de codificación podría llegar al final.

Su prueba para llevar a casa lo coloca al final de la fila. Para compensar, tendría que publicar un rango de salario que sea £ 10k más alto que otros. De todos modos, encontrar un trabajo requiere mucho tiempo; alguien que lo hace diez veces más lento está al final de la lista. Si tengo que elegir entre enviar un currículum y tener una entrevista telefónica con diez empresas, y hacer la tarea para usted, adivine lo que haré.

Entonces, lo que sucede es que encuentras candidatos que quieren trabajar para ti porque no conseguirán trabajo en otro lado .

Una cosa que nadie parece haber mencionado; incluso si la prueba no es tu problema, debes buscar otras formas de atraer talento.

Si está buscando buenas personas en función de su trabajo publicado existente, no necesita ejecutar la prueba con ellos .

Si solo le envían personas a través de reclutadores y filtros, es vulnerable al hecho de que sus necesidades y las necesidades de los reclutadores no se combinan perfectamente. Quieren colocar a alguien contigo. Quiere un ingeniero de primer nivel. Si pueden encontrar un ingeniero de alto nivel que sea increíble porque volverás con ellos, pero si no pueden (y los ingenieros de alto nivel tienden a tener cosas en marcha que dejan poco tiempo para la entrevista), se conformarán con solo colocando a un ingeniero moderado con un lindo traje. La pérdida para ellos es un poco de reputación a largo plazo, pero eso es menor en comparación con perder sus objetivos. Si es probable que esto no sea cierto en su caso, quédese con ese reclutador y nunca lo deje ir (*),

Lo que quiere hacer es encontrar candidatos demostrablemente interesantes. Busque en StackOverflow y GitHub los mejores ingenieros (escuché que StackOverflow tiene una herramienta para ayudar con esto ), busque compañías técnicamente interesantes que produjeron un buen software pero que arruinaron sus finanzas o monetización, y acaban de despedir a 10 ingenieros de alto nivel. Pasa tiempo trabajando en universidades ayudando con proyectos de fin de año. Identificar buenos candidatos potenciales y hacerse amigo de ellos, preferiblemente en persona, alternativamente a distancia; incluso si tienen ofertas, los buenos ingenieros se juntan con buenos ingenieros. Además, pueden decirle cómo se sienten acerca de su proceso de contratación.

¿Suena esto como mucho trabajo? debería _ Una de las razones por las que la contratación parece tan "difícil" es porque estás tratando de hacerlo de la manera más eficiente posible. Cuanto más tiempo, capacidad intelectual y recursos le dediques, más fácil será. Si esos recursos se gastarían mejor en el envío del producto es la eterna pregunta de gestión. Pero si dedica mucho tiempo a la "filtración de programas basura", eso es gastar dinero . Al menos los pasos descritos anteriormente tienen un valor inherente más allá del proceso de contratación.

(*): Joder, contratalos .

Creo que ha formulado su pregunta un poco mal, pero la forma en que la ha formulado refleja un concepto erróneo común sobre la contratación de programadores. ¿Los candidatos están siendo "asustados" por la tarea de programación, o están filtrando a su empresa fuera de su propia consideración debido a la tarea?

Una anécdota para demostrar mi punto: mientras buscaba trabajo no hace mucho, vi un puesto para una empresa que parecía promedio. La forma en que describieron su proceso de programación hizo que sonara bastante bien, pero había muy pocos detalles, por lo que era escéptico. Tal vez eran un buen lugar para trabajar, tal vez no. Pero pensé que vería cómo llegar a la pantalla de un teléfono para poder descifrar los detalles y ver si eran tan buenos como parecían.

Hice clic en la publicación de trabajo e inmediatamente me pidieron que escribiera una carta de presentación. Puaj. Creo que todos los candidatos odian las cartas de presentación. No conocía esta empresa ni usaba sus productos, entonces, ¿qué podría decir sobre ellos? Los busqué en Google, leí su sitio web y sus ofertas de productos, descubrí dónde podría encajar en su organigrama si me contrataban y se me ocurrieron algunos párrafos "vendiéndome".

Luego proporcioné mi currículum y acceso a mi LinkedIn, pero inmediatamente después me pidieron que completara mi experiencia laboral relevante con fechas y descripciones. Esta información está tanto en mi LinkedIn como en mi currículum, fue ridículo tener que proporcionar la misma información 3 veces. Cerré la pestaña del navegador. 5 minutos más tarde estaba aplicando a otra compañía que ofrecía algunos beneficios realmente geniales que la primera no ofrecía. De hecho, podría aplicar a otra compañía con mejores beneficios más rápido de lo que podría pasar por los aros que la primera compañía quería de mí.

Debe asegurarse de que sus candidatos estén interesados ​​​​en su empresa en particular antes de presentarles obstáculos para saltar, o de lo contrario no saltarán. ¿Haces esto?

Ejemplos de beneficios de calidad que comúnmente veo que ofrecen las empresas de tecnología:

1. Trabajo remoto.
2. Computadoras/monitores gratis como bono de firma.
3. La empresa contribuye a respetados proyectos de código abierto.
4. Reembolso por formación profesional y/o congresos.
5. Almuerzos atendidos.
6. Horario flexible.
7. Oportunidad de trabajar con tecnologías nuevas o desconocidas.
8. "Cultura de inicio" - también conocida como falta de política/burocracia.
9. Patrimonio de la empresa.
10. Reconocimiento de nombre: su empresa o su producto es conocido. A los candidatos les gusta mencionar dónde trabajan y escuchar a la gente responder "¡Oh, genial! Me gustan sus productos".
11. Objetivos/visión de la empresa benéfica o revolucionaria. A la gente le gusta escribir código que mejore la vida de las personas.
12. Salario por encima de la media. El dinero cubre una multitud de pecados organizacionales.
13. Retiros anuales de empresa a lugares frescos.

Esta lista no es completa, pero si su empresa no ofrece uno o más elementos como los de esa lista, entonces cualquier obstáculo en su proceso de contratación podría enviar a un candidato a buscar uno que sí lo haga.

Así que digamos que, por alguna razón, no ofrece o no puede ofrecer incentivos como los anteriores para que sus candidatos los convenzan de que se gasten escribiendo código para usted de forma gratuita. Entonces, ¿qué puedes hacer? Tengo dos alternativas que la mayoría de los candidatos preferirán a las tareas de programación ajetreadas:

Alternativa n.º 1: págales una tarifa por hora para realizar tu tarea de programación como si fueran un contratista. Esto les anima a tomárselo en serio tanto por motivos profesionales como porque... les pagan. Esto le cuesta dinero, pero también lo hace cualquier forma de reclutamiento. Si es realmente bueno, incluso puede encontrar una manera de que diagnostiquen y corrijan un error real en su código, en cuyo caso obtendrá algo útil por su dinero.

Alternativa n.º 2: probablemente ya hayan escrito un código de forma gratuita que le mostrarán si solo se lo pregunta. La mayoría de los programadores tienen código en Github, Bitbucket, sitios web de preguntas y respuestas como Stack Overflow, o podrían proporcionarle algún código que aún no hayan publicado.

¿Por qué hacer que escriban un código que no les interese cuando podrías dejarles compartir un proyecto apasionante contigo? Se garantiza que será menos aburrido que leer otra solución al mismo problema genérico por centésima vez. Y dado que el código ya está escrito, le ahorra tiempo a usted y a su candidato. Además, verá qué tipo de código les gusta escribir, lo que da una idea de su personalidad y qué tan bien encajarán con la cultura de su empresa.

¿Cuál es tu problema empresarial?

Sin tener en cuenta todos los argumentos a favor o en contra de pruebas particulares, todo se reduce a una compensación: más filtros ahuyentarán a algunos buenos candidatos, menos filtros dejarán pasar a malos candidatos que quizás deba reemplazar poco después de la contratación.

Todo se reduce a observar la situación de su negocio en lugar de las prácticas generales.

¿Actualmente tiene un problema en el que carece de candidatos calificados y no puede contratar tan rápido como necesita para cumplir con sus objetivos comerciales? Debe deshacerse de esta tarea de programación inicial.

¿Actualmente tiene un problema en el que no está satisfecho con la calidad de sus contrataciones recientes? Entonces necesitas implementar más filtros como este.

¿Tiene ambos problemas y ambos son igualmente dolorosos? Enhorabuena, ha encontrado el equilibrio adecuado para esta compensación.

Realmente creo que puede ayudar a establecer quién realmente sabe los idiomas que figuran en su currículum.

Si ese es realmente su objetivo, consideraría un enfoque diferente. Como indicaron otras respuestas, SÍ, siempre debe tener una pregunta de codificación, pero las preguntas de codificación rara vez entran en detalles del idioma. Algunas preguntas que he visto que son útiles para probar esto:

1. Compare y contraste Java y C (o los dos idiomas que sean relevantes, estén en el currículum del candidato, etc.)
2. ¿Qué características crees que deberían agregarse al lenguaje? (O mejor aún, ¿qué piensa sobre este cambio reciente/propuesto en particular en el lenguaje?)

Los ingenieros que han visto una o dos cosas saben cómo responder a estas preguntas con bastante facilidad y en solo unos minutos.

En mi humilde opinión, hay casi un 0% de posibilidades de que un recién graduado universitario pueda hacer un código de programación difícil en un nivel de entrada. Si su prueba de codificación tarda una semana en completarse, debe mencionar claramente en su requisito que están buscando programadores con al menos más de 2 años de experiencia porque creo que se necesita mucha experiencia para completar un trabajo de código que requiere uno. semana para completar. Y creo que si está buscando recién graduados, diseñe su prueba en consecuencia y puede encontrar muchas ideas en Internet o puede pedirle a los programadores senior que trabajan para usted que diseñen una prueba adecuada para recién graduados.

Pensé que respondería a esta pregunta, ha pasado un año desde que se publicó y nos hemos ceñido a ella.

RECOMENDACIONES

Positivos del enfoque

1) La prueba para llevar a casa elimina a los candidatos desmotivados y los reemplaza con candidatos que realmente quieren trabajar para usted. Esto por sí solo hace que valga la pena hacerlo, ya que las personas motivadas = empleados productivos. Si no se molestan en hacer una tarea de 1 hora, eso dice mucho sobre su actitud para conseguir el trabajo.

2) Estoy de acuerdo con otros, que la prueba para llevar a casa no debe durar más de una hora; la mía es muy simple. He tenido los siguientes resultados al agregarlo al proceso de reclutamiento:

a) Algunos candidatos no lo completan. No vale la pena contratar.

b) Algunos alumnos lo intentan pero lo completan mal. No vale la pena contratar.

c) Algunos candidatos hacen trampa, momento en el cual vale la pena hacer preguntas de seguimiento sobre su asignación. Hicimos esto con un candidato reciente que luego no se molestó en responder a nuestro correo electrónico sobre la asignación. No vale la pena contratar.

d) Algunos candidatos al enterarse de que hay una asignación técnica repentinamente retiran su solicitud, donde anteriormente mostraban MUCHO interés. Probablemente esquivó una bala.

e) Algunos candidatos lo hacen muy bien, comentan su código y en una o dos ocasiones aportan documentación. Vale la pena contratar.

Negativos del enfoque

1) La deserción de la solicitud de los candidatos que se desaniman por la tarea de llevar a casa hace que sea más largo encontrar a alguien adecuado. PERO, por otro lado, es positivo para la empresa, ya que reduce la probabilidad de una mala contratación, lo cual es peligroso.

2) No siempre se puede saber si alguien ha hecho trampa, pero es por eso que a menudo se respalda con una entrevista telefónica técnica.

Resultado de este enfoque

Uno de nuestros empleados que contraté usando este enfoque resultó ser un empleado estrella. Él todavía está trabajando para nosotros después de más de un año. Es confiable y técnicamente talentoso.

Un mouse desconocido o un diseño de teclado inesperado (especialmente Mac vs PC), o un IDE diferente pueden ralentizar drásticamente el rendimiento sin ninguna diferencia en la competencia. Además, una aplicación completa a menudo requiere una gran cantidad de código repetitivo que un desarrollador puede no tener suficiente tiempo para escribir o incluso no recordar. Comenzar una nueva aplicación completamente desde cero es en realidad una tarea muy rara; la mayor parte del trabajo se concentra en ampliar o mejorar el código existente.

Por lo tanto, sugiero dar solo tareas muy cortas y preparadas con más cuidado durante la entrevista. Lo mejor es pedir escribir una función que debe tomar parámetros dados y devolver el resultado explicado y recomendaría hacerlo en papel, evitando la computadora en absoluto.

Los enviaría a un cuestionario en línea donde puedes filtrar a las personas que no tienen ni idea. Al menos tendrías una idea de si saben de lo que están hablando.

Al principio de mi carrera, los cazatalentos me decían "te enfrentas a personas que leen el recuadro y ponen una solicitud en su currículum". Asumo que esto todavía les puede pasar a los jóvenes e ingenuos, pero una vez que te critican en algunas entrevistas, te das cuenta de que es un mal consejo...

Recientemente me hice una prueba para llevar a casa. Era una aplicación completa que necesitaba conectarse a un servidor de socket que tenía que simular una alimentación lenta. El cliente se actualizó dinámicamente, pudo cancelar la fuente y escribir y leer XML.

De todos modos, quiero aprender sobre sockets, ya que estoy pensando en usarlos para un servidor de póquer que estoy escribiendo.

Quería aprender XMLreader y XMLwriter.

Al principio pensé olvidarlo. Pero luego lo vi como una oportunidad para demostrar lo que puedo hacer. No tengo un título en informática, así que echo de menos algunas cosas teóricas. Preguntaron cuáles son los 3 pilares de la programación orientada a objetos y querían decir a quién le importa.

Mi mensaje es que las personas que quieren el trabajo deben completar la prueba.