#11 Los de recursos humanos, que normalmente son los que hacen las entrevistas, no suelen conocer los lenguajes de programación que piden en las ofertas. Normalmente, el arquitecto o el líder del proyecto les dicen "necesito un tío que sepa tal lenguaje y si sabe también este otro mejor". Por eso, cuando meten la pata en algo técnico, creo que no hay que ser tan estrictos con ellos ni levantarse de una entrevista. Otra cosa es que encima vayan de gurús, pero lo importante es llegar hasta la pregunta del sueldo y ahí es cuando decides si te merece la pena o no. De todas las entrevistas se puede sacar algo que te sirva para la siguiente.
Por cierto, creo que aquí nadie vota para ser cool como tú dices, si no porque nos sentimos identificados con el texto del artículo y nos ha gustado. Si quieres entender otra cosa es tu problema.
#14 La entrevista la tiene que hacer alguien que sepa evaluar lo que sabes y el técnico de selección de RRHH/Gerente de Consultora no es la persona adecuada para evaluar los conocimientos técnicos de un candidato, podrá hacer la entrevista no técnica pero la entrevista técnica la tiene que hacer un técnico., qué es exactactamente como lo hacen Google o similares.
Si la persona que tiene que va a evaluar mis conocimientos técnicos no tiene ni idea esa no es la empresa para la que quiero trabajar porque significa que va a ser un desastre de empresa.
#84 Estoy de acuerdo contigo. Por suerte no en todos los sitios es así, porque en otra entrevista primero hablé con el de RRHH, en la que la conversación básicamente se centró en apuntar mis estudios, experiencia laboral, conocimientos en lenguajes de programación y el sueldo. Después con el jefe de proyecto, en la que me estuvo preguntando acerca de mis tareas en la empresa en la que estaba, que herramientas y lenguajes conocía y había usado, que procedimiento seguiría para resolver tal incidencia... también me explicó el estado actual del proyecto, lo que necesitaban de mi y las funciones que iba a realizar, además de aclararme cosas que no me dijo el de RRHH, cómo que tendría que estar viajando constantemente para instalarle la aplicación al cliente. El primer comentario que puse sólo fue una anécdota, pero por suerte o por desgracia hay todo tipo de entrevistas, incluso con psicotécnicos...
#47 Supongo que los de RRHH están para filtrar. Si el que pide un programador es el jefe de proyecto y tiene que estar pendiente de publicar la oferta, mirar uno por uno los candidatos, llamarlos para realizar la entrevista y entrevistarse con ellos... al final no tendría tiempo para hacer su trabajo. Ahora, que el de RRHH filtre bien o mal, ya es otra cosa de ahí la gracia del articulo, que al final prefiere escoger un vendedor de coches marrones antes que al carpintero.
#80 Buena explicación. Al final, usar SQL en una base de datos NoSQL es como ir a un bar y pedir un campero de pollo pero sin pollo.
A mi en una ocasión, el entrevistador al ver que tenía mucha experiencía en SQL me dijo que eso estaba muy bien, pero que en un año SQL dejaría de existir y todas las empresas ya no usarían esa tecnología. Yo me quedé a cuadros y le pregunté que por qué pensaba eso y me contestó que SQL era un lenguaje que se había quedado anticuado y que había un nuevo lenguaje mucho más rápido y mejor para las bases de datos. Por supuesto no me dijo el nombre, ya que "lo había escuchado por ahí", pero el lo afirmaba totalmente convencido. Me ha hecho gracía el artículo porque me ha recordado aquella entrevista que hice en el 2006 y ahora pienso que lo que me dijo aquel gurú es como si a un carpintero le dijese "oye, ¿sabes que el martillo esta anticuado y ahora se va a empezar a usar una nueva herramienta?".
#7 Bueno, yo pienso que ya que se pierde el tiempo en ir a una entrevista, es mejor quedarse a ver si se saca algo provechoso de ello.
#11 Los de recursos humanos, que normalmente son los que hacen las entrevistas, no suelen conocer los lenguajes de programación que piden en las ofertas. Normalmente, el arquitecto o el líder del proyecto les dicen "necesito un tío que sepa tal lenguaje y si sabe también este otro mejor". Por eso, cuando meten la pata en algo técnico, creo que no hay que ser tan estrictos con ellos ni levantarse de una entrevista. Otra cosa es que encima vayan de gurús, pero lo importante es llegar hasta la pregunta del sueldo y ahí es cuando decides si te merece la pena o no. De todas las entrevistas se puede sacar algo que te sirva para la siguiente.
Por cierto, creo que aquí nadie vota para ser cool como tú dices, si no porque nos sentimos identificados con el texto del artículo y nos ha gustado. Si quieres entender otra cosa es tu problema.
#14 La entrevista la tiene que hacer alguien que sepa evaluar lo que sabes y el técnico de selección de RRHH/Gerente de Consultora no es la persona adecuada para evaluar los conocimientos técnicos de un candidato, podrá hacer la entrevista no técnica pero la entrevista técnica la tiene que hacer un técnico., qué es exactactamente como lo hacen Google o similares.
Si la persona que tiene que va a evaluar mis conocimientos técnicos no tiene ni idea esa no es la empresa para la que quiero trabajar porque significa que va a ser un desastre de empresa.
#7 ¿Tunning? ¿En puto serio?
Dunning-Kruger de libro.
#26 Duning, se dice Duning...
#5 "Y Ensamblador y C valen para algo? Lo que vale es php"
#5 Supongo que se referiría a NoSQL http://es.wikipedia.org/wiki/NoSQL
Lo usan gente como Twitter, Google, Facebook y demás. Para sistemas que tengan que manejar cantidades extremadamente grandes de datos va mejor que SQL. Para bases de datos normales, pues como que no.
Pero hay gente que escucha "Google usa X" y ya van por ahí dándoselas de gurú diciendo "X es el futuro y todo lo demás está obsoleto" sin pararse a leer las razones por las que Google usa X y el entorno y condiciones en los que lo está usando.
#36 Gracias por el apunte. La verdad es que no recuerdo el nombre del lenguaje que me dijo. Se que hay varias tecnologías de base de datos que son mejores para manejar un gran volumen de información, a mi en ese momento me vino a la cabeza Teradata http://es.wikipedia.org/wiki/Teradata pero dudo mucho que una pequeña empresa migre su base de datos a esa...
Cómo tu dices, hay que tener en cuenta las condiciones y el entorno, porque si no lo necesitas es innecesario, no solo por el esfuerzo de aprender el lenguaje que utilizan, si no por los costes que pueden suponer los servidores que se necesiten para trabajar con esas bases de datos.
#36 Lo del NoSQL es más un mito que otra cosa. Claro, las implementaciones se venden como más escalables, más rápidas, con soporte para índices menos estrictos y mejor preparadas para HA, pero todo viene a costa de recortar funcionalidad.
Y utilizando MySQL con memcached y restringiendo el uso casi a un conjunto de relaciones clave-valor, Facebook hace lo mismo.
#51 si vas a restringir MySQL a un almacén de hashes clave-valor, tienes herramientas más adecuadas como mongodb. Has leído el texto con la roca y los martillos? pues eso
#75 Facebook y por ejemplo algo más cercano Tuenti, que manejan cantidades de datos brutales lo hacen con mysql mucho cacheo y con muchas restricciones como por ejemplo no ejecutar joins para poder hacer sharding. No es que mysql este pensada para darle este uso especificamente, pero un sistema con tal carga de datos y con los requisitos de disponibilidad que tienen no se pueden plantear una migración a noSQL tan tranquilamente, así que es normal que sigan manteniendo gran cantidad de sus datos en mysql con estas restricciones (que va como un tiro).
Estoy seguro que si empezarán ahora mismo el proyecto lo plantearían de inicio con un noSQL, por ejemplo facebook creo su propio noSql: cassandra.
Vamos que no todo es blanco o negro.
#5 De hecho no hace falta dejar de utilizar SQL para utilizar NoSQL como apunta #36
SQL es una definición de un lenguaje. Lo que pasa es que su uso está tan extendido en bases de datos relacionales que ya se da por sentado que Base de Datos Relacional SQL, pero no tiene porqué ser así.
NoSQL define una filosofía nueva, que es principalmente no hacer "joins" de tablas o vistas o historias raras. Las tablas son fijas y se utilizan índices únicos (además de otras limitaciones bastante diversas y serias) para que se comporte más como un Hash que como un árbol B+. Por eso se "dispara" la eficiencia. Ésta es la filosofía de Cassandra, que es la BDD que utiliza Facebook, por ejemplo. Pero es que esto se puede hacer en una tabla relacional de toda la vida, pero sin aprovechar sus capacidades relacionales, como bien ha apuntado #51. Más aún, una base de datos relacional con índices bien definidos no tendría que tener nada que envidiar a sistemas Hash. El problema es que por lo general no se respetan los índices y el rendimiento cae en picado con mucha facilidad.
Ahora bien, se podría perfectamente utilizar SQL para ejecutar consultar sobre estructuras NoSQL. Simplemente habría que desarrollar un intérprete.
Por supuesto, lo que acabo de decir roza lo absurdo por el choque de conceptos. Y a un listo de RRHH ya ni te digo como le suena.
#36 #51 #80 Yo hace poco hice la certificación de mongoDB (la da gratis la propia compañía https://education.10gen.com/), y sinceramente no me pareció tan óptimo como algunos creen.
Para aplicaciones como Twitter puede ser una buena idea, pero hay muchas aplicaciones que necesitan unos modelos de datos más complejos, y al final lo que vi es que los JOINS se sustituyen por mayor uso de la CPU en la parte de la lógica de negocio. Sinceramente, creo que en modelos de datos complejos, si estos están bien definidos y se usa una gestión correcta de las transacciones, es mejor utilizar SQL.
#80 Ya existe algo como lo que comentas, nuoDB, basicamente interpreta un SQL compatible con el de MySQL pero luego el almacenamiento es más cercano a como funciona un sistema noSQL. Tiene bastante buena pinta y tenemos pendiente probarla más en serio para ver que tal se comporta que sobre el papel todo suena muy bonito claro...
#81 No hace falta tener un titulo de psicología para ver la actitud de una persona no nos engañemos. Por supuesto la actitud es fundamental y ver si la persona encaja en el equipo más alla del plano tecnico. Pero precisamente alguien de RRHH no es muy apto para saber si una persona encajará en un grupo de desarrolladores de software más que nada por que en muchos casos no entiende mucho de la psicología del desarrollador, no entienden las cosas que nos gustan, no entienden las cosas que nos motivan, así es muy difícil que puedan acertar.
Sobre lo de trabajar dentro del equipo como entrevista, mira es fácil, si alguien no esta dispuesto o lo considera un abuso esta en su perfecto de derecho de no hacerlo, por supuesto eso lo descarta inmediatamente para el puesto. Esta claro que esto no lo va ha hacer everis (por poner un ejemplo), hay que tener cierto prestigio como empresa para que el candidato sepa que esto no es una estafa y que bien merece la pena el esfuerzo porque vas a trabajar en un lugar que de verdad lo merece. Tampoco sería la primera entrevista, antes de esto el candidato tendría que pasar más pruebas previas para asegurarnos que esos días no van a ser una perdida de tiempo ni para el ni para la empresa que contrata. Además las entrevistas son algo bidireccional, como candidato no estaría de más probar uno o dos días para ver si te gusta el trabajo y el ambiente que se respira, mejor eso que perder varios meses de tu vida trabajando en un lugar en el que no estas comodo.
Además estos días, aunque no seas contratado, son una oportunidad de aprendizaje, te sorprendería que hay gente que incluso dedica su tiempo de vacaciones para irse a compartir unos días con grupos de trabajo de otras empresas, en mi equipo hemos tenido gente haciendo desk-surffing (que es el nombre "cool" de esta movida), y hay más empresas, incluso en españa, que hacen estas moderneces: http://www.desk-surfing.org/ir-y-venir/
Nunca vas a trabajar en un sitio que merezca la pena si la entrevista la hace un RRHH, porque los únicos sitios que merecen la pena trabajar son aquellos que entienden que la contratación de nuevos colaboradores es, precisamente, su inversión más importante.
#87 Lo sospechaba!, jaja 
La verdad es que después de trastear con Cassandra hace unos años (o intentarlo), la necesidad de una interfaz amigable estaba clarísima.
Gracias por el dato
#87 "Sobre lo de trabajar dentro del equipo como entrevista, mira es fácil, si alguien no esta dispuesto o lo considera un abuso esta en su perfecto de derecho de no hacerlo, por supuesto eso lo descarta inmediatamente para el puesto".
Hombre, yo estoy en paro desde hace bastante pero me lo pensaría mucho. Eso de trabajar por la cara deja lugar a muchos abusos por parte del empleador como que todo el mundo trabaje gratis y nunca contrate a nadie o que pruebe a un montón de gente y al final contrate a su primo aunque no sepa hacer la o con un canuto. Yo sólo lo aceptaría si en el caso de que no me contraten la empresa no se pueda beneficiar de mi trabajo de ningún modo. Algo así como cuando una ETT o una cárnica presenta un candidato a otra empresa. Si lo contrata me llevo mi parte, si no lo hace he trabajado para nada pero la otra empresa no se beneficia de mi trabajo.
#84 Estoy de acuerdo contigo. Por suerte no en todos los sitios es así, porque en otra entrevista primero hablé con el de RRHH, en la que la conversación básicamente se centró en apuntar mis estudios, experiencia laboral, conocimientos en lenguajes de programación y el sueldo. Después con el jefe de proyecto, en la que me estuvo preguntando acerca de mis tareas en la empresa en la que estaba, que herramientas y lenguajes conocía y había usado, que procedimiento seguiría para resolver tal incidencia... también me explicó el estado actual del proyecto, lo que necesitaban de mi y las funciones que iba a realizar, además de aclararme cosas que no me dijo el de RRHH, cómo que tendría que estar viajando constantemente para instalarle la aplicación al cliente. El primer comentario que puse sólo fue una anécdota, pero por suerte o por desgracia hay todo tipo de entrevistas, incluso con psicotécnicos...
#47 Supongo que los de RRHH están para filtrar. Si el que pide un programador es el jefe de proyecto y tiene que estar pendiente de publicar la oferta, mirar uno por uno los candidatos, llamarlos para realizar la entrevista y entrevistarse con ellos... al final no tendría tiempo para hacer su trabajo. Ahora, que el de RRHH filtre bien o mal, ya es otra cosa de ahí la gracia del articulo, que al final prefiere escoger un vendedor de coches marrones antes que al carpintero.
#80 Buena explicación. Al final, usar SQL en una base de datos NoSQL es como ir a un bar y pedir un campero de pollo pero sin pollo.
#36 El que diga una sandez como que las BBDD relacionales (llámese SQL) van a desaparecer, no tiene ni pajolera idea...
Es más, le puedes contraatacar (que seguro será un RRHH) hablándole de modelos jerárquicos, reticulares, que son previos al relacional, a ver qué te dicen.
Es que si desnormalizo o no normalizo y meto mogollón de datos en la misma tabla, seguro que gano en tiempo de respuesta para determinadas consultas, pero el modelo de datos era una mir#da, con perdón.
#5 #36 Pues yo estoy metido en un proyecto para un centro excursionista (con lo que se entiende que no tendrá millones de registros) y he optado por usar mongoDB debido a su facilidad para añadir / eliminar "bloques" de información sin tener que andar pensando en montar más tablas relacionales, etc. La verdad es que estoy pensando en mandar a tomar por el culo las bases de datos relacionales de una vez por todas... ¡Salud!
#58 No has leído muy bien mi comentario, pero me preocupa más que vayas de enteradillo por la vida sin tener ni puta idea.
Infórmate un poquito anda: www.highscalability.com
#1 Una pelicula de Almodóvar con banda sonora compuesta por los Mojinos Escozios
#2 las historias que yo subo no son tan interesantes
"Son temas duros y pasarlos por alto no sería correcto... pero eso es lo que voy a hacer" Debio pensar Obama, porque ahí termina el video y no responde las preguntas de la señora.
A ver, no podemos sacar conclusiones precipitadas, ya que sólo tenemos una parte del video. Nos falta saber cómo llego a meterlo ahí y por qué motivo lo hizo. Además, teniendo en cuenta que al final del video le dice al coche: "muerete, io de putah" y que le da varias patadas, me lleva a pensar que este hombre, en realidad, esta peleando contra un Decepticons para detener su invasión extraterrestre.
#11 En realidad al final de la noche y con el trancazo pensó que le habían dado un bonus level del Street fighter
#7 Bueno, yo pienso que ya que se pierde el tiempo en ir a una entrevista, es mejor quedarse a ver si se saca algo provechoso de ello.