Preguntas al entrevistador que nunca harás

dilbert-job-interview-jpgHe recopilado algunas preguntas razonables, profesionales y serias, que sin embargo un entrevistado nunca hará a su entrevistador. ¿Tú las harías? Vamos a verlo:

¿Porqué debería aceptar su oferta de empleo?

Es una pregunta razonable, pero que nadie quiere hacer. Por mucho que a los empleados se les exija orgullo, liderazgo, bla bla bla, se trata de una pregunta arriesgada. Después de todo, el empleado es el único que debe ser capaz de demostrar algo en la entrevista de trabajo. ¿o no?

¿Qué es lo que retiene a sus trabajadores?

Es otra pregunta razonable. Los empleados vienen a quedarse. Ése debería ser su objetivo. Pero necesitamos saber ofrecerles elementos de retención a la altura del esfuerzo que les exigimos.

¿Cuál es su índice de rotación de personal?

Otra pregunta natural y responsable. Es una métrica, un indicador. Pero también tiene un significado, o al menos puede ser un indicativo de una situación (sin entrar en si es positivo o negativo, deseable o deleznable). Es un indicador que puede dar una falsa impresión, así que…¿por qué no medirlo y analizarlo? ¿por qué no podemos hacerlo con naturalidad?

Pero esta pregunta, en caso de que el entrevistador quiera evitarla o si incluso el entrevistador afirma que no se mide, surge una pregunta natural que de nuevo, el entrevistado puede sugerir de forma natural:

¿Si no está midiendo su índice de rotación de personal…por qué afirma que le preocupan sus empleados?

Fuente: Linkedin

Anuncios

La titulitis ha muerto

dilbert-university-mbaDe nuevo, seguimos viendo titulares que insisten en que las grandes multinacionales (en este caso es Google quien se suma al carro de otras como Microsoft, etc.), ya no miran el expediente académico.

¿Para qué sirve pues estudiar? Pues se está perdiendo la noción enquistada y del siglo pasado de que estudiar sirve como garantía para encontrar un buen empleo, para garantizar el éxito en la vida. Al final va a resultar que estudiar, sirve simplemente, para adquirir conocimientos, y no es una garantía exclusiva y universal de un empleo de alta remuneración.

Ya hace tiempo que se habla de ello, y es que la universidad prepara universitarios. Pero las empresas necesitan profesionales.

¿Qué ocurre ahora, al salir de la universidad? Pues que hay que ganarse el pan. Ya no sirve hacer un esfuerzo puntual durante un tiempo para sacarse el título. Ahora cada día es una prueba de aptitud, y se nos pone a prueba en nuevas y cada vez más complejas situaciones: se llama realidad competitiva profesional.

Después de todo, ya hemos hablado en artículos anteriores de los job-hoppers (*), que saltan de empleo en empleo para mejorar su situación laboral. Al contrario, las empresas también nos exigen cada día más un pequeño (y a veces no tan pequeño) esfuerzo de superación, de mejora. Pequeñas batallas que pueden terminar si o si de dos formas:

  • Triunfando, y por tanto, aprendiendo de las buenas prácticas y criterios aplicados.
  • Fallando, pero aprendiendo de qué se aplicó de forma incorrecta, o qué premisas eran inadecuadas para la situación.

Este tipo de corrientes de pensamiento supongo que molestarán a los que llegaron con su carrera universitaria y su MBA pensando que ya no tendrían que esforzarse. Que para ganar dinero basta SER y no HACER. Se les olvida recordar que el cliente paga por lo que recibe de nosotros, no por lo que somos.

Fuente:http://www.elmostrador.cl/noticias/mundo/2016/01/24/google-cambia-su-forma-de-contratar-personal-el-expediente-academico-no-sirve-para-nada/

(*) Como ya me comentaba una lectora en una entrada anterior, el término job-hopper no debe usarse para los que ven forzado su cambio de trabajo de forma constante, sino para los que lo buscan y fuerzan como una medida de garantizar una promoción laboral continua y sostenible.

Pesadilla en la oficina

Ahora que tenía este post pensado, me comentan que ya existe una entrada en youtube que parodia la serie “Pesadilla en la cocina”, pero en el mundo del software, es decir: “pesadilla en la oficina”. Pues ale, os adjunto el enlace para que disfrutéis del vídeo:


¿Os imagináis algo así en vuestras empresas? ¿Aguantaríais que alguien criticara tan duramente vuestro trabajo? Y ojo, no me vale la típica respuesta de listillo en plan “sólo si sabe mucho más que yo”. Las cosas son como son, nos la diga Chicote, el tal Alvarote del vídeo, o Rita la Cantaora.

Fauna laboral: el protegido

Dilbert-El-protegido

Hay quien lo llama enchufado, pero yo prefiero llamarlo el protegido. Después de todo, lo de enchufado es poco significativo, y por protegido entiendo que nos referimos al individuo que está liberado de marrones, no tiene que trabajar ni hacer nada salvo las peticiones especiales que su jefe le diga directamente. Cuando surge algo urgente o especialmente delicado, el protegido desaparece, hace su “mutis por el foro”, y de hecho suele estar ilocalizable.

El término enchufado, además suele utilizarse para “el hijo de…” o “familiar de…”, lo cual es inexacto.

Estos individuos los he podido observar en alguna de mis anteriores empresas, y existen diversas técnicas de actuación recomendables:

  • Estar cerca de ellos. Esta técnica intenta buscar que al estar junto a un protegido, estemos liberados de marrones, tareas infames de última hora, y proyectos imposibles. Por desgracia, los marrones que deberían ser responsabilidad de un protegido, pueden caer en sus alrededores. Es como si algo que sería responsabilidad natural de una persona, debiera de caer inherentemente en su área de actuación. No nos equivoquemos, el protegido estará ahí (no está muy lejos) para recoger los méritos y los laureles del triunfo.
  • Estar lejos de ellos. Esta técnica intenta evitar que los marrones nos salpiquen por cercanía de un protegido. Con suerte, podremos estar en un proyecto lo suficientemente complejo y alejado que haga que no se acuerden de nosotros. Sin embargo, esta técnica tiene también sus problemas, ya que los marrones tienden a caer lejos de los protegidos.

¿Cómo suele actuar el protegido?

  • Animal social. Se sabe protegido, por lo que da prioridad a las relaciones públicas, las sonrisas y los cafés. Su hábitat natural está junto a la máquina del café, aunque los más peligrosos son los que saben alternarlo con su puesto de trabajo, simulando una actividad febril.
  • Acompaña siempre a su protector. Sin él, no es nada y lo sabe. Sus actividades requieren de la constante supervisión y conformidad de su protector.
  • Rendimiento. Rinde lo menos posible, aunque lo verás teclear como si tuviera la enfermedad de Párkinson en cada uno de sus dedos.
  • Sólo le preocupa su marca personal. Esta característica la comparte con el trepa. Por supuesto, hay protegidos pasotas, pero rara vez mancharán su imagen profesional.
  • Transparencia. Simplemente, carece de ella. El protegido se limita a realizar las tareas oscuras y secretas que su jefe (o el jefe que los ha acogido bajo “su protección”) les ha encargado. Nunca sabrás qué hacen, ni para qué. Eso sí, todo será super-importante y muy urgente. Aunque todos sabemos que no es así, ya que de serlo, sería un marrón, que por definición, no les es nunca asignados a  los protegidos.
  • Actividad: el protegido está continuamente preparándose. Y me diréis, ¿normal, no? Pues no tanto, ya que como el protegido tiene mucho tiempo libre, suele estar preparándose para formarse (algún día puede que tenga que demostrar que sabe hacer algo) y para promover su marca personal.

Y tú, ¿conoces a algún protegido?

 

 

Principios SOLID

Estos principios, que supongo ya conoceréis todos, están orientados a los que se inician en la programación orientada a objetos. Después de todo, el sentido común ya nos orienta a este tipo de prácticas, pero es gracias a su recopilación, que los que empiezan pueden aplicarlas.

Ayer un compañero me comentaba: “Oye Roberto, a veces las nuevas incorporaciones las formamos mucho y bien en tecnologías, en frameworks y lenguajes de programación. Pero no les enseñamos realmente a programar”. Pensaba en la afirmación, y efectivamente, saber programar es algo mucho más complejo que saber un lenguaje o un framework. Es por eso que me he acordado de este post que llevaba mucho tiempo sin completar.

Por si algún despistado no conoce los principios SOLID, vamos a revisarlos.

Robert C.Martin, introdujo a principios de la década del 2000 este concepto. SOLID corresponde a 5 principios en los que fundamentar la orientación a objetos:

  • S: Single responsibility.  Principio de responsabilidad única. Cada objeto, debe dedicarse a una sola cosa. Si os fijáis, es una ampliación del concepto clásico de programación en el que un método o función debe tener un único propósito.
  • O: Open-closed. Las clases u objetos han de estar abiertas para su extensión, pero cerradas para su modificación. Este principio está directamente relacionado con la herencia en Orientación a Objetos.
  • L: Liskov substitution principle (principio de substitución de Liskov). Este principio promulga que todos los objetos deberían ser sustituibles por instancias de sus subtipos sin afectar al funcionamiento del programa. Es decir, que no debemos reimplementar los métodos en las clases heredadas, sino utilizar los de las clases base.
  • I: Interface segregation principle (principio de segregación de la interfaz). Este principio afirma que es mejor muchas interfaces cliente específicas, que tener una sola interfaz de propósito general. Este principio busca el desacoplamiento entre clases.
  • D: Dependency inversion principle (principio de inversión de la dependencia), donde Robert C.Martin nos indica que se debe depender de abstracciones, no de implementaciones. Por ejemplo, la técnica o patrón de inyección de dependencias sigue este principio.

¿Y tú, tienes en cuenta los principios SOLID a la hora de programar?

 

Cómo afrontar una entrevista de trabajo (1)

dilbert-entrevista-trabajoEmpiezo poniendo a esta entrada el número 1 porque ya preveo que va a dar para unas cuantas más. Y es que las entrevistas de trabajo son cada vez complejas, y no siempre es dicha complejidad proporcional al puesto de trabajo.

Hoy para empezar, veamos un par de preguntas que así, sin venir a cuento, le hacen a unos amigos en otra empresa, para puesto de programador con experiencia:

Pregunta #1: La cuerda que rodea la tierra

Pregunta: Suponiendo que la tierra fuese una esfera perfecta, si ponemos una cuerda que de la vuelta completa a la tierra por el ecuador y quede perfectamente ajustada a ella…si añadimos un metro a dicha cuerda, ¿cuáles de los siguientes objetos podrían pasar por el hueco que quedaría bajo la cuerda (una moneda, un gato, un vaso de vino)?

Respuesta: Resulta que se trata de un famoso problema matemático, una paradoja matemática que consiste en que el hueco que quedaría entre la tierra y la cuerda es exactamente el mismo, y sólo depende del tamaño de la cuerda añadida (y no del tamaño de la cuerda). Es decir, que si a una pelota de golf (o de tenis, o lo que os de la gana), le añadís un metro de cuerda, la distancia o hueco entre la superficie de la esfera y la cuerda…será exactamente la misma que en el problema inicial de la tierra (aproximadamente, unos 16 cm). Más información y detalle del cálculo del teorema que lo demuestra en: https://en.wikipedia.org/wiki/String_girdling_Earth

Pregunta #2: Una de interruptores

Hay 3 interruptores (de los de encender/apagar luces de toda la vida), en la planta calle de un edificio. Sólo uno de ellos apaga/enciende una bombilla del piso 3. Los otros dos, están conectados a cualquier otra cosa. Si sólo tuvieras una oportunidad de tocar los interruptores y subir al piso 3 (sin volver a bajar ni alterar los interruptores)…¿cómo podrías saber qué interruptor era el correcto?

Respuesta: La solución, en: http://www.scientificamerican.com/article/answers-to-puzzles-posed-in-let-the-games-continue/

Conclusión.

Por desgracia, estas preguntas tenían poco o nada que ver con la pericia técnica del trabajo para el cual se hacía la entrevista. Sin embargo, son preguntas que se suelen hacer en entrevistas de trabajo, en empresas como Google o Microsoft.

¿Os parecen preguntas adecuadas? ¿Creéis que realmente son objetivas de alguna forma? Ya hay voces de algunos responsables de RRHH que alzan su voz en contra de este tipo de técnicas. Pero eso, lo dejaremos para otro día.

 

 

 

 

 

7 Fallos habituales en una sprint review

Una sprint review parece sencilla. Pero como siempre, podemos caer en la dejadez, dejar de trabajar con rigor, cayendo en una serie de fallos habituales que os comento. Al final del post os dejo un vídeo que satiriza una sprint review. Pero empecemos con los 7 fallos habituales en una sprint review:

1.Expectativas de trabajo completado fuera del plan original.

Es muy típico esperar que se lleven a cabo tareas “extra”. Después de todo ¿no es eso ser ágil? Entonces, ¿porqué no incluir pequeños cambios o tareas adicionales, durante el sprint? Creo que todos ya sabemos que un sprint precisamente está pensado para acometer de la mejor manera posible, las historias de usuario planificadas. Nada menos, pero tampoco nada más.

2.Confundir estimaciones con compromisos.

Esto es también muy habitual. Una estimación no es más que eso. A veces las estimaciones son erróneas, y un sprint trata de acometer todo el trabajo planificado, pero a veces simplemente no es posible. Deja la historia de usuario sin completar para el próximo sprint, no sin antes asegurarte de ver porqué te equivocaste al estimar, no sea que en realidad haya más trabajo oculto del que creías.

3.Expectativas no realistas

Podemos tener expectativas no realistas de ausencia de errores, corrección de errores existentes, funcionalidades pretenciosas, hitos inalcanzables, etc.

4.El product owner que no actúa como tal.

El product owner puede que vea la funcionalidad por primera vez en la propia sprint review. Eso significa que no ha dado feedback durante su desarrollo, y que su labor de product owner no ha sido tal.

5.No mantener informado al equipo.

La comunicación y la información son claves. El equipo debe estar puntualmente informado de todo, pero especialmente de revisiones hechas sobre los objetivos del sprint.

6.Ver la review como una oportunidad para buscar culpables, en lugar de aprender y educar.

Esto es también muy típico en proyectos que se inician por primera vez en SCRUM u otras metodologías ágiles. Cuando algo falla, debemos investigar los motivos y buscar soluciones…no culpables.

7.Confundirlo con una retrospectiva.

Efectivamente, los conceptos de sprint review y sprint retrospective son bastante diferentes. Mejor dejaremos el detalle de su comparativa en un post dedicado a ellos y a sus diferencias.