lunes, 24 de septiembre de 2007
Hace unas semanas Miguel de Icaza publicaba en su blog personal un par de ejemplos del tipo de pruebas técnicas que realizan cuando contratan personal, en este caso para el proyecto Mono.
La filosofía es bastante simple, y la verdad es que no carece de sentido: los aspirantes reciben por correo electrónico el "enunciado" de la prueba, y disponen de dos semanas para responder. Aunque el tiempo de respuesta puede parecer excesivo, está pensado para ser realizado por los aspirantes cuando vuelven a casa tras sus jornadas de trabajo o estudio.
Según Miguel, esta técnica le da mejores resultados que las tradicionales entrevistas cara a cara, donde una lectura del currículum y varias preguntas rápidas no permiten conocer en profundidad al candidato. No hay nada como ver planteamientos y código para saber el tipo de desarrollador que tenemos delante.
La prueba para trabajar en el ámbito de Windows.Forms consistía en desarrollar un Control (Widget) y responder una pregunta, y decía más o menos esto (traducción libre):
¿Que os parece? ¿Podríais entrar a trabajar en el equipo de Mono?
La filosofía es bastante simple, y la verdad es que no carece de sentido: los aspirantes reciben por correo electrónico el "enunciado" de la prueba, y disponen de dos semanas para responder. Aunque el tiempo de respuesta puede parecer excesivo, está pensado para ser realizado por los aspirantes cuando vuelven a casa tras sus jornadas de trabajo o estudio.
Según Miguel, esta técnica le da mejores resultados que las tradicionales entrevistas cara a cara, donde una lectura del currículum y varias preguntas rápidas no permiten conocer en profundidad al candidato. No hay nada como ver planteamientos y código para saber el tipo de desarrollador que tenemos delante.
La prueba para trabajar en el ámbito de Windows.Forms consistía en desarrollar un Control (Widget) y responder una pregunta, y decía más o menos esto (traducción libre):
Desarrollo de un control
Debes implementar un pequeño motor de renderizado para un lenguaje de marcas basado en XML. Este lenguaje acepta las siguientes etiquetas:
<p>...</p>, para definir el inicio y fin de párrafos.
Los párrafos pueden contener en su interior los siguientes tags:El control debe exponer la siguiente propiedad, que permitirá al desarrollador modificar el contenido (en este lenguaje de marcas) de forma programática.
- <b>...</b>, para poner en negrita el texto
- <i>...</i>, para poner el texto en cursiva
- <link>...</link>, para que el texto sea renderizado como un hiperenlace.
- <blink>...</blink> para que el texto parpadee
string Markup { get; set; }
Por ejemplo:m = new MarkupControl ();
m.Markup = "<p>Hello <b>World</b>!</p>";
El control también debe exponer un evento que permita notificar de los clicks del usuario sobre los enlaces (etiqueta <link>), algo así como:delegate void LinkClicked (object sender, string link_text);
De esta forma, será posible suscribirse al evento usando un código como el siguiente:m.LinkClicked += my_clicked;
...
void my_clicked (object sender, string link_text)
{
Console.WriteLine
("The link {0} was clicked", link_text);
}
Debes enviar una aplicación completa que se ejecute correctamente en Linux, y debe hacerse uso del evento y la propiedad citados con anterioridad. Por ejemplo, estaría bien tener algo como:void my_clicked (object sender, string link_text)
{
Console.WriteLine ("Link {0} pulsado", link_text);
((MarkupControl) sender).Markup = "<p>Nuevo <b>texto</b></p>";
}
Puntos extra: al usar <blink> será necesario actualizar la vista, se valorará si se evita el parpadeo usando buffers dobles o repintando sólo el área modificada.
Quiero una pequeña y sucinta implementación, pero es tu oportunidad para demostrar que puedes escribir código robusto, así que impresióname.Pregunta
En nuestra implementación de corlib, en System/DateTime.cs tenemos una implementación no óptima del método TryParse, básicamente invocamos a Parse dentro de un bloque try/catch.
Explica:
- ¿Por qué digo que nuestra solución no es óptima?
- ¿Qué debería tener para hacerla más eficiente?
- ¿Por qué el desarrollador que escribió el código no realizó lo más eficiente?
La trick-question es: ¿por qué el proceso más rápido no se realizó en primer lugar? Explícalo.
¿Que os parece? ¿Podríais entrar a trabajar en el equipo de Mono?
2 Comentarios:
hola.
detalles aparte, la idea de realizar este tipo de pruebas me parece genial. lo voy a proponer en mi empresa, a ver si mejorams las selecciones.
saludos cordiales
Hola, rvega, gracias por comentar.
Sí, el concepto es bueno. Ahora bien, utilizarlo en otros contextos debe ser difícil, a no ser que se trate de una oferta excepcional, de un sitio con el atractivo de Ximian (Novell) o por el simple hecho de trabajar junto a uno de los grandes como Miguel de Icaza.
¿Alguien hoy en día realizaría las pruebas, con el esfuerzo que conlleva, para una oferta mediocre o con objeto de acceder a una empresa del montón? Me temo que no.
Enviar un nuevo comentario