jueves, 26 de noviembre de 2015

Contratación ¿En qué me estoy equivocando?

Aunque no acostumbro a escribir posts de opinión (básicamente porque creo que mi opinión no aporta mucho en casi ningún tema), hoy haré una merecida excepción porque quiero compartir con el resto una situación que me está sorprendiendo y frustrando a partes iguales y además no parece tener visos de solucionarse en un futuro cercano.

Después de 10 años como empresario/autónomo/auto-empleado, todo el equipo anterior (la friolera de 3) hemos emprendido juntos una nueva aventura en una especie de start-up (la llamo así porque no sé cómo se llama ahora a una empresa de reciente creación, pero bueno, no tenemos futbolín, aunque sí partimos de una situación más o menos estable en la que ya tenemos clientes y un producto en el mercado, así que entiendo que tampoco damos el perfil startapil al 100%).

En cualquier caso, una de las premisas iniciales del proyecto es ampliar el equipo técnico con una nueva incorporación. ¡Un nuevo fichaje! Estoy ilusionado, pasar de 3 a 4 es mucho, para algunos no significará nada, pero para mí supone colocar la cuarta pata a una mesa que espero aguante mucho tiempo.

Las primeras preguntas que tuvimos resolver fueron qué perfil buscar y que sueldo ofrecer.

En cuando al perfil (y después de mucho divagar), apostamos por un full-stack centrado en tecnologías .NET. Es decir, un back-end (ASP.NET MVC, Web API, Entity Framework), pero que se defienda razonablemente bien con Javascript y jQuery. La verdad es que perfil es un clon de nosotros mismos. Esto puede ser bueno o malo según como se mire, pero por ahora apostamos por el músculo y en ahondar en lo que ya sabemos (por ahora los experimentos con gaseosa).

En relación al sueldo, hemos determinado que podemos llegar hasta 33K… incluso negociables, fíjate tú. ¡Esto no puede fallar!, es un buen sueldo, ya sé que no es mega-sueldo pero tampoco es un mierdi-sueldo, yo creo (y si no es verdad me corriges) que para España no está mal.

Además, tenemos un buen horario (que por ahora más o menos cumplimos), de lunes a jueves de 8 a 17:00 y los viernes de 8 a 14:00. A mí me gusta mucho esa frase de “un ritmo de trabajo sostenible y sostenido”, es decir, si el éxito de la nueva empresa depende de que nos quedemos echando horas por sistema, claramente algo está mal.

Y con estos mimbres nos lanzamos al mercado laboral seguros de encontrar a un nuevo compañero…

Y a partir de aquí empieza nuestro vía crucis.

Lo que en principio parecería iba a ser una tarea sencilla se está convirtiendo en todo un dolor de muelas. Podemos argumentar que yo no soy de RRHH, luego probablemente no manejo ciertas variables en una entrevista que seguro debería, pero a grandes rasgos intento ser cordial, respetuoso y crear un ambiente favorable para una conversación distendida (en el fondo incluso me siento culpable por tener que decidir si alguien es apto o no para un trabajo, pero ese es otro tema, es más rollo personal…).

Para la preselección de candidatos hemos optado por una empresa de recruiting (que para ser justos están esforzándose mucho por cumplir las expectativas), luego la gente que finalmente entrevistamos ya ha pasado un filtro previo en el que nos aseguran que la persona tiene una salud mental estable e incluso sabe de programación (al menos su CV así lo dice y en una entrevista con un no-técnico parten la pana). Por otro lado, yo me he preparado las típicas preguntas sacadas del típico post ¿Qué preguntar cuando entrevistas a un candidato? Por ejemplo, ¿Te gusta lo que haces? ¿Te formas? ¿Cuál es el mayor reto al que te has enfrentado? ¿Te gusta trabajar en equipo? (todavía nadie ha contestado que no, pero tiempo al tiempo…) Vamos, que me siento ridículo en esta parte de la entrevista y en ese momento tanto entrevistado como entrevistador seguro lo estamos pasando muy mal.

Como al principio invertimos mucho tiempo en ver gente que tenía importantes suficientes carencias técnicas llegamos a la conclusión de que el filtro previo de la empresa de recruiting tenía que incorporar una pequeña prueba técnica (no para que ellos la evalúen, sino para que nos manden los resultados y así tengamos algo más de contexto antes de decidir si ver o no a la persona).

Esa primera entrevista técnica es la siguiente:

  • POO
    • Diferencias entre una clase abstracta y una interfaz
  • ASP.NET MVC
    • Diferencia entre @Html.Partial y @Html.Action
    • Diferencia entre @helper y @functions
  • ASP.NET WebAPI
    • ¿Para qué sirve [HttpGet] y [HttpPost]?
    • ¿Para qué sirve [FromUri] y [FromBody]?
  • Entity Framework
    • Diferencia entre Database First y Code First
    • ¿Qué hace DbSet.Find?
    • Diferencia entre IEnumerable e IQueryable
    • Lazy loading vs Eager loading vs Explicit loading
  • Javascript/jQuery
    • Hablando de eventos ¿Qué es la delegación?
    • ¿Qué es un closure?
    • ¿Qué es una promise?

Por descontado que no pretendo que nadie me dé una respuesta académica a cada una de las preguntas, pero sí por lo menos que en sus propias palabras conteste algo relacionado con el tema y que tenga cierto sentido.

También cabe decir que inicialmente (en mis mundos de arco iris y unicornios) había preparado un Word con más de 70 preguntas en distintos niveles o fases. Claro ¿Cómo iba a elegir de entre los buenos al mejor sino haciendo un poco de pair-programming con él e intercalando hábilmente preguntas de todo tipo?

Bueno, pues si vierais las respuestas lo fliparíais. Sólo 2 personas de 8 han contestado razonablemente bien. “Razonablemente” es una palabra que uso mucho ahora como medida de protección contra mi creciente frustración.

Ya después de esta selección hay una entrevista (que si puedo siempre hago por Skype). En esta entrevista intento (con más o menos éxito) hacer preguntas técnicas sin que parezca un incómodo interrogatorio. Voy a poner un ejemplo de cómo creo yo debería discurrir la entrevista:

“¿Qué opinas de los genéricos en C#? Y el tema de las lambas, qué movida ¿no? ¿Y cómo te llevas con las promises en Javascript? Oye, seguro que me puedes enseñar algo de código, ¿no? Mira, te voy a enseñar yo este otro código ¿Qué te parece? Y qué importante es el tema de lazy loading vs eager loading vs explicit loading en Entity Framework, ¿verdad? ¿Y los filtros en MVC?”

Y ya si la conversación va viento en popa le pregunto:

“¡Qué locura this en Javascript! ¿verdad? ¡Uff! Como ha cambiado el tema de los ValueProviders y ModelBinders entre ASP.NET MVC y WebAPI, ¡estos de Microsoft nos quieren matar!”

Pues te puedes imaginar, esta entrevista es imaginaria y no ha sucedido… y con franqueza no sé si llegará a suceder alguna vez. Siendo así, la pregunta que me hago es ¿En qué me estoy equivocando?

Si yo fuera mañana a hacer una entrevista de empleo, lo primero que haría sería colgar código en github o similar (si no recuerdo mal me van a querer contratar por mi código – además de por otras softskills, pero no es el tema del post de hoy). También me leería (y por qué no me estudiaría) los típicos posts de “Top interview questions about [inserta aquí tecnología/lenguaje]”.

Es cierto que eso no funcionará porque la entrevista no es un examen, no vale con la memoria a corto plazo, esto va de bagaje personal y de cómo encaras y has encarado la profesión… pero, en cualquier caso, optar a un trabajo de programador.NET en el año 2015 y no saber defender con una mínima coherencia las diferencias entre una interface y una clase abstracta me parece un pecado capital (IMHO). Igualmente, no me digas que haces front-end si no sabes (ni te suena) lo que es promise o closure.

En este punto queda claro que algo está fallando. ¿Posibles reflexiones? Yo hago las siguientes.

¿Tendré una visión distorsionada del mercado laboral y por 33K tengo que contratar a un padawan en vez de a un señor programador? Puede ser, yo creo que no, que es un sueldo majo, pero ya dudo de todo…

¿La gente buena ya está pillada (y cobrando un sueldo igual o superior al ofrecido) y además cambiar la comodidad y seguridad de una antigüedad no les hará atractivo el proyecto?

Yo asumo que quien venga tendrá un periodo de adaptación y no será parte productiva real del equipo hasta que no pase un tiempo. Todos necesitamos un periodo de adaptación, conocer la empresa, sus miserias y virtudes, descubrir el dominio del negocio en el que se está trabajando e incluso aprender a contar hasta tres cuando te toque lidiar con código legacy, porque sí, amigo, de ese código “viejuno” hay mucho, también hay código “fresquito”, nuevo y rimbombante, pero del otro hay más y no podemos renunciar a ello, pero lo que sí tengo claro es que si dices que sabes Code First y no te suena el método OnModelCreating… mal vamos… venga, vale, que usas DataAnnotations, aceptamos barco…

¿Realmente el nivel “general” (nótese el entrecomillado) en España es el que yo creía que era? De nuevo aquí podría ser que tuviera una percepción equivocada respecto a este tema y en esto tiene mucha culpa Twitter, los blogs, ¡la comunidad! Reconozco que lo último es echar la culpa a la comunidad, ¡pobre ella! J pero es que yo quiero en mi equipo gente que quiera salir de su zona de confort, perdón, rectifico, gente que YA haya salido de su zona de confort, y eso está siendo muy difícil, y eso sólo lo veo en la gente de Twitter, en la gente que participa en cualquiera de los bolos de MsCoders, Madrid.NET, Formación Tajamar o similar (y participar es “ir”, “oír”, no significa ser el ponente).

Tampoco pretendo con este post encontrar respuestas a mis problemas (que seguramente serán los problemas de muchos) pero al menos sí espero poder ver a gente conocida y en vez de contarles mi película, que ya la hayan visto y me den su más sincera opinión, yo la agradeceré.

Actualización de hoy mismo: No dejes de leer los comentarios, de veras, son todos muy oportunos y valen más que el propio post. Si tuviera que volver a escribirlo probablemente ya sería otro. El objetivo principal del post (que no era otro sino recabar opiniones y aprendar con ello) se ha cumplido y con creces. He cambiado de opinión en algunos puntos y eso es bueno, no me cuesta reconocerlo, cambio mucho de opinión. Y por cierto, aquí está el enlace de la oferta https://betabeers.com/post/programador-fullstack-net-2379/

Un saludo!

38 comentarios:

  1. Efectivamente, el nivel en este País deja mucho que desear, y ese sueldo no esta mal, pero conozco muchos desarrolladores que cobran más y no saben ni los conceptos básicos de POO. Yo intentaría buscar alguien con potencial, capacidad y ganas de llegar a ese nivel, antes que a alguien que ya tenga ese nivel y experiencia, os haréis un favor mutuo...

    ResponderEliminar
    Respuestas
    1. Desde luego es una opción, la aptitud (seas padawan o no) tiene que ser positiva, sino da igual lo que sepas, no eres un buen trato. :( Lo que no deja de sorprenderme es tener esa carencia de conocimientos y optar a un sueldo así (que a lo mejor es normal, pero yo pensaba que no). Claro, por un lado es positivo, no creo que a los programadores que se esfuercen les falte trabajo, pero por otro lado y en una empresa donde (hoy) no hay tiempo de excesiva formación sino que tenemos que sacar un producto adelante, pues es un handicap fuerte. Iré contando por aquí el desenlace, gracias por comentar!

      Eliminar
  2. Hola crack, bueno, aunque un poco lejos de españa, 100% de acuerdo contigo, algo pasa con esos seniors de 12 años de exp que aun no saben que ea visual studio (es real), cuando he tenido la oportunidad de evaluar tecnicamente (solo tecnicamente) de verdad que uno se asombra del nivel promedio tan bajo, y eso que las preguntas realmente son sencillas... En fin, creo que ahora los devs digamos que abundan, pero aquellos que quieren conocer algo mas, trasnochar par dias a la semana son muy excasos... Para cerrar, mucha suerte crack, y como dicen las ex(las malas) no eres tu son ellos

    ResponderEliminar
    Respuestas
    1. jajaja, me ha gustado ese cierre "no eres tú, son ellos"
      Mucha de la gente que ha venido viene de consultoría y aunque la aptitud es buena tengo la sensación de que el anonimato que te da la masa (una empresa grande) no juega a tu favor para el desarrollo personal (en otros temas una empresa grande sin duda será mejor).
      Al final, los buenos están cogidos... o están lejos :-)
      Siendo así, o encontramos un diamante en bruto (como decía el comentario anterior) o pagamos más y hacemos ofertas a programadores "conocidos", no parece que haya otra.
      Gracias por opinar, Julio, eres un tío grande!

      Eliminar
    2. gracias a ti Sergio, el tema del comentario de arriba es... es que eso que preguntas TODOS deberian saberlo! son cosas muy simples, y si es un diamante en bruto deberia mostrar ganas de aprender y notarse que se preocupa por estudiar un poco! En esta area es necesario ser estudioso, dedicado y esforzarse por aprender y estar actualizado, pero al parecer no muchos hacen eso.

      Mucha suerte y ya nos contarás!

      Eliminar
    3. Pues eso, me reafirmo entonces, son preguntas "must-know", si no las sabes defender (el cuestionario básico) algo falla

      Eliminar
    4. No no, un buen programador conoce más de una tecnología. Quizás se mueve bien con Python o Go, conoce muchos frameworks, tiene muchos proyectos interesantes en github, tiene un buen puntaje en SO y quizás sea un cryptoanalista como hobby. Y tiene que saber qué hace DbSet.Find? y la diferencia entre IEnumerable e IQueryable?

      No muchachos, ustedes viven en un ecosistema que solo puede ser observado mediante un microscopio y por lo tanto buscan a alguien que viva en la misma gotita de agua que ustedes, y eso es muy difícil de encontrar.

      Saben que los respeto mucho así que no se ofendan por favor, pero levanten la mirada y reconozcan que existe mucho más y que no todos están en lo mismo.

      Saludos

      Eliminar
    5. Estoy de acuerdo contigo, Lucas. Hago el ejercicio de auto-crítica. Mi universo es muy pequeño y gracias a vuestros comentarios hoy estoy aprendiendo un montón, pero el problema es que llegue alguien diciendo que sabe EF y no sepa muy bien que hace DbSet.Find. Otra cosa es que dijera que no ha trabajado nunca con EF, hay sin problemas.
      En cualquier caso por mí no te preocupes, no me ofendo, de hecho que Julio, tú y yo tengamos esta conversación es genial. El post lo he escrito con ese propósito, aprender que estaba haciendo mal, luego la crítica constructiva bienvenida sea :)

      Eliminar
  3. Genial es post.

    Pudiera ser que los eventos que citas (MsCoders, Madrid.NET, Formación Tajamar... ) sean los lugares adecuados para buscar al candidato que buscas.

    Por otro lado, por si te sirve de algo, mi trabajo actual lo encontré directamente en StackOverflow, donde viendo las preguntas/respuestas del inscrito y como evoluciona la complejidad de dichas intervanciones a lo largo del tiempo te podrías hacer una idea (aproximada, pero algo es algo) de la valía del candidato.

    Saludos!

    ResponderEliminar
  4. Pues es otra idea, aunque no tengo "ninguna" esperanza de que ningún candidato de los vistos tenga perfil de StackOverflow, eso sería ya de nota!
    En cuanto a buscar ahí, en los eventos y demás, lo voy a empezar a hacer, la verdad es que no he promocionado (ni contado casi) el tema de la selección a nadie, pero claramente hoy lo he hecho público y en breve publicaré la oferta real para que cualquiera pueda verla.
    Gracias por comentar Jonathan, una opinión autorizada :)

    ResponderEliminar
  5. Yo sufro el mismo problema a menudo. Nunca encuentro lo que quiero y eso lo doy por hecho, lo asumo, pero es que lo que encuentro es muy muy muy malo.
    Cero iniciativa, dejadez absoluta y cero ganas de saber más, muy flojos la verdad.
    En la última le pedí a mi jefe que uno de los requerimientos básicos fuera tener perfil en StackOverflow o en GitHub, ... poco menos que se rieron de mi.

    Es frustrante.

    ResponderEliminar
  6. "poco menos que ser rieron de mí" gran frase, tristemente :(
    Gracias por opinar!

    ResponderEliminar
  7. Es complicado encontrar gente con buena cualificación. Tener un buen nivel exige mucho esfuerzo, mientras que el mercado laboral no ofrece grandes recompensas.

    Personalmente creo que es un error acudir a empresas de "recursos humanos". Se dedican a filtrar a la gente por cuestiones no técnicas y realizan valoraciones muy subjetivas. Esto genera que posibles candidatos muy válidos sean desestimados.

    En mi caso ando buscando trabajo y creo cumplir muy bien el perfil que demandas, excepto por Entity Framework, soy más de NHibernate :D

    Tengo pendiente crear un "portfolio" que muestre lo que sé hacer. Considero que el currículum clásico está ya superado y no aporta gran cosa. Podría incluir aquí mi usuario de StackOverflow o incluso código que tengo colgado, pero prefiero no hacerlo por cuestiones de privacidad.

    Como referencia sobre mis intereses profesionales para mostrar un poco por dónde me muevo, estas son algunas de las páginas de la comunidad .NET española que suelo seguir:

    http://www.variablenotfound.com/
    http://blog.koalite.com/
    http://www.jasoft.org/blog/
    http://www.campusmvp.es/recursos/
    http://geeks.ms/blogs/

    ¿Valoras la opción de trabajo en remoto? Hoy en día con Skype y el control de código fuente distribuido se puede trabajar de forma muy eficiente a distancia. Si estuvierais dispuestos a ello aceptaría un sueldo considerablemente inferior a los 33.000 euros. Además también tengo muy en cuenta que sois un grupo pequeño y hacer frente a un gasto tan grande es un esfuerzo considerable. Estoy seguro que me ganaré un aumento de sueldo cuando mis aportaciones generen un incremento de los ingresos.

    El hecho de trabajar desde casa puede generar dudas entre quienes contratan. En mi caso aplico la metodología Pomodoro para asegurar que mantengo un buen nivel productivo.

    ResponderEliminar
  8. Buenas!
    Yo soy partidario de realizar preguntas técnicas en una entrevista, pero quizá estás buscando más un "clon" de ti mismo que no alguien que técnicamente pueda ser bueno.
    Yo quizá iría por preguntas más "genéricas"... como p.ej...

    1. Para una app móvil si elegiría Xamarin o Cordova o por qué.
    2. Si cree que otras soluciones como Titanium o React Native valen la pena o no
    3. Cuando hace reviews de código, en qué se fija?
    4. Qué opinión le merece el uso de un Garbage Collector? Qué problemas le ve? Es preferible usar ARC? RAII?
    5. Qué piensa de las aplicaciones SPA? Qué opina de Angular? De React? De Aurelia? De Backbobe?
    6. Qué opinión le merecen lenguajes como F#? Scala? Haskell? Clojure?
    7. Qué opinión le merece DNX/ASPNET5? Y nodejs? Y Java? PHP? RoR?
    8. Qué tipo de tests hace? Qué mockea? Cuando? Por qué?
    9. Si tuviese que definir una arquitectura para un proyecto X (ahí lo describes)... qué arquitectura eligiría? Qué tecnologías? Por qué?
    10. Hace TDD? Por qué? Y BDD?
    11. Qué opina de CQS? CQRS? DDD?
    12. Qué nota le pone a su propio código? Por qué? Qué hace para mejorar?
    13. ORMs sí o no? Y Micro-ORMs?
    14. Como manejar los cambios de esquema de una BBDD?
    15. Git o TFS? Por qué? Quizá algún otro?

    Creo que ese tipo de preguntas te puede dar más información sobre si el candidato pilota de tecnología o no... por qué al final, según mi opinión, eso va más de las ganas y la capacidad de aprender, de si sabe o no si se ejecutan en MVC6 los OutputFormatters para el content-type application/x-www-form-urlencoded o para el content-type application/json.

    ;-)
    Saludos!!!!!

    ResponderEliminar
    Respuestas
    1. Gracias por opinar Eduard,
      Tomo nota del cambio de orientación.
      Es más que probable (bueno, y sin el probable) que buscar un clon esté siendo un error. Creo que llevas razón en preguntar cosas menos directas que una pregunta concreta que venga seguido de un silencio incómodo (los nervios, que no has trabajando con ello o cualquier otra cosa...). Creo que intercalaré preguntas en la línea de las que propones con alguna otra que considere básicas sí o sí (aquí sigo pensando que hay cosas que no son opcionales).
      Pero sí, pillo la idea, algo voy a cambiar.
      Gracias!

      Eliminar
  9. Genial, Miguel, a día de hoy no es una opción trabajar en remoto (no es una decisión que recaiga sobre mí) pero si no tienes problemas en desplazarte a Alcobendas no tengo ningún problema en que tengamos una entrevista. Mi correo es panicoenlaxbox@gmail.com Si quieres seguimos por ahí :)
    Un saludo.

    ResponderEliminar
    Respuestas
    1. Muchas gracias por el interés, pero por el momento descarto mudarme de nuevo a Madrid. Acabo de empezar a buscar trabajo y en principio prefiero no cambiar de domicilio.

      Eliminar
    2. Como opciones para buscar posibles candidatos sugeriría:

      https://betabeers.com/post/
      http://www.stratos-ad.com/trabajo

      Patrocinar un envío de la #Bonilista también puede ser recomendable, aunque según dijo David Bonilla tienen reservas para varios meses.

      Eliminar
  10. Gracias Miguel, la oferta la acabo de publicar justo ahora https://betabeers.com/post/programador-fullstack-net-2379/
    A ver que tal! :)

    ResponderEliminar
  11. Hola,

    Vaya por delante que no soy ningún experto en contratar gente, lo he hecho pocas veces y no siempre he acertado (aunque las últimas me ha ido bastante bien).

    Creo que tienes ya unas cuantas pistas de cómo mejorar tu proceso, algunas ya las apuntabas tú y otras han surgido en los comentarios y en twitter:

    1) Si quieres gente activa en twitter, blogs, github, eventos, comunidades... búscalos allí.

    2) Cambia el enfoque de las preguntas, y en lugar de ir a tecnologías concretas, pregunta más por fundamentos. Trata de detectar gente capaz de aprender y adaptarse a cosas nuevas, porque incluso aunque ahora contrates un experto en EF, si no es capaz de amoldarse a la librería X que vais a usar dentro de 6 meses, no te servirá de mucho.

    Nada de esto te garantiza encontrar a la persona adecuada, y es posible que si cambias el enfoque de las preguntas incluso te desanimes más porque al final es más fácil encontrar gente que haya memorizado el API de EF para una certificación, que gente capaz de entender el por qué de esa API, pero al menos creo que te acercará a tu objetivo.

    Por cierto, ya que ha salido el tema del teletrabajo, yo prefiero la comunicación "cara a cara", creo que por mucho Skype/Slack/DVCS, nada gana en productividad a una conversación directa y unos garabatos en un papel.

    Pero, dicho esto, también creo que la cuestión no es si es más efectivo trabajar en remoto o en local, sino si el mejor candidato que puedes contratar en remoto, aun contando con la (previsible) bajada de rendimiento, supera al mejor candidato que puedes contratar en local.

    Un saludo afectuoso y mucha suerte!

    Juanma.

    ResponderEliminar
  12. Hola Sergio,
    Esta, creo, es una problematica globalizada, por acá en Colombia también he tenido que vivir algo similar a lo que expones y tuvimos que probar disintas soluciones
    El trabajo remoto tiene bastantes complicaciones pero nada que no se pueda solucionar, recibirías una gran cantidad de postulantes, seguro, pero ahí si que podrías filtrar por perfiles de github, stackoverflow ó hasta twitter. Por otro lado, para tu necesidad de trabajo presencial creo que la mejor solución es buscando en eventos de desarrollo ó en streamings.

    ResponderEliminar
  13. Hola Sergio, creo que al día de hoy he realizado no menos de 200 entrevistas y siempre me sorprendo de la mayoría de los candidatos. He probado con todo tipo de preguntas y enfoques sin ningún resultado. Incluso una vez escribí sobre algunos de los entrevistados mofándome de su nivel técnico, de lo cual hoy me arrepiento. Pero luego descubrí algunas cosas interesantes que me han llevado a la conclusión de que el problema en gran parte ha sido siempre el mismo: yo. Quiero compartir contigo algunos puntos:

    1. Desviar una bala de un balazo.
    Esta es quizás la más común de todas y se produce cuando el entrevistador pregunta sobre cosas que él usa a diario en su proyecto y en las que es un prácticamente experto. En este caso uno no logra nunca saber qué es lo que el entrevistado sabe, lo único que uno averigua es qué cosas, de las que yo se, él también sabe. Esto no es ni siquiera la intercesión de conocimientos de ambos puesto que el entrevistado no me puede preguntar a mí qué es lo que yo sé. Y por último, puesto que en un campo tan amplio uno solo sabe el uno por millón de todas tecnologías, es muy difícil que el entrevistado pueda responder aceptablemente a muchas preguntas.

    2. Solo se que no se nada
    Lo interesante no es que el entrevistado sepa lo mismo que uno, lo realmente enriquecedor es la incorporación de conocimiento que el equipo no tiene lo que fortalece y merece la pena tener en cuenta porque para crecer hay que incorparar más conocimientos y mas diverso porque un equipo en el que todos saben mucho de mvc y ef es un equipo que no sabe nada de nada.

    3. Argentina nunca va a ganar un mundial
    Uno muchas veces cree que solo se trata de encontrar al jugador correcto, que el mejor equipo es el que tiene a los mejores jugadores pero lamentablemente eso no funciona. Lo más importante es cómo encaja una persona en un equipo, que aporta. Incluso aspectos no técnicos suelen ser determinantes muchas veces, trabaja duro? es curioso? aprende rápido?

    4. Una piedra colgando a 500 metros de altura
    Me ha pasado encontrar estas piedras, solo lo más inútil del mundo si no fuera que eso esa es simplemente una conclusión de un observador inadvertido como yo. Una piedra a 500 mts es puro potencial! Solo hay que dejarla caer para ver lo que es capaz de hacer! De nuevo el problema está en mi incapacidad de reconocer el potencial cuando veo una piedra colgando y no que el potencial no esté allí.

    Creo que hay otras formas de evaluar a los programadores, la mejor es dejarlos programar o ver qué cosas han programado pero incluso en el supuesto caso que no tengamos código para revisar, afinar el ojo suele ser necesario.

    Saludos

    ResponderEliminar

  14. Muy buen post Sergio.

    Yo creo que muchas veces se valoran los conocimientos concretos y no lo que pueda crecer una persona con lo que ya sabe. Por ejemplo, aunque me gustaría, no he tenido la oportunidad de trabajar con WebAPI. Sé lo que es, he hecho alguna prueba, pero nunca me he metido en faena. Y al final, por mucho que te formes en tu casa, cuándo más se aprende es peleando en la trinchera. A ser posible con unos buenos compañeros que te enseñen.

    Lo mismo pasa con otras preguntas de las que comentas. Algunas las sé, pero otras (igual soy el único que lo reconoce) no sabría responderlas con solvencia. Y quizá eso haría que no pasara el corte en vuestra entrevista

    Vale, no saber diferenciar una interface de una clase abstracta es de libro :-0, pero creo que a veces hay que intentar buscar el potencial. Si buscas conocimientos brutos, que se puedan aplicar en una empresa determinada, es difícil encontrar al candidato perfecto.

    Suerte !!!

    ResponderEliminar
  15. @Juanma Gracias por tu aportación, como siempre muy acertado con la reflexión de buscar a un experto hoy que mañana quizás no lo sea.

    Las pistas para mejorar el proceso ya estan muy claras (gracias a toda la interacción que ha habido en twitter y en los comentarios del post).

    En cuanto al teletrabajo, y no se si por suerte o por desgracia, no está en mi mano el decidir, no se sopesa el trabajo remoto en mi empresa, así que al menos elimino una variable de la ecuación. Si te refieres a realizar la entrevista vía Skype, he optado por ese método después de haber invertido tiempo físico y no haber conseguido resultados. A este respecto no tengo una opinión clara, conocerse en persona es un plus, eso está claro, pero con los horarios apretados que tenemos todos hoy en día (y sobre todo los entrevistados que tienen normalmente trabajo) es más fácil coincidir en Skype que en vivo.

    @Jonathan Manrique Como decía, hoy por hoy no consideramos trabajo en remoto, quizás eso nos cierre algunas puertas (bueno, nos las cierra seguro), pero entre imposiciones de la dirección y que yo mismo no estoy muy convencido de la solución, por ahora un problema menos :)

    @Lucas Ontivero Lucas, mil gracias! Interesantísimos tus apuntes sobre el tema. Está claro (y ahora lo veo claro y nítido aunque esta mañana lo veía todo nublado y borroso) que YA se en que me equivocado (al menos en parte). Centrarme tanto en preguntas concretas ha sido un error, un gran error. De hecho (y como dices tú) el error he sido YO (y eso no quita para que siga pensando que la gente que he visto, no eran ni serían mi tipo... aunque cierto es que ahora lo digo con la boca más pequeña). Creo que quizás el poco margen de error que tengo (empresa pequeña) me ha hecho tener visión "tunel" y apostar por el clon, cuando eso no mejorará nada. Lo único que sucederá es que seremos más bocas que alimentar pero el crecimiento a la hora de sacar trabajo no será exponencial, y sobre todo no podremos aprender los unos de los otros.

    Respecto a tus ejemplos decirte que han sido acertadísimas, entre esto y el resto de comentarios del post, hay que ser ciego para no ver que el proceso es muy, muy mejorable. Desde YA voy a cambiar drásticamente el guión de las entrevistas. Lógicamente seguirá habiendo preguntas must-know pero las orientaré a conceptos transversales... u ortogonales como dice uno que yo me sé :)

    @Ruben Pues me matas, sinceramente, entre tu comentario y los de Juanma y Nicolo en twitter (que decían lo mismo), pues blanco y en botella. ¿Qué no te voy a contratar a ti? :) Si es precio tiramos el proyecto abajo y lo volvemos a levantar con "tus" tecnologías. Ya en serio, sois todos gente a los que tengo en muy alta estima, luego sería de tontos no replantearse como están discurriendo las entrevistas. Siempre he dicho eso de "contrata a alguien por lo que pueda llegar a saber y no por lo que sabe". Antes lo hice y me fue bien, pero la presión de los objetivos en esta nueva empresa ha podido conmigo y me ha nublado el juicio, así de claro. Botón Reset y a empezar de nuevo!

    En general, gracias a todos los que habéis comentado, la sesión de auto-ayuda aquí y en twitter ha sido brutal e impagable, hoy he empezado el día abajo y lo acabo arriba y con muchas ganas de volver a ver gente e intentar no cometer los mismos errores.

    Un saludo y gracias.

    ResponderEliminar
  16. Hola Sergio,
    La misma problemática por acá en Argentina, yo creo que el tema es simple, oferta-demanda, el nivel de demanda actual y la baja oferta de gente calificada hace que pase eso: que haya gente con poco nivel cobrando sueldos muy altos y que cueste mucho encontrar gente capacitada (hay mucho programador "verde" que salió de golpe al mercado por la demanda)
    A nosotros lo que más nos resulta son los referidos, probamos muchas cosas y en definitiva es lo único que dio resultado real.
    Un abrazo!

    ResponderEliminar
    Respuestas
    1. En todos los sitios cuecen habas! :)

      El "referido" (como decís allí) sería la primera opción sin duda, pero ya gasté esa bala una vez y tampoco tengo muchas más en la recámara.

      Gracias por comentar, un saludo

      Eliminar
  17. Estoy de acuerdo con Ruben. No puedes cerrarte en la entrevista a la tecnología en cuestión... disto mucho de decir que yo sea un crack, pero no me considero mal desarrollador, y más o menos estoy al tanto de la tecnología... sin embargo, y por razones laborales, nunca he hecho nada en ASP.NET MVC, o en WebApi, y no sabría contestar a la mitad de las preguntas que has puesto ahí... (sin embargo, he hecho servicios web en otras plataformas y he trabajado con MVVM, MVP e incluso MVC en otras plataformas no .NET. Llevo escribiendo C# de forma profesional desde prácticamente el día que salió la versión 1, WinForms lo conozco hasta las entrañas y tengo algo de experiencia con WPF.

    Creo que con la experiencia que tengo y un proyecto real no me sería dificil hacerme con ellas si se diera el caso: ahora bien, y esto es lo importante, me pillas así de sopetón en una entrevista y me preguntas para qué sirve [FromUri] y [FromBody], y me dejas pillado.

    Y tengo perfil en Stackoverflow (y no de esos de 200 puntos que te dan por estar 3 años) y Github :-)

    Obviamente, puedes preguntar lo que tu creas conveniente, y quizá te interese contratar directamente a un experto en -exactamente- ASP.NET MVC y ahorrarte el periodo de formación, pero personalmente considero que si contratas a alguien que sea un "buen desarrollador", y conozca las tecnologías de desarrollo y el concepto (en este caso el concepto web), te da un poco igual, dado un proyecto real y con un equipo de trabajo al que consultar las dudas básicas que a todos nos surgen cuando cogemos una nueva tecnología, dudo que una persona así tardara más de una semana en ponerse las pilas con él.

    Y al contrario también: si coges a un becario que ha trabajado de junior en una consultora, sin prácticamente experiencia, pero que por chiripa le ha tocado usar ASP.NET MVC en el único proyecto que haya hecho, te sabrá contestar a casi todas esas preguntas, y sin embargo será una "mala adquisición", a la larga os generará un montón de problemas (producidos por la falta de experiencia, todos hemos pasado por ahí).

    Conste que no estoy buscando trabajo y te escribo esto únicamente por si te ayuda...

    Creo que los filtros (tanto los pre-filtros en la empreas de recruiting como en la entrevista) no deben estar tan centrados con "las tecnologías que estáis usando ahora", y deberíais buscar a alguien que tenga experiencia y sepa adaptarse bien a cualquier cosa que le pongan por delante.

    ... y ojo, que me consta que no es nada fácil :-)

    Mucha suerte y un abrazo

    ResponderEliminar
    Respuestas
    1. Gracias por darme tu punto de vista, te lo agradezco mucho :)

      Además, lo que has dicho de que pueda venir alguien que sepa justo contestar lo que pregunto (por algún azar de la vida) pero no sepa lo que no pregunto y presupongo, pues una buen dato. No lo había pensado. Esta en la línea de lo que decía @Juanma, a lo mejor es más fácil aprenderse la API de memoria pero no haber agarrado el concepto y la larga será peor para todos.

      Eliminar
  18. Muy buenas Sergio,

    No nos conocemos; he encontrado tu blog vía Antonio García y mi compi David Pelaez. Mi opinión discrepa un poco de la mayoría.

    Yo llevo más de 10 años en esto. Si yo buscara un programador, no perdería el tiempo en preguntas "concretas"; por supuesto solo mantendría las preguntas basadas en lo de siempre... en código puro y duro.

    clases/métodos abstractos / herencia / interfaces / métodos/propiedades virtuales / decoradores / un poco de patrones (no me preocupan en demasía) / inyección de dependencias / principios de BBDD / algo básico de BI(SQL Server, Oracle o lo que sea) y poco más.

    Más allá de esto, puros principios, ¿para qué indagar en términos específicos de plataforma? Vale, si, quieres un Full Stack Developer, ¿pero quieres un tío teórico que al final no te sabe tirar líneas de código en condiciones?

    Me astía, y mucho, las solicitudes de dioses al aparato. Conozco infinidad de gente en el negocio, ¿crees que por decirte que es closure/primise en JS es mejor que el resto? Ni de coña.

    Por lo tanto... la mejor prueba, y te reduzco tu lista al 20% es realizar una prueba "BÁSICA" de programar algo en base a unas especificaciones. MUY MUY BÁSICA, no se hasta que punto reducirla... hacer una simple librería.

    Eso sí, indicar el enunciado lo siguiente, "NO TE EVALUARÉ A QUE FUNCIONE... LUCETE".

    ¿Simple, a que sí? Quizás parezca osado esta opinión, pero coño, estoy harto de eruditos. ¿Sabes programar o no? Ponte a los mandos; creame esto de la mejor manera que sepas!!!

    Luego evaluas, y delimitarás ciertos bloques de código con asombro o astío; a partir de ahí ya puedes decidir.

    Estoy harto de eruditos, charlas MVP´s, imposiciones, etc. ¿Creamos código de una vez? ¿Nos divertimos discutiéndolo? ¿Me dices en que he fallado? ¿Te puedo demuestrar que esto es mejor?

    Hemos perdido la dignididad del oficio con "preguntitas".

    Sin acritud Sergio.

    Un abrazo
    Daniel Leiva

    ResponderEliminar
  19. Un placer Daniel! No te preocupes, si he escrito el post es porque la situación me incomoda algo/bastante, así que cualquier opinión es válida y la valoro. Sólo el mero hecho de que la gente invierta un tiempo valioso en darme su punto de vista es ya un triunfo! :)

    Por otro lado, entiendo perfectamente lo que dices, al final esto va de tirar código, ni más ni menos. No dudo que ningún programador serio puedo reciclarse en cualquier tecnología en un tiempo record, pero si todo mi trabajo gira en torno a unas tecnologías concretas, es difícil que la cabra no tire al monte y mi primera intención sea contratar a alguien que tenga una aterrizaje suave. ¿Significa eso que alguien que no sepa ASP.NET no vale para el puesto que ofertamos? Pues ya no, esta mañana estaba algo obcecado con eso, pero ahora revisaré ese planteamiento. No se en que punto medio me quedaré, pero tampoco me puedo ir de Málaga a Malagon. Es decir, yo creo que si tocas web de la parte cliente (y me da igual la tecnología o framework que uses) tienes que saber sí o sí que es una promise. Probablemente un closure no lo expliques bien, yo no lo haría, pero al menos te tiene que sonar, si no es que me cuesta creer que trabajas en web en la parte de cliente. ¿Y si aparece un programador bueno de escritorio (cualquier historia relacionada con desktop) pero no sabe nada de web? Pues yo que sé, entonces cambio la oferta y sencillamente busco un programador, pero claro, entonces no estaría ni medio-alineado con la dirección que lleva la empresa. Si ya me esta resultando dificil evaluar a alguien por algo más o menos concreto, si voy sólo y exclusivamente al concepto "programador" creo que será aún más difícil encontrar/decidirme a alguien y me puedo encontrar en una empresa 100% .NET con un excelente programador de Ruby (por ejemplo) que tiene que aprender, así de golpe y sin escape posible, una buena pila de frameworks nuevos.

    Sólo por curiosidad ¿Yo nunca he visto ese tipo de ofertas? Digo yo que algo habrá que afinar, ¿no?

    En cuanto al código, y como te decía al principio, así si te doy toda la razón, voy a ver si planteo un "enunciado" sencillo y en directo hacemos un poco de pair-programming, eso puede ser una solución magnífica. Aunque por otro lado, ya he hecho un par de intentos y no creas que todo el mundo está dispuesto a programar en una entrevista, entiendo que bien porque inseguridad, bien por nervios o bien porque tristemente les he minado previamente con preguntas concretas tipo test (perdón de nuevo porque esta mala práctica), pero me he encontrado eso.

    Entiendo que NO querer programar en la entrevista ya dice mucho del entrevistado. :( Y que conste que según qué caso, estaría incluso dispuesto a ir un sábado a la oficina o programar vía Skype para que el tema del cansancio del día no sea una excusa (todos sabemos que a poco que te pongas se te van las horas rápido y entre diario es un poco "movida").

    Mil gracias por darme tu opinión, Daniel, de verdad, gracias

    ResponderEliminar
    Respuestas
    1. Yo nunca he hecho un proceso de selección. No me ha tocado ese marrón, pero siempre he pensado que una buena opción sería poner un ejercicio práctico a los candidatos. Una especie de práctica sencilla como las que se hacen en la universidad. Que el candidato la resuelva en su casa, tranquilamente y sin nadie observando.

      Luego ya en una entrevista cara a cara, se comenta la solución y ahí seguro que salen bastantes conceptos para analizar.

      No sé, a mi programar delante de alguien a quién no conozco, me pone un poco nervioso. ¿Qué pensará si no me sé un determinado atajo de Visual Studio? ¿Y si doy demasiadas vueltas para encontrar una opción qué no suelo usar? ¿Y si tengo que usar Stack Overflow para buscar esa duda recurrente que siempre tengo que mirar?

      Yo creo que es buena idea.

      Eliminar
  20. Hola que tal, antes que nada, seguro que yo lo haría mucho peor que tú así que no soy nadie para criticar tus métodos de selección, pero creo que el problema que tienes es que tu selección peca de frameworkitis. Yo me centraría más en la parte del core del lenguaje a usar (C#, JavaScript) y haría preguntas como algunas que has hecho (diferencias entre abstracto e interfaz, que es un closure o un promise) y la potenciaria con más preguntas relativas a patrones de diseño o metodologías (programación asíncrona, etc) y demás más allá de cómo ese patrón se llame en diferentes frameworks. Usar un framework más o menos bien, con una buena base, es fácil. Me parece mucho castigo que sólo por el hecho de no haber usado Entity Framework, por ejemplo, mucha gente quede descartada de la selección, cuando conceptos como el Lazy o el Eager loading existen en la mayoria de ORMs, aún usando otros nombres. O a lo mejor, en vez de WebApi ha usado OpenRasta y los conceptos son los mismos pero con otra nomenclatura.

    ResponderEliminar
  21. Hola Michael,
    No te preocupes, crítica, que esa la idea. :)
    Después del tuyo y otros muchos comentarios, estoy de acuerdo en lo que dices, de hecho siguientes entrevistas las orientaré de otra forma, centrándome más en conceptos y menos en un framework o API en concreto. Cierto es que sería deseable que tuvieras experiencia en las tecnologías concretas que se demandan para el puesto, pero intentaré no caer en el error de sólo centrarme en eso.
    Es complicado, pero gracias a toda vuestra ayuda, tengo ahora más claro el cómo abordarlo.
    Un saludo.

    ResponderEliminar
  22. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  23. Leyendo todos los comentario y para no ser redundante. Creo que lo único que podría recomendarte es que enfoques esa entrevista a conceptos generales con énfasis en las tecnologías que manejas. Puedes encontrar a alguien que tenga muy buenas bases, pero si su curva de aprendizaje va a durar 2 o 3 meses para que sea viable su contratación, ahí habrá un problema.

    Algo que propuse en la empresa que laboro y que han adoptado muy bien, es un semillero. Generalmente cuando la empresa requiere alguien, un nuevo dev, etc... Es como si se iniciara una nueva relación de golpe. ¿Cuantas relaciones en la vida real son así? ¿El amor a primera vista funciona? Puedes aplicar esto para tu empresa. Obviamente no para esta contratación, pero si para un futuro. Crea tu grupo de aspirantes e instrúyelos progresivamente. Que ellos conozcan el trabajo de tu empresa y que tú conozcas su trabajo. No es algo utópico, muchas empresas lo hacen. ¿Cuál es la diferencia? Ninguna. Así en el momento de que ya puedas hacer la incorporación, simplemente escogerás el mejor.

    ResponderEliminar
  24. Te lo digo claro. 33000€ para un buen programador, que él sepa que es bueno , es poco. No hace falta marear tanto la perdiz.

    ResponderEliminar
  25. Tomándome a mí como ejemplo: he manejado WPF/Winforms, C#, VB.net, ASP (MVC/Webforms), VB6, C, C++, Javascript, PHP, Python, JSP, Java, HTML, XML, CSS, assembler, NHibernate/EF/Dapper.NET, Lisp, Lua, Racket, Scheme, Spring FW, design patterns, SQL (MySQL, SQLite, SQL Server), VHDL, Matlab, entre otras muchas cosas. Jamás he tomado cursos, lo que sé lo he aprendido por mi cuenta, así que desconozco mucha terminología.

    Tengo una maestría en ciencias de la computación en la que me especialice en su momento en robótica, procesamiento de imagen, visión por computadora y optimización. Se trabajar en equipo y me entretienen los problemas complejos.

    En base a lo que describes, probablemente no me contratarías por que desconozco muchas cosas de las que pides (o que en los comentarios mencionan, si tengo o no cuentas en las redes no se los diría) y por lo que pagas, ni yo aplicaría para entrevista con ustedes.

    Un saludo.

    ResponderEliminar
  26. La clave al contratar una persona está en la capacidad que tenga esa persona de aprender y reciclarse y del tiempo que le de la empresa para ello.

    Hoy necesitas ASP.NET y EF, mañana ASP.NET Core y EF Core que ya es otro concepto, hay que cambiar todo el código y adaptarse al nuevo framework. ¿Cuántas personas crees que encontrarías a día de hoy que dominaran a fondo todo .NET Core y tecnologías asociadas?

    La clave está en las personas que les guste y disfruten con las tecnologías que solicitas y que la programación y sus tecnologías sean para ellas un reto y disfruten con ello y quieran realmente saber más y superarse así mismas y a lo demás.

    Te pongo un ejemplo. Contraté hace años a una persona y estábamos desarrollando una aplicación en .NET 1.0 que acababa de salir. Programé un acceso a datos SQL Server y la carga de una tabla completa de un millón de registros me tardaba unos 10ms. Esta persona se picó y cuando llegué al día siguiente había hecho un código que cargaba la misma tabla en 4 ms. Este es el perfil de personas que hay que encontrar. Yo tuve suerte.

    Pero es como buscar una aguja en un pajar.

    Saludos a todos.

    ResponderEliminar