Traducción: El camino a la educación formal en administración de sistemas

Original de Tom Limoncelli
http://everythingsysadmin.com/2012/06/the-road-to-intentional-formal.html

Linkedin: http://www.linkedin.com/pub/tom-limoncelli/1/bb/333


La administración de sistemas está madurando y aún así, todavía no hay un curriculum estándar aceptado. Es irónico y algo que intimida un poco el que un campo de trabajo del cual la sociedad se vuelve cada vez más dependiente no tenga una educación formal y aceptada. Propongo una plataforma de enseñanza similar a lo que se encuentra en la industria de la electricidad/electrónica.


Para hacerse médico hay una educación generalmente aceptada. Pregraduadados "pre med" o de un programa de biología, luego escuela médica, internado y así sucesivamente. Me da una gran tranquilidad el que los médicos que consulto sigan un camino de educación formal. Los sysadmins por otro lado, a menudo "terminan" o "caen" en la profesión. Conozco muchos administradores de sistemas los cuales tienen una educación formal de físicos por ejemplo, porque les enseña los rigores de la matemática, medidas y a pensar en términos de sistemas. Conozco muchos administradores que comenzaron experimentando con computadoras como hobby, en su casa, posiblemente arreglando las computadoras de sus amigos y luego "terminaron" en administración de sistemas como trabajo y están disfrutando de una carrera altamente exitosa. Aún así, conozco exactamente cero doctores hayan conseguido arrancar haciendo experimentos médicos en su casa. La profesión médica fue desde "barberías" al estudio científico y la práctica de la medicina. La administración de sistemas debe hacer un recorrido similar.

La educación de administración de sistemas está evolucionando en una plataforma de 3 componentes, similar a la de la industria de la electricidad. Si vamos a imitar a esa industria es importante primero entender su plataforma.

La industria de la electricidad tiene tres bases: el técnico, el ingeniero y el investigador.

El técnico es alguien que podrías contratar para instalar un nuevo enchufe en tu casa, o para que instale infrastructura eléctrica en una construcción. Las personas en este rol siguen las prácticas aceptadas de la industria, llamadas "códigos de construcción". Un técnico literalmente podría no conocer la Ley de Ohm. Pero sí saber, que el código de construcción dice que cada tantos pies de esto tiene que ser uno de esto otro. Que cada circuito de 15 Amp puede tener un cierto número de enchufes. Podrían no saber o no importarles, el por qué existen estas reglas, pero son reglas para ser seguidas. Saben que si una de esas reglas se viola, el trabajo no pasará la inspección cuando el edificio sea revisado por su trabajo. Los trabajos técnicos generalmente no requieren una educación universitaria.

El ingeniero generalmente tiene educación formal. Tienen un profundo conocimiento que les permite diseñar los sistemas que los técnicos instalan. Ellos entienden no solo los códigos de construcción, sino también entienden la ciencia detrás de ellos. Son responsables no solo por diseños chicos como cableado para una casa nueva, sino también de diseños grandes como el abastecimiento de energía para la red de iluminación de un estadio. Los ingenieros con más experiencia escriben nuevos códigos de construcción. Algunos ingenieros hacen práctica general mientras otros se especializan. Algunos se involucran en proyectos relativamente mundanos, mientras otros trabajan con lo último en su campo.

El investigador investiga. Mientras que los ingenieros diseñan algo que nunca ha sido diseñado antes, los investigadores crean categorías nuevas completas. Pueden tener un acercamiento al diseño e inventar nuevos componentes o pueden enfocarse en la física e inventar paradigmas completamente nuevos.

El campo de administración de sistemas se beneficiaría de un enfoque similar al anterior.

El técnico administrador de sistemas instala y mantiene los sistemas diseñados por otros. Pueden no conocer todos los detalles de por qué un estándar existe pero conocen como mantenerse dentro de ese estándar. Esta idea ya existe en términos de "certificaciones" (que las entregan los fabricantes de hardware y software en el mercado). Un técnico aprendiendo una certificación Red Hat, Cisco o Microsoft es equivalente a un electricista aprendiendo un nuevo código de construcción. En vez de ser un gobierno o entidad reguladora el que provea la certificación, la presión de seguir los estándares está dada desde los fabricantes de hardware y software, quienes no proveen soporte para diseños que no siguen ciertas buenas prácticas. Cuando se diseña un ambiente MS Exchange uno podría elegir no usar Active Directory pero eso sería ir contra la recomendación del fabricante y no sería una configuración soportada. He escuchado de ingenieros de redes que elegían una idea de diseño sobre otra porque Cisco no certificaría el primer diseño. Los fabricantes usan la "zanahoria" de la promesa de soporte, que es tan poderosa como el "palo" de un inspector municipal de construcciones.

El ingeniero de administración de sistemas está un poco menos definido. Hay una gran necesidad de una carrera universitaria que llene este vacío. Debería haber desde niveles de bachillerato (BA / BS en US), hasta maestrías (Master en US).

La investigador de administración de sistemas está en el grado de doctorados. No hace falta mucha explicación. Igualmente, debería notarse que uno no necesita un doctorado para inventar en el mundo de la administración de sistemas. La industria se mueve muy rápido para aislar la creación de nuevos paradigmas en una torre de marfil. El paradigma "devops" es un "patrón encontrado", es decir evolución orgánicamente y se le dió un nombre una vez muchos llegaron a la misma conclusión.

¿Cuales deberían ser los próximos pasos?

Educar técnicos es algo de lo que los fabricantes se están encargando. Eso está bien y es apropiado.

El nivel de doctorados es algo que va a llegar con el tiempo.

La brecha se da a nivel universitario. Ese debería el foco de atención. Para ser más específicos, el objetivo principal debería ser definir una carrera de 4 años en sistemas. A ese efecto, deberíamos empezar a encontrar a quienes están enseñando actualmente "administración de sistemas" a nivel universitario, catalogar lo que están haciendo y juntarlos para idear estándares para un currículum.

Yo estaría interesado en conversar con instructores de nivel universitario a los que les gustaría unir fuerzas en un proyecto como ese.

Tom Limoncelli

2012-06-04

Cómo es la arquitectura de Instagram

Un ingeniero de Instagram, la empresa recientemente comprada por Facebook publicó en el blog -oficial- del team de ingeniería de Instagram los detalles de la arquitectura que sostiene Instagram.

Acá pueden leer el artículo completo
http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances-dozens-of

Me gusta leer estos textos para ir viendo qué se usa hoy en deployments grandes, cómo lo usan, qué cosas deberían funcionar y no lo hacen, qué otras cosas no están tan probadas pero funcionan muy bien, etc. Startups como Instagram hacen un uso extensivo de tecnología opensource - obviamente - para reducir costos al máximo, así que - en gral. - el profile de TCO de este tipo de arquitecturas suele ser muy bajo en consumo de recursos, lo más bajo posible sin afectar la escalabilidad y la calidad de los servicios (más o menos el requerimiento base presente en toda arquitectura de sistemas).


Traduzco/colaboro el artículo original:

La arquitectura evolucionó durante un año, provee servicios para 14+ millones de usuarios. La infra la manejan 3 ingenieros. Tres principios de la arquitectura:

- Mantener las cosas bien simples.
- No reinventar la rueda.
- Aplicar, cuando se pueda, tecnologías sólidas y probadas.

La arquitectura, de arriba hacia abajo

1) OS / Hosting
Ubuntu 11.04 (Natty), corriendo sobre Amazon EC2.
Los Ubuntus anteriores les dieron problemas en EC2 con alto tráfico, pero Natty funcionó bien. Por ahora están con Amazon, ya que con 3 ingenieros es poco viable el hosting propio.

2) Balanceo de Carga
Todo request a los servers de Instagram pasa por balanceadores. Solían correr 2 Nginx y balancearlos con DNS Round-Robin. El problema con eso es el tiempo que tarda DNS en actualizarse, para el caso en que hubiera que decomisionar alguno de los servers. Ahora están usando Amazon Elastic Load Balancer, con 3 instancias Nginx detrás y las pueden sacar y poner sin problemas (son sacadas de la rotación automáticamente si alguna falla en un health-check). También terminan su SSL a nivel ELB, lo que libera carga de CPU en los Nginx. Usan amazon Route53 para DNS.

3) Servers de aplicación
Corren Django sobre 25 máquinas Amazon High-CPU Extra-Large. La carga de trabajo está muy ligada a las CPU más que a la memoria. así que las máquinas mencionadas le ofrecen un buen balance de memoria y cpu.

Usan gunicorn como server WSGI, antes usaban mod_wsgi de Apache, pero Gunicorn les resultó más fácil de configurar y con menos consumo de CPU. Para correr comandos en varias instancias a la vez, usan Fabric, que hace poco tiene un modo paralelo que les permite deployar código en muy poco tiempo.


4) Data Storage
La mayoría de los datos (usuarios, metadatos de fotos, tags, etc.), están guardados en Postgresql, en este link explican como "shardean" a través de varias diferente instancias de Postgresql.
http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram

¿Qué es "shardear" en bases de datos?
http://en.wikipedia.org/wiki/Shard_(database_architecture)

El cluster shard principal tiene 12 instancias de memoria Quadruple Extra-Large (y 12 réplicas en una zona diferente).

Los ingenieros se dieron cuenta que el network filesystem de Amazon (EBS), no soportaba suficientes búsquedas de disco por segundo, así se dedicaron a mantener en memoria todo el set de trabajo. Para lograr buena performance de IO (entrada/salida), configuraron los discos EBS en RAIDS por software usando mdadm.

Un tip que dan: se dieron cuenta que vmtouch ( http://hoytech.com/vmtouch/vmtouch.c ) es una muy buena herramienta para ver qué datos están en memoria, especialmente al hacer failover de una máquina a la otra donde no hay un perfil de memoria activo todavía. Hay un script ( https://gist.github.com/1424540 ) que usan para parsear el output de vmtouch y mostrar el comando vmtouch correspondiente a correr en otro sistema para hacerlo coincidir con el estado de la memoria de la anterior.

Todas las instancias Postgresql corren en un esquema master-replica usando Streaming Replication. Usan snapshots EBS, para hacer snapshots frecuentes de los sistema para backup. Usan XFS como filesystem del OS, lo cual les permite congelar/descongelar los arreglos RAID cuando están haciendo el snapshot, garantizando así la consistencia del - filesystem dentro del - snapshot. Se inspiraron en ec2-consistent-snapshot ( http://alestic.com/2009/09/ec2-consistent-snapshot ). Para arrancar la replicación, la herramienta que usan es repmgr. de 2ndQuadrant ( https://github.com/greg2ndQuadrant/repmgr ).

Para conectar las bases de datos con los servers de aplicación, se dieron cuenta pronto que ello tenía un fuerte impacto en la performance, así que usan Pgbouncer para poolear conecciones a Postgresql. El blog de Christopher Pettus es una gran fuente de datos respecto de Django, Postgresql y Pgbouncer.

http://pgfoundry.org/projects/pgbouncer/
http://thebuild.com/blog/

Las fotos en sí las guardan en Amazon S3, la cual guarda ahora varios terabytes de datos de fotos para Instagram. Usan Amazon CloudFront como CDN, lo que ayuda a los tiempos de carga de imágenes de usuarios alrededor del mundo.

También usan Redis extensivamente. que abastece el feed principal, el de actividades y el del sistema de sesiones (este es el backend de session de Django > https://gist.github.com/910392), y el de otros sistemas relacionados ( http://instagram-engineering.tumblr.com/post/12202313862/storing-hundreds-of-millions-of-simple-key-value-pairs ). Todos los datos de Redis necesitan estar en memoria, así que terminaron corriendo varias instancias de memoria Quadruple Extra-Large para Redis, ocasionalemente shardean en varias instancias de Redis para algun subsistema. Corren Redis en un esquema master-replica, y las réplicas constantemente guardan la DB a disco; para terminar usan snapshots EBS para backupear esos dumps DB (lo hacen en la réplica porque se dieron cuenta que dumpear la DB en el master era muy "costoso" en recursos). Ya que Redis permite escribir a las réplicas, se hace para para lograr un fácil failover a nuevas máquinas Redis, sin que sea necesario un downtime (bajar el servicio).

Para la API de geo-búsqueda usaron Postgresql por varios meses, pero cuando shardearon sus entradas Media, se mudaron a Apache Solr, que tiene una interfaz JSON simple, así que por lo que concierne a su aplicación, es solo otra API a consumir.

Finalmente, como todo servicio web moderno, usan Memcached para cacheo y tienen 6 instancias Memcached, a las que se conectan usando pylibmc y libmemcached, cuentan que Amazon tiene el servicio Elastic Cache, pero no es más barato ($$$), que correr las instancias Memcached, así que todavía no lo están usando.


5) Cola de tareas y envío de notificaciones
Cuando un usuario quiere compartir una foto Instagram en Twitter o Facebook, o cuando necesitan notificar a los suscriptores "Real-Time" ( http://instagram.com/developer/realtime/ ), de que una nueva foto fue posteada, manejan esa tarea con Gearman ( http://gearman.org/ ), un sistema de manejo de colas escrito en Danga. Proceder asincrónicamente en la cola implica que los uploads de medios terminan rápidamente, mientras que los más pesados pueden correr en background. Tienen unos 200 workers (todos escritos en Python), consumiendo de la cola de tareas en cualquier momento, divididos entre los servicios que comparten. También manejan el feed de fan-out en Gearman, así que postear es tan responsivo para un nuevo usuario como lo es para un usuario con muchos followers.

Para enviar notificaciones la solución de mejor costo-beneficio que encontraron fue https://github.com/samuraisam/pyapns , un servicio opensource de Twisted que llegó a manejar más de un billón de envíos de notificaciones y funcionó bien.


6) Monitoreo
Con más de 100 instancias, es importante saber qué está pasando. Usan Munin ( http://munin-monitoring.org/  ) para graficar métricas de todos los sistemas, y también los alerta si algo está fuera de rangos normales. Escriben muchos plugins customizados para Munin, sobre Python-Munin (http://samuelks.com/python-munin/ ), para graficar métricas que no son del sistema (por ejemplo, suscripciones por minuto, fotos posteadas por segundo, etc.), Usan Pingdom ( http://pingdom.com/ ) para monitoreo externo del servicio y PagerDuty ( http://pagerduty.com/ )para manejar notificaciones e incidentes.

Para reporte de errores de Python usan Sentry ( http://pypi.python.org/pypi/django-sentry) una muy buen app Django escrita por la gente de Disqus. En cualquier momento dado, se loguean y pueden ver qué errores están ocurriendo en el sistema, en tiempo real.

Traducción: Las 8 creencias principales de los jefes extraordinarios

Me interesó este artículo:
http://www.inc.com/geoffrey-james/8-core-beliefs-of-extraordinary-bosses.html

Por supuesto, es inevitable que hasta que conozcas a uno de estos tipos extraordinarios y los tengas como jefe, todo lo de la traducción de abajo te va a parecer un montón de pavadas.

La traducción (libre):

Los mejores jefes tienen un entendimiento fundamentalmente diferente acerca del lugar de trabajo, la empresa y las dinámicas de equipo.

Unos años atrás entrevisté a alguno de los más exitosos CEOs del mundo para descubrir sus secretos de management. Aprendí que lo mejor de lo mejor tiende a compartir los siguientes puntos de vista:


1) Los negocios son un ecosistema, no un campo de batalla
Los jefes "promedio" ven los negocios como un conflicto entre empresas, tienen "tropas", y demonizan a sus competidores como "enemigos, sus clientes son "territorio" a ser conquistado.

Los jefes extraordinarios ven los negocios como un ecosistema, donde el mejor adaptado tiene chances de sobrevivir. Naturalmente crean equipos que se adaptan fácilmente a nuevos mercados; forman rápidamente alianzas con otras empresas, clientes e incluso competidores.



2) La empresa es una comunidad, no una máquina
Los jefes "promedio" consideran a su empresa una máquina, y a sus empleados, como partes de ella. Crean rígidas estructuras y tratan de mantener el control "bajando palancas" y "gobernando el barco".

Los jefes extraordinarios ven sus empresas como un conjunto de esperanzas y sueños de individuos, todos conectados por un propósito mayor. Inspiran a sus empleados a dedicarse ellos mismos al éxito de sus compañeros de trabajo y por ende, al de la comunidad, y al final, al de la empresa en sí.



3) El management es servicio, no control
Los jefes promedio quieren empleados que hagan exactamente lo que se les dice. Están extremadamente alertas a todo lo que pueda fomentar insubordinación y crean un ambiente de trabajo donde la iniciativa de un individuo es enmudecida mediante la filosofía "esperá y veamos qué dice el jefe".

Los jefes extraordinarios fijan una dirección general y se comprometen ellos mismos a obtener los recursos que sus empleados necesiten para poder hacer el trabajo. Delegan decisiones, permitiendo que los equipos formen sus propias reglas e interviniendo solo en emergencias.



4) Mis empleados son mis pares, no mis hijos
Los jefes promedio ven a sus empleados como inferiores, inmaduros, en los que simplemente no se puede confiar sin un control patriarcal. Los empleados se dan cuenta de esa actitud, y gastan energía en parecer ocupados y cubrirse la espalda.

Los jefes extraordinarios tratan a cada empleado como si él o ella fueran la persona más importante en la empresa. La excelencia se espera en donde sea dentro de la empresa, desde la bahía de carga hasta las salas de reuniones. Como resultado, los empleados en todos los niveles se hacen cargo de sus propios destinos.


5) La motivación viene de una visión, no del miedo
Los jefes promedio ven el miedo a ser despedidos, ridiculizados y a perder beneficios/privilegios como un modo crucial de motivar a la gente. Como resultado, los empleados se paralizan y no son capaces de tomar decisiones que impliquen el riesgo de fallar.

Los jefes extraordinarios inspiran a la gente para que vean un futuro mejor y cómo ellos serán parte de eso. Como resultado, los empleados trabajan más duro porque creen en los objetivos de la organización, y verdaderamente disfrutan lo que están haciendo y - por supuesto - saben que ellos compartirán la recompensa al final.


6) El cambio es crecimiento, no dolor
Los jefes promedio ven el cambio como complicado y amenazante, algo a afrontar solo si la empresa está en una situación desesperante. Subconscientemente "torpedean" los cambios, hasta que es demasiado tarde.

Los jefes extraordinarios ven el cambio como una parte inevitable de la vida. Aunque no lo valoran al cambio por sí mismo, saben que el éxito solo es posible si empleados y organización abrazan nuevas ideas y nuevas maneras de hacer negocios.


7) La tecnología ofrece fortalecimiento, no automatización
El jefe promedio adhiere a la vieja visión IT de que la tecnología es principalmente una manera de fortalecer el control gerencial y aumentar la predictibilidad. Instalan sistemas centralizados que deshumanizan y antagonizan empleados.

Los jefes extraordinarios ven la tecnología como modo de liberar a los seres humanos para ser creativos y construir mejores relaciones. Adaptan los sistemas de oficina a las herramientas como smartphones y tabletas, lo que la gente usa en realidad.


8) El trabajo debería ser divertido, no un mero esfuerzo
Los jefes promedio están metidos en la noción de que el trabajo es a lo sumo, un mal necesario. Esperan que los empleados no estén contentos al trabajar, por lo tanto tienden subconscientemente a definirse a sí mismos como "opresores" y a sus empleados como "víctimas", luego cada quien se comporta de acuerdo a ese paradigma.

Los jefes extraordinarios ven al trabajo como algo que debería ser inheremente disfrutable y creen en consecuencia que la parte más importante del trabajo del jefe, es tanto como sea posible, poner a la gente a trabajar en puestos en que puedan ser verdaderamente felices.

Cómo se trabaja en GitHub: Las horas son basura

Traducción libre del original:

How GitHub Works: Hours are Bullshit
http://zachholman.com/posts/how-github-works-hours/

de Zach Holman

------------------------
Frederick Winslow Taylor escribió el gran análisis de management y eficiencia en 1911 con "Los Principios Científicos de la Administración". El tuvo el primer punto de vista científico en cuanto a maximizar la eficiencia en trabajos de manufactura. Tiempo es dinero. Rápido es mejor. Más horas son mejor trabajo.


Las horas son basura
Las horas son un gran modo de determinar la productividad en muchas industrias, pero no en la nuestra. Trabajar en una startup es una muy diferente experiencia respecto de trabajar en una fábrica. No puedes dedicarle más tiempo a un problema y esperar llegar a resolverlo. El código es un esfuerzo creativo. Tienes que estar del humor apropiado para crear código de alta calidad.

Recuerdas la última vez que estuviste depresivo o enojado. Qué tan productivo fuiste? Ahora piensa en la última vez que fuiste realmente productivo. El código volando desde la punta de tus dedos. No solo la pura cantidad, sino la pura calidad de ese código. Cuando estás en el estado de ánimo correcto, tu mejor día de programar puede ganarle a semanas de frustrante tipeo de teclado.

Queremos que los empleados estén en la zona tan a menudo como sea posible. Disponer de horarios específicos para que estén en la oficina hace daño a esa cuestión. Forzarme a estar en la oficina a las 9AM no me va a llevar a la zona nunca, pero la mitad de GitHub podría muy bien trabajar mejor durante la mañana.

Al permitir un horario de trabajo más flexible, creas una atmósfera donde los empleados pueden estar contentos acerca de su trabajo. Al final ello llevará a más horas de trabajo, y que esas horas sean incluso más productivas. Trabajar semanas se vuelve trabajar noches y ello se vuelve trabajar fines de semana, ya que ninguno se siente como si fuera "trabajo".


Un Día
Cada día en GitHub es diferente. Realmente no tengo un día "promedio", pero esto es una buena aproximación:

- Despertar alrededor de las 10am, revisar los logs de Campfire (N.deT. Es un chatroom masivo para los empleados de GitHub), limpiar los tickets de soporte de la noche.
- Tomar el colectivo al trabajo y desayunar cerca del mediodía o las una.
- Trabajar desde las 1pm hasta algo así como las 6-9pm en la oficina
- Ir a casa y trabajar/relajarme en mi sofá hasta las 2am, o
- Salir y tomar algo con mis compañeros de trabajo (más sobre esto luego)

Tenemos un grupo de gente (loca) que viene a trabajar alrededor de las 7am, tenemos algunos que vienen a las 3pm. Tenemos otros que son más productivos trabajando desde su casa. No hace falta que vengas a la oficina todos los días, si no tenés ganas (aunque la mayoría del tiempo todos vienen).

Por qué nuestro día es tan "libre"? Porque
1) Trabajar en chatrooms nos permite trabajar cuando y donde querramos y
2) queremos crear un ambiente donde la gente sea más productiva. No hay un solo "día de trabajo" que se acomode a las horas productivas de todos, así que no forzamos uno.


Forzandolo
Tenemos actualmente 35 empleados y creciendo, y este punto de vista funciona muy bien, pero los managers aman asignar horas de trabajo por una razón: les da la ilusión de que las horas pueden medir el rendimiento.

Si no le prestás mucha atención a las horas, te hace falta mirar métricas diferentes: Qué tan bueno es su código? Están arreglando bugs? Están metidos en el trabajo o la mayor flexibilidad no está motivandolos?

Es difícil hacer esos juicios cualitativos, pero aún así son más valiosos que "este tipo hoy trabajó 10 horas". Porque tan pronto como tú lo vuelves una cuestión de "horas", su trabajo se vuelve menos acerca de código y más acerca de "horas".

Como descubrir un mal jefe antes que sea demasiado tarde

Traducción libre de
how-to-spot-a-bad-boss-before-its-too-late/



Vas a una entrevista de trabajo, respondes todas las preguntas y luego está el inevitable momento: tenés alguna pregunta para nosotros? Este es tu momento de enterarte si querés el trabajo y en particular, que clase de persona podría ser tu potencial jefe. Así que ¿cuales son las preguntas que van a mostrar las cosas como son?

1. De toda la gente con que trabajaron, de quienes están más orgullosos y por qué?

Querés trabajar con quien te ayude a crecer, desarrollarte y avanzar. Si este jefe no ha ayudado a la gente a progresar, esto podría indicar que tiene miedo de rivales, en cuyo caso, vos vas a ser frenado. También podría sugerir que no vas a recibir ningun mentoring ni coaching significativo, en cuyo caso, qué cosa, aparte del sueldo, ganarás en ese trabajo? Por otra parte, si el jefe puede mencionar personas que han obtenido amplias oportunidades, podrías estar en presencia de un ganador.

2. Podrías describir algun desacuerdo que hubiera habido dentro de un proyecto, trabajo o departamento y cómo fue resuelto?

Todos los departamentos saludables discuten: es así como la organización "piensa". Si no hay debate, nadie está pensando.  Lo que querés discernir de la respuesta es si hay niveles de confianza profesional alrededor de desacuerdos saludables. Si no hay esos niveles de confianza, tus puntos de vista no serán bienvenidos, y es un signo seguro de que las políticas triunfan sobre la inteligencia. Evíta estos trabajos.

3. Hay alguna oportunidad formal para ser mentor o coach de empleados con talento dentro de la empresa?

Si no podés ser vos mismo un mentor, es altamente probable que no vayas a recibir mentoring alguno tampoco. Muchos candidatos dudan en preguntar si van a recibir mentoring o coaching (porque creen que los hace ver como candidatos débiles), así que este podría ser un buen modo de ver al respecto sin que se note lo que están preguntando en realidad.

4. Qué le pasó a la persona que estuvo antes en el puesto de trabajo que ofrecen y cómo era como empleado?

La información de fondo de una posición vacante siempre es interesante. Si la persona anterior se fue en malas circunstancias, algo de ese oprobio va a venir con el trabajo , en cuyo caso, ya están advertidos.  Si avanzaron dentro de la empresa, implica que vos también podrías avanzar. Si nadie sabe que pasó con el empleado anterior, están mientiendo y vos deberías pensar dos veces respecto a esta oferta de trabajo. Es de mucha ayuda saber cómo era el trabajo que antes se hacía, aunque solo sea porque es más fácil imitar a alguien que es diferente; en cambio si los anteriores empleados en el puesto trabajaban de modo muy similar, puede que te sea difícil destacatar tu propio trabajo.

5. Qué tanto cambiaron las expectativas y requerimientos del puesto de trabajo desde que fue creado por primera vez?

Si no cambió para nada, es muy probable que sea una organización bastante estable, pero posiblemente rígida. Si eso es o no de tu gusto, es decisión tuya. Pero vos deberías saber antes de tomar el empleo si estás entrando en un puesto muy variable, "caliente" o en un puesto tipo estanque de aguas calmas.

Ninguna de estas preguntas te va a meter en problemas, pueden evitar que te metás en un lugar donde no querés estar.