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

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?

 

¿Te conviene trabajar desde casa?

Dilbert-Teletrabajo Los Millenials, esa raza aparte de la que hablaremos otro día, lo valoran. Estamos hablando del trabajar desde casa. Y el trabajar desde casa ha sido objeto de un artículo muy interesante en LinkedIn.

Pero analicemos un poco el artículo, ya que ponen al hecho de trabajar desde casa como un lastre en la carrera profesional. Claro, desde casa es sencillo realizar el 99% de las tareas. Pero por ejemplo, ya no es tan sencillo liderar. Y no hablo de dirigir a un equipo, sino dar ejemplo, y ser el líder que todos desean ver hacer y que guía al equipo.

¿Significa esto que no se puede ser jefe trabajando desde casa? No, pero en el artículo se plantea que a la hora prosperar en la carrera profesional, es más sencillo hacerlo de forma personal en la oficina, o codo a codo con el equipo en el cliente (o donde sea). Es en ese día a día en la oficina, haciéndose ver, donde  se genera la confianza para que los responsables te tengan en cuenta a la hora de promocionarte profesionalmente.

Aquí es donde viene la pregunta: ¿te conviene trabajar desde casa?

Pues tal como lo plantea el artículo, pues no, si lo que quieres es progresar profesionalmente a puestos de dirección.

Por supuesto, si entre tus objetivos están el no progresar rápidamente, sino realizar un trabajo a gusto, y con un adecuado balance entre la vida personal y la profesional, el teletrabajo es un punto a valorar.

El artículo está muy cargado de valores profesionales, y está muy bien dirigido. Sin embargo, no tiene en cuenta que está estableciendo una premisa: si quieres prosperar profesionalmente, debes dejarte ver. Que te vean trabajar, y que te vean haciendo cosas bien.

De nuevo, aquí extraemos algunas tristes conclusiones, dos de las cuales dejo a la reflexión de mis lectores:

  • ¿Y si mi visibilidad se reduce no por trabajar desde casa sino porque me mandan a un cliente? En ese caso no es porque queramos, sino que se nos saca fuera “visualmente”, impidiendo y coartando nuestra carrera profesional de forma ajena a nuestra voluntad.
  • Si se trata de dar visibilidad a nuestro buen hacer, ¿no estaremos fomentando que la gente oculte descaradamente sus errores o su “no tan buen hacer”? O lo que es peor, que se busquen culpables de cualquier situación, en lugar de afrontarlas y solucionarlas (tal y como se esperaría de un líder)

Así que tras darle muchas vueltas…vuelve a mi cabeza la pregunta:

¿Te interesa trabajar desde casa?

 

 

 

¿Eres un job-hopper?

job-hopperYa llevo unos días oyendo el término de Job-Hopper. La última vez ha sido leyendo un artículo de Forbes.

Después de todo, es un concepto antiguo en nuestra profesión. Pero antes de ir más allá con ello, vamos a ver su definición:

 

Un “job-hopper” es una persona que cambia de empleo con cierta asiduidad. No hay un límite definido, pero al menos 1 vez al año o cada dos años. También se les conoce con otros términos como “salta-empleos”.

Supongo que me estaréis diciendo. “Vale, ¿y qué?”. Pues que tenemos que tener cuidado con estos individuos. Me explicaré.

Estas personas suelen necesitar periódicamente nuevos estímulos, aprender cosas nuevas. Efectivamente, odian el estancarse y el hacer cosas similares todo el tiempo. Necesitan variación, adrenalina, novedad y enriquecer su intelecto con cosas diferentes. Hasta aquí suena bien, ¿no?

Los job hoppers suelen estar vinculados con cualidades negativas como la falta de responsabilidad, compromiso e inmadurez.También se cree que los job hoppers son individuos que carecen de seguridad laboral. Una persona que cambia frecuentemente de trabajo, podríamos pensar que tiene menos posibilidades de convertirse en gerente, ya que este tipo de posiciones exige una conducta de trabajo duro y constante en los empleados. Una desventaja que padecen aquellos que cambian frecuentemente de puestos de trabajo es que no consiguen tener el tiempo suficiente para especializarse en algunos temas.

Sin embargo, en un entorno laboral plagado de Millenials en el que ya no se valora la experiencia…¿a quién le importa? ¿Qué más da si has estado en 1 trabajo durante los últimos 10 años…o 10 trabajos durante los últimos 5 años?

Por desgracia, es más fácil prosperar profesionalmente y ganar cada vez más saltando de empleo en empleo, sin llegar a demostrar nada y dejando atrás los errores para que los arreglen los demás. No se valora el esfuerzo, el pensar a largo plazo y ya no hablemos de la deuda técnica, calidad del código y las buenas prácticas.

Sin embargo, he visto artículos en la red donde a estas personas se les valora positivamente el hecho de haber cambiado de empleo constantemente. De hecho, en entornos profesionales donde se trabaja por proyectos, es donde estas personas encuentran su hábitat natural. De hecho, hay empresas donde conforme se acaba un proyecto de un año…los profesionales empiezan a preguntarse por su futuro laboral, y es aquí donde los job-hoppers encuentran su lugar favorito, ya que no les tiembla al pulso al buscar empleo constantemente, pero especialmente conforme se acerca el final de dichos proyectos.

¿Y tú, eres uno de ellos, o conoces a alguno? ¿Te gustaría trabajar con un job-hopper?

PD: Gracias, Angel Granero por la idea de este post.

La línea de Base y los cambios en producción

branch-per-taskMuchos me diréis que a qué viene esto ahora a cuento. Pues me sigo encontrando muchos casos en los que hay programadores que no terminan de entender el concepto de línea base. Además, este concepto es fundamental para entender los cambios en el ciclo de vida del software, desde el entorno de desarrollo, hasta el de producción. Y no, no me refiero a permitir o no hacer cambios directamente en producción. De eso creo que ya hemos hablado. Me refiero a controlar los cambios en cualquier entorno mediante el concepto de línea base.

¿Qué es la línea base?

La línea base es un concepto de la gestión de la configuración (otro día hablaremos de ella). La línea base se define en el IEEE 600.12/1990 como:

Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios.

La línea base es un contrato. Un contrato igual que lo es una API, o el WSDL de un servicio web. La línea base establece en qué puedo confiar, porque es algo acordado (ni siquiera tiene porqué ser bueno, probado, excelente o definitivo). Hablamos de una versión de cada uno de los componentes software, que en conjunto, se ha acordado que es correcta en su conjunto. Pero sin suponer esto que cumpla los requisitos, ni las pruebas…simplemente es un hito.

Cuando trabajas con Subversión, TFS o Github, tenemos los conjuntos de cambios, tags o Changesets. Esas etiquetas o paquetes de cambios identifican el software en su conjunto, y son como una foto. Sí, como una foto del software en un momento y situación determinados del tiempo.

Aquí la idea no es versionar. No es un control de cambios. Es tener la posibilidad de devolver todo el código a un momento del tiempo en el que sabíamos que algo funcionaba (o no), pero al menos conocíamos su estado en conjunto. Esto es muy importante para controlar el estado de los entornos, para poder devolver un entorno (pruebas, desarrollo, calidad, preproducción, formación, producción), a un estado conocido.

Si la línea base es una foto, instalar una línea base es devolver a un entorno a un estado conocido, es un viaje al pasado.

Por ese motivo, jamás deberemos tocar el código en producción, ni en pre-producción, ni en otro entorno que no tengamos debidamente controlado con el correspondiente gestor (SVN, Github, TFS…). Porque si tocamos el código, hemos perdido la partida. Ya no podremos tener control de hacer una nueva “foto”, y empezaremos a perder el control de los cambios, de los entornos, del desarrollo.

Y claro que podemos coger ese código, hacer un checkout en desarrollo y poner ese código después para recuperar el estado del entorno de desarrollo. Y claro, también existe Santa Claus, y Blancanieves, y los siete enanitos. Si no lo hicimos en un principio, si nos hemos dejado seducir para tocar el código en producción y “jugárnosla”, hemos perdido el control y ha dejado de jugar a nuestro favor todos los beneficios de la integración continua, testing automático, etc, etc.

Alguna vez he oído decir que tocar el código en producción es como dejarse seducir por el lado oscuro de la fuerza. Tentador…pero no sólo es algo que esté mal…es algo cuyo precio vas a pagar tarde o temprano.

Habilidades vs títulos (episodio 2)

dilbert-certification

Si hace poco hablába de la titulitis en el artículo “Habilidades vs títulos” (que ahora deberé renombrar añadiéndole “episodio 1”), ahora va el jefe de Recursos Humanos de Google y suelta la frase: “el expediente académico no sirve para nada“.

Y es que nos pongamos a la defensiva o no, se está demostrando cada día más que la postura de “yo valgo porque mi título es tal o cual”, ha muerto, y debería considerarse una postura conformista y obsoleta.

Por desgracia, todo cambia, y debemos adaptarnos. Ya nunca más el tener un título va a suponer una ventaja absoluta, y debemos mirar con otros ojos (y con el debido respeto profesional), a los que han elegido otras vías de formación. Debemos valorar por capacidades, no por títulos.

Tal y como afirma el jefe de RRHH de Google, lo que se enseña en la universidad es muy distinto de lo que se necesita en el mundo laboral. La paradoja, tal y como desarrolla en el artículo, es que la universidad enseña…a superar la universidad. Del mismo modo que el hacer muchos Test Psicológicos entrena a superarlos (no necesariamente desarrolla el intelecto, aunque aparentemente los resultados de tus test sean exponencialmente mejores). De ahí se deduce que una persona que saca muy buena puntuación en un test…sólo significa eso y nada más. Para resolver problemas reales…hay que enfrentarse a problemas reales.

En el artículo, es curioso como una de las preguntas favoritas del jefe de RRHH de Google es “Dame un ejemplo de cómo resolviste un problema analítico difícil”. Aquí empieza a verse la luz valorando la experiencia, al mismo tiempo que una mente inteligente.