#28 Entrevistador: Así que eres carpintero, ¿no?
Carpintero: Cierto, es lo que hago.
E: ¿Durante cuánto tiempo?
C: 10 años
E: Genial, eso es bueno. Ahora tengo unas cuantas preguntas técnicas para usted para ver si se adecua a nuestro equipo, ¿de acuerdo?
C: Está bien, estoy de acuerdo.
E: Antes que nada, estamos trabajando en una subdivisión construyendo muchas casas marrones. ¿Ha construido alguna casa marrón con anterioridad?
C: Bueno, soy carpintero, por lo que construyo casas, y la gente la pinta del color que quiera.
E: Sí, lo entiendo, pero ¿puede indicarme cuanta experiencia tiene con el marrón? Aproximadamente.
C: Dios, no lo sé. Una vez que han sido construidas no me preocupo del color del que han sido pintadas. ¿Quizás seis meses?
E: ¿Seis meses? Bueno, estamos buscando a alguien con más experiencia en el marrón, pero déjeme hacerle unas cuantas preguntas más.
C: Bien, de acuerdo, pero la pintura es la pintura, ya sabe.
E: Sí, bien. ¿Qué tal con el nogal?
C: ¿Qué pasa…...
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?".
#6 Gracias a la educación que he tenido (gracias a mis padres por costearla en su momento) y a mi interés por los idiomas ya no me doy ni cuenta de cuándo estoy leyendo en inglés, ¿me tengo que autocastigar o algo?
#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.
Entrevistador: Así que eres carpintero, ¿no?
Carpintero: Cierto, es lo que hago.
E: ¿Durante cuánto tiempo?
C: 10 años
E: Genial, eso es bueno. Ahora tengo unas cuantas preguntas técnicas para usted para ver si se adecua a nuestro equipo, ¿de acuerdo?
C: Está bien, estoy de acuerdo.
E: Antes que nada, estamos trabajando en una subdivisión construyendo muchas casas marrones. ¿Ha construido alguna casa marrón con anterioridad?
C: Bueno, soy carpintero, por lo que construyo casas, y la gente la pinta del color que quiera.
E: Sí, lo entiendo, pero ¿puede indicarme cuanta experiencia tiene con el marrón? Aproximadamente.
C: Dios, no lo sé. Una vez que han sido construidas no me preocupo del color del que han sido pintadas. ¿Quizás seis meses?
E: ¿Seis meses? Bueno, estamos buscando a alguien con más experiencia en el marrón, pero déjeme hacerle unas cuantas preguntas más.
C: Bien, de acuerdo, pero la pintura es la pintura, ya sabe.
E: Sí, bien. ¿Qué tal con el nogal?
C: ¿Qué pasa con eso?
E: ¿Ha trabajado mucho con el nogal?
C: Claro, nogal, pino, roble, caoba - lo que sea.
E: ¿Pero cuantos años de nogal tienes?
C: Dios, realmente no lo sé - ¿se supone que debería estar contando el nogal?
E: Bien, aproximadamente..
C: Vale, digamos que tengo un año y medio de nogal.
I: ¿Diría que tiene un nivel básico de nogal o eres un gurú del nogal?
C: ¿Un gurú del nogal? ¿Qué es un gurú del nogal? Claro, he usado nogal.
E: ¿Pero no eres un gurú del nogal?
C: Bueno, soy carpintero, por lo que he trabajado con todo tipo de maderas, ya sabes, hay algunas diferencias, pero creo que si eres un buen carpintero...
E: Sí, si, estamos usando nogal, ¿le parece bien?
C: ¡El nogal está bien! Lo que quieras. Soy carpintero.
E: ¿Qué tal el nogal negro?
C: ¿Qué pasa con él?
E: Bueno, tenemos algunos carpinteros de nogal con nosotros, pero ninguno era un carpintero de nogal negro. ¿Tiene alguna experiencia con el nogal negro?
C: Claro, un poco. Sería bueno tener un poco más por mi currículum, supongo.
E: Vale. Espera, déjeme comprobar la caja...
Ca: Adelante.
E: Vale, una cosa más por hoy. Estamos usando Roca 5.1 para golpearl os clavos. ¿Has usado Roca 5.1?
C: [Poniéndose pálido...] Bueno, sé que muchos carpinteros están empezando a usar rocas para golpear los clavos desde que Artesanos compró una cantera, pero sabes, para ser sincero he tenido más suerte con una pistola de clavos. O un martillo, para el caso. Resulta que me golpeo demasiado los dedos con la… » ver todo el comentario
En la realidad hubieran modificado el CV del vendedor de coches afirmando que lleva 10 años de experiencia en la carpintería de nogal con incrustaciones de grafeno.
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.
#25 Estoy de acuerdo contigo. No es lo mismo utilizar un lenguaje de programación u otro que pintar una casa ya terminada con un color u otro, o utilizar un tipo de madera u otro. No me gusta la analogía. De hecho nunca me ha gustado la analogía de programador = albañil que pone ladrillos.
#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 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.
He hecho cientos de entrevistas, y con diferencia los candidatos que más me gustan son los que cuando les pregunto si saben tal o cual cosa me dicen que no debe ser complicado, que se busca en internet o que eso no pero han hecho tal cosa que es parecida, los que no me gustan nada son los que cuando les digo que usamos Spring 3 me dicen que sólo han usado el 2 y ponen cara de acojonados.
No sé de qué país será ese post pero me sorprende porque las entrevistas técnicas en Europa no tienen nada que ver con las de España, en España si tienes carisma y sabes venderte bien puedes superar cualquier entrevista, a menos que te hagan una prueba escrita u oral, pero en Irlanda/Gran Bretaña/Bruselas etc no es así, allí realmente te ponen a prueba y te frien a preguntas que pocos sabrían responder, no porque no tengamos esos conocimientos, sino porque no estamos acostumbrados a ese tipo de entrevistas
En Europa las personas de selección saben perfectamente lo que te están preguntando, no se dejan llevar por tu amplia experiencia aunque hayas trabajado exactamente con lo que piden, creo que en España se trabaja más por experiencia que por memorización de términos, mientras que en el resto de Europa es al revés
En serio, no te pases, por muy bien que entiendas el inglés es evidente que está en inglés y te das cuenta. Me doy cuenta yo con mis dos lenguas maternas ¿y no te das tú con el inglés?
#43 ¿Tienes experiencia con el microsoft office? ¿Si es así, cuántos años? Si me preguntaran eso a mí no tendría ni idea. He usado un montón de programas ofimáticos diferentes (wordperfect, MS office, libreoffice, openoffice, los que hay online, algun que otro probrando...) Me manejo bien en ellos y podría adaptarme a uno nuevo en poco tiempo, quizás semanas como mucho. Y ni siquiera soy informático. Imagínate alguien que ha dedicado toda su vida a los ordenadores.
Para él tiene tan poco sentido como para un carpintero pensar en el color con que pintan de la madera luego de trabajarla, o cuántos años ha trabajado con cada tipo de madera.
#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.
#20 ¿Te has propuesto que todos perdamos karma por "exceso de votos negativos a un usuario"? No, yo no pico, ya no te casco más negativos, disfruta de mi indiferencia
Por qué las páginas que hablan de esos maravillosos seres que son los programadores siempre se acaban cayendo?
Service Temporarily Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Seguro que la página está alojada en una carpintería.
#8 Pues me pasa igual!!! He tenido que volver a abrir el enlace para ver que estaba en inglés. Una pena que no lo entienda en voz tan bien como lo leo.
Facebook también aplica técnicas NoSQL a sus BDD SQL. Por ejemplo, restringen el comportamiento relacional de la base de datos con cachés. De hecho NoSQL es conocido a veces como 'not only SQL'.
Totalmente de acuerdo. Aunque yo pensé que en la analogía los lenguajes de programación eran los materiales como el roble. De hecho a Java se lo llamó Oak (roble) al principio. Esto sí tiene un poco más de sentido ya que un material tiene unas propiedades (resistencia, flexibilidad, etc) qué sí creo que es importante conocer y dominar (a diferencia de los colores, que sólo tienen una cualidad y es básicamente irrelevante)... pero aún así la analogía es un poco mala. Si los materiales se refieren a los lenguajes ¿a qué se refieren los colores? Pues no se, supongo que a cualquier cosa irrelevante en la que te pidan tener experiencia. En cuanto a las rocas, los martillos y las pistolas de clavos quizá se refiera a entornos de desarrollo o los sistemas operativos donde se haga el desarrollo. La empresa a lo mejor busca alguien que desarrolle con Eclipse sobre Windows, pero a lo mejor el candidato prefiere el vi sobre Linux (por decir algo). Creo que es comprensible para las empresas en general (habrá casos que no) usar windows en todos los ordenadores, incluyendo los de los desarrolladores... ya que es bueno que todos en la empresa el mismo sistema para que haya un técnico que se encargue de preparar equipos pueda preparar tanto el ordenador de la secretaria o el comercial como el del desarrollador... o para que ciertas aplicaciones las usen todos los de la empresa (a las secretarias, comerciales o clientes normalmente no le vas a pedir que sepan de Linux). Pero claro, al desarrollador a lo mejor le parece un poco mal que le exijan usar Windows o ciertos entornos de desarrollo si él conoce cosas mucho mejores para hacer bien su trabajo.
En cuanto a la analogía en general del desarrollador con un albañil o con un carpintero también es desafortunada... El albañil pone ladrillos que es una cosa que más o menos puede hacer todo el mundo. Bueno, vale, y tiene que tener cierta práctica y maña con el manejo de ciertos materiales como cemento, yeso... o herramientas como la paleta o la plomada... pero son cosas muy evidentes, esa práctica es cosa de quizá un día y una vez conocido eso se usa lo mismo durante años. Sin embargo, los desarrolladores usan cosas mucho más complejas y propensas a errores o a ser demasiado lento si no estás concentrado o no tienes experiencia. El caso es que muchas empresas no son conscientes de eso y contratan carne al peso, lo consideran como algo que puede hacer cualquiera y que da igual a quién contratar.
#8#64
Le están haciendo una entrevista de trabajo a un tipo.
-Bueno, su currículo es sorprendente. Aquí pone que usted habla inglés
- Sí, claro, fui a un colegio bilingüe…
- Y también domina el francés
- Si es que mi madre es francesa…
-Y habla perfectamente alemán
- Si, es que mi padre nació en Munich…
- Y también conoce el italiano…
- Bueno, es que tuve una novia que vivía en Roma…
- Y también el portugués
-Bueno, es que en mi anterior trabajo me destacaron a Lisboa
-Muy bien, muy bien, queda usted contratado. Sólo una curiosidad: conociendo tantas lenguas diferentes… ¿Usted en qué piensa?
- ¿Yo? En follar, como todo el mundo.
#67 Lo de Oak viene del roble que se veia por la ventana de la oficina de James Gosling en Sun Microsystems...
"Initially, Gosling attempted to modify and extend C++ but soon abandoned that in favor of creating a new platform called Green and an entirely new language, which he called Oak, after the tree that stood just outside his office"
En peopleware hay una entrevista parecida, la analogía es con un malabarista esta vez, no me acuerdo al dedillo pero más o menos era asi:
- Así que es usted malabarista?
- si, y de los buenos!,
- Usted a echo malabares con varias bolas al mismo tiempo?,
- si por supuesto.
- Usted cuenta chistes graciosos mientras hace malabares?,
- pa partirse!
- Usted hace malabares con fuego?
- por supuesto!
- Pues muy bien entonces contratado!.
- esto... y no me va ha pedir que haga unos malabares para ver que tal lo hago?
- ummm no lo había pensado...
Si tenemos en cuenta que las personas que componen un equipo son, con mucha diferencia, el principal motivo del exito o fracaso de cualquier proyecto (por si alguien duda esto, leeros este articulo de cokburn de hace una decada: alistair.cockburn.us/Characterizing+people+as+non-linear,+first-order+) habría que tomarse mucha más en serio la contratación del personal tecnico de un proyecto. Y por supuesto esa contratación no la pueda hacer alguien de RRHH (que horrible nombre para un departamento por cierto) sino que lo ideal es que sea el propio equipo de desarrollo quien haga las entrevistas para ver si la persona encaja, tanto tecnicamente como personalmente, en el equipo. También es habitual pedir que se presenten trabajos anteriores (la cuenta de github a ver que tienes mismo) o pedir el desarrollo de algún pequeño proyectillo, otra posibilidad es pedir a la persona que pase uno o dos días trabajando con el equipo a ver si la cosa funciona. En nuestro caso no tenemos RRHH, somos muy pequeñitos, y las entrevistas siempre las hacemos gente del equipo. De momento nos ha ido bastante bien y hemos juntado un equipo de gente muy majete.
Lo que no tiene sentido es hacer entrevistas por alguien que recita de memoria algunos acronimos y no tiene ni la menor idea de lo que significan. Esto sin contar con la obsesión con los frameworks/tecnologías, cuando en realidad lo que importa son los principios y practicas que uno maneja (cosas como OO, patrones, TDD, SOLID etc,etc), las tecnologías van y bienen a toda la velocidad, tus principios/practicas las usaras durante toda tu vida profesional.
#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.
#48 Pues la verdad, yo con mis dos lenguas maternas no me doy cuenta. Generalmente inconscientemente me quedo con los conceptos que he leído/escuchado pero no suelo recordar en qué lengua estaban. Así que debe ser cuestión de como procesa la información cada persona. Probablemente mi nula memoria hará que me concentre más en los conceptos que en detalles, mientras otras personas podrán albergar más información en su cabeza. Pero eso sí, con el inglés sí me doy cuenta
#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.
"Y por supuesto esa contratación no la pueda hacer alguien de RRHH (que horrible nombre para un departamento por cierto) sino que lo ideal es que sea el propio equipo de desarrollo quien haga las entrevistas para ver si la persona encaja"
Yo creo que lo ideal es que haya dos entrevistas: la técnica (aptitud) y la de actitud (y si nos ponemos incluso más de dos pruebas, claro). Y en algunos casos la podría hacer la misma persona (no es lo ideal, pero es posible que se contrate a alguien para trabajar sólo)
¿Por qué no sólo la técnica? Pues porque uno puede saber mucho pero luego a lo mejor puede dar problemas de otro tipo: no saber trabajar en equipo o, al revés, necesitar trabajar con otros y no ser capaz de trabajar independiente... o ser una persona que no va a trabajar con muchas ganas (que sabe todo lo que hay que saber, pero que no le apasiona demasiado, lo cual acabará dando problemas), y un largo etcétera.
Pero vamos, que sí estoy muy de acuerdo con lo que dices ahí, porque lo normal en muchos casos es que se haga sólo la de actitud por una persona no técnica que le suenan todos los nombres a chino.
"otra posibilidad es pedir a la persona que pase uno o dos días trabajando con el equipo a ver si la cosa funciona"
Hombre, dependerá de la empresa, el contrato, etc... Aparte de que algunos aspirantes considerarían un abuso "trabajar gratis" dos días y posiblemente incluso sea ilegal (una cosa es preguntar al candidato, aunque sea en papel y otra que el tío se ponga en un ordenador y solucione algo... ). La ley contempla un periodo de prueba en los contratos, antes del cual puedes despedir sin indemnización y quizá sin aviso (eso sí, habiéndole dado de alta en Seguridad Social y pagando la porcioncita de sueldo que corresponda: una semana o dos o lo que sea). Date cuenta que alguna empresa puede tener un problema puntual (se me ha roto una tubería) y camuflar como entrevista de trabajo lo que sería hacerle un servicio gratis (una vez arreglada la tubería: "lo has hecho muy bien, ya te llamaremos"... y como no necesitan tener a esa persona fija nunca le llaman), sin intención ninguna de contratar a nadie (lo que en los concursos se llama declarar el premio desierto, recibiendo un montón de obras e ideas por nada). Por otro lado, para el propio equipo de desarrollo y para la empresa el trabajar dos días con cada candidato o preparar una especie de examen puede suponer una inversión considerable (yo creo que puede ser muy buena inversión, pero quizá no lo sea en algunos casos) y puede suponer pedir que algunos empleados hagan algo para lo que no fueron contratados (fueron contratados como desarrolladores pero no para hacer pruebas o exámenes a sus futuros compañeros).
#36#51#80 Yo hace poco hice la certificación de mongoDB (la da gratis la propia compañía 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.
#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.
Yo, gracias a mi educación, no me doy cuenta de cuando estoy leyendo algo en castellano, inglés o chino mandarín. Y eso que no tengo ni idea de chino mandarín.
#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: 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.
Yo soy de los que piensa que, a priori, todos saben más que yo en sus respectivos campos profesionales. Por eso no discuto de medicina con médicos o de arquitectura con arquitectos a menos que tenga una buena razón para hacerlo. Y por eso cuando me encuentro que MySQL no funciona del todo bien primero me pregunto qué estoy haciendo mal.
Porque si los ingenieros de Facebook o Tumblr siguen erre que erre utilizándolo, ¿será que son todos idiotas? ¿O será que saben algo que yo no sé?
Y si hay motores como XtraDB o TokuDB que funcionan sobre MySQL, ¿son sus creadores estúpidos por perder el tiempo con una BBDD tan ineficiente? ¿O yo soy un ignorante?
Quizá antes de pontificar y hacerte el interesante deberías plantearte que tu posición en el mundillo de las bases de datos es insignificante. Que no eres nadie, vamos.
Y lo más importante, que desde un principio me he referido a SQL, en general, y que no has tenido los cojones de pensar en Oracle o IBM DB2, por poner dos ejemplos paradigmáticos.
Puede que sea verdad y no tengas ni putísima idea. Puede que los ingenieros de media docena de empresas entre las más grandes de Internet sepan más que tú. Sé que es una idea alocada pero plantéatelo, ¿vale?
#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.
#69 ¿Qué inglés? ¿Eres capaz de entender y hablar en un inglés culto? El diccionario de la RAE tiene menos páginas y palabras que el Merrian Webster Collegiate, por ejemplo.
Curiosamente C11 sólo tiene 29 ficheros en su biblioteca estándar y está formado por 32 palabras clave. Es posiblemente uno de los lenguajes de programación generalista más concisos que existen.
#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.
#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.
#25 El lenguaje sería el tipo de madera, el color dice que es el cliente el que se lo pinta como quiere después de haberle entregado el sistema, así que supongo que será la configuración de la aplicación... Como si te piden que hagas un procesador de textos, y el entrevistador quiere saber si tienes experiencia en dejarlo instalado en el directorio aplicaciones en lugar del archivos de programa. Eso sería el color, algo que no tiene porqué hacer el programador-carpintero.
#48 Hombre, en el momento claro que te das cuenta. Pero si has entendido bien un texto, al rato ya no te acuerdas de ese detalle, y no podrías decir en qué idioma estaba.
A mí, además de con los idiomas, también me pasa cuando me cuentan un argumento, que me lo sé, pero muchas veces no sé si he visto la película o me he leído el libro. Y no es por ir de sobrado, es que el cerebro funciona así.
Carpintero: Cierto, es lo que hago.
E: ¿Durante cuánto tiempo?
C: 10 años
E: Genial, eso es bueno. Ahora tengo unas cuantas preguntas técnicas para usted para ver si se adecua a nuestro equipo, ¿de acuerdo?
C: Está bien, estoy de acuerdo.
E: Antes que nada, estamos trabajando en una subdivisión construyendo muchas casas marrones. ¿Ha construido alguna casa marrón con anterioridad?
C: Bueno, soy carpintero, por lo que construyo casas, y la gente la pinta del color que quiera.
E: Sí, lo entiendo, pero ¿puede indicarme cuanta experiencia tiene con el marrón? Aproximadamente.
C: Dios, no lo sé. Una vez que han sido construidas no me preocupo del color del que han sido pintadas. ¿Quizás seis meses?
E: ¿Seis meses? Bueno, estamos buscando a alguien con más experiencia en el marrón, pero déjeme hacerle unas cuantas preguntas más.
C: Bien, de acuerdo, pero la pintura es la pintura, ya sabe.
E: Sí, bien. ¿Qué tal con el nogal?
C: ¿Qué pasa…...
Pregunta:"Has usado la piedra"
Respuesta "Bueno, pienso que la pistola de clavos funciona mejor"
Pregunta: "Pero muchas compañías están usando la piedra"
Veo mucho resentimiento en tu comentario
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.
Zopenco.
Dunning-Kruger de libro.
Carpintero: Cierto, es lo que hago.
E: ¿Durante cuánto tiempo?
C: 10 años
E: Genial, eso es bueno. Ahora tengo unas cuantas preguntas técnicas para usted para ver si se adecua a nuestro equipo, ¿de acuerdo?
C: Está bien, estoy de acuerdo.
E: Antes que nada, estamos trabajando en una subdivisión construyendo muchas casas marrones. ¿Ha construido alguna casa marrón con anterioridad?
C: Bueno, soy carpintero, por lo que construyo casas, y la gente la pinta del color que quiera.
E: Sí, lo entiendo, pero ¿puede indicarme cuanta experiencia tiene con el marrón? Aproximadamente.
C: Dios, no lo sé. Una vez que han sido construidas no me preocupo del color del que han sido pintadas. ¿Quizás seis meses?
E: ¿Seis meses? Bueno, estamos buscando a alguien con más experiencia en el marrón, pero déjeme hacerle unas cuantas preguntas más.
C: Bien, de acuerdo, pero la pintura es la pintura, ya sabe.
E: Sí, bien. ¿Qué tal con el nogal?
C: ¿Qué pasa con eso?
E: ¿Ha trabajado mucho con el nogal?
C: Claro, nogal, pino, roble, caoba - lo que sea.
E: ¿Pero cuantos años de nogal tienes?
C: Dios, realmente no lo sé - ¿se supone que debería estar contando el nogal?
E: Bien, aproximadamente..
C: Vale, digamos que tengo un año y medio de nogal.
I: ¿Diría que tiene un nivel básico de nogal o eres un gurú del nogal?
C: ¿Un gurú del nogal? ¿Qué es un gurú del nogal? Claro, he usado nogal.
E: ¿Pero no eres un gurú del nogal?
C: Bueno, soy carpintero, por lo que he trabajado con todo tipo de maderas, ya sabes, hay algunas diferencias, pero creo que si eres un buen carpintero...
E: Sí, si, estamos usando nogal, ¿le parece bien?
C: ¡El nogal está bien! Lo que quieras. Soy carpintero.
E: ¿Qué tal el nogal negro?
C: ¿Qué pasa con él?
E: Bueno, tenemos algunos carpinteros de nogal con nosotros, pero ninguno era un carpintero de nogal negro. ¿Tiene alguna experiencia con el nogal negro?
C: Claro, un poco. Sería bueno tener un poco más por mi currículum, supongo.
E: Vale. Espera, déjeme comprobar la caja...
Ca: Adelante.
E: Vale, una cosa más por hoy. Estamos usando Roca 5.1 para golpearl os clavos. ¿Has usado Roca 5.1?
C: [Poniéndose pálido...] Bueno, sé que muchos carpinteros están empezando a usar rocas para golpear los clavos desde que Artesanos compró una cantera, pero sabes, para ser sincero he tenido más suerte con una pistola de clavos. O un martillo, para el caso. Resulta que me golpeo demasiado los dedos con la… » ver todo el comentario
En la realidad hubieran modificado el CV del vendedor de coches afirmando que lleva 10 años de experiencia en la carpintería de nogal con incrustaciones de grafeno.
Aplícate lo de #9 Ya no te das cuenta lo falso que eres, más bien
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.
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.
Al principio no pensaba votarlo, pero he conseguido leerlo sin muchos problemas y es un texto bastante gracioso (para mi gusto, claro está)
En Europa las personas de selección saben perfectamente lo que te están preguntando, no se dejan llevar por tu amplia experiencia aunque hayas trabajado exactamente con lo que piden, creo que en España se trabaja más por experiencia que por memorización de términos, mientras que en el resto de Europa es al revés
Gracias por la traducción #28
En serio, no te pases, por muy bien que entiendas el inglés es evidente que está en inglés y te das cuenta. Me doy cuenta yo con mis dos lenguas maternas ¿y no te das tú con el inglés?
En fin...
Para él tiene tan poco sentido como para un carpintero pensar en el color con que pintan de la madera luego de trabajarla, o cuántos años ha trabajado con cada tipo de madera.
books.google.es/books/about/El_Principio_de_Dilbert.html?hl=es&id=
Y utilizando MySQL con memcached y restringiendo el uso casi a un conjunto de relaciones clave-valor, Facebook hace lo mismo.
¿Soy cool?
Hay que ver la cantidad de jilipolleces que uno lee... ¡Y en mi lengua nativa!
Muchas gracias.
Pd: si alguien puede, que me traduzca el mensaje a ingles zopenco.
Y Facebook se ha deshecho de MySQL.
Y Tumblr ya se ha deshecho de todo lo que parezca SQL.
Y tal.
Infórmate un poquito anda: www.highscalability.com
Service Temporarily Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Seguro que la página está alojada en una carpintería.
Totalmente de acuerdo. Aunque yo pensé que en la analogía los lenguajes de programación eran los materiales como el roble. De hecho a Java se lo llamó Oak (roble) al principio. Esto sí tiene un poco más de sentido ya que un material tiene unas propiedades (resistencia, flexibilidad, etc) qué sí creo que es importante conocer y dominar (a diferencia de los colores, que sólo tienen una cualidad y es básicamente irrelevante)... pero aún así la analogía es un poco mala. Si los materiales se refieren a los lenguajes ¿a qué se refieren los colores? Pues no se, supongo que a cualquier cosa irrelevante en la que te pidan tener experiencia. En cuanto a las rocas, los martillos y las pistolas de clavos quizá se refiera a entornos de desarrollo o los sistemas operativos donde se haga el desarrollo. La empresa a lo mejor busca alguien que desarrolle con Eclipse sobre Windows, pero a lo mejor el candidato prefiere el vi sobre Linux (por decir algo). Creo que es comprensible para las empresas en general (habrá casos que no) usar windows en todos los ordenadores, incluyendo los de los desarrolladores... ya que es bueno que todos en la empresa el mismo sistema para que haya un técnico que se encargue de preparar equipos pueda preparar tanto el ordenador de la secretaria o el comercial como el del desarrollador... o para que ciertas aplicaciones las usen todos los de la empresa (a las secretarias, comerciales o clientes normalmente no le vas a pedir que sepan de Linux). Pero claro, al desarrollador a lo mejor le parece un poco mal que le exijan usar Windows o ciertos entornos de desarrollo si él conoce cosas mucho mejores para hacer bien su trabajo.
En cuanto a la analogía en general del desarrollador con un albañil o con un carpintero también es desafortunada... El albañil pone ladrillos que es una cosa que más o menos puede hacer todo el mundo. Bueno, vale, y tiene que tener cierta práctica y maña con el manejo de ciertos materiales como cemento, yeso... o herramientas como la paleta o la plomada... pero son cosas muy evidentes, esa práctica es cosa de quizá un día y una vez conocido eso se usa lo mismo durante años. Sin embargo, los desarrolladores usan cosas mucho más complejas y propensas a errores o a ser demasiado lento si no estás concentrado o no tienes experiencia. El caso es que muchas empresas no son conscientes de eso y contratan carne al peso, lo consideran como algo que puede hacer cualquiera y que da igual a quién contratar.
Le están haciendo una entrevista de trabajo a un tipo.
-Bueno, su currículo es sorprendente. Aquí pone que usted habla inglés
- Sí, claro, fui a un colegio bilingüe…
- Y también domina el francés
- Si es que mi madre es francesa…
-Y habla perfectamente alemán
- Si, es que mi padre nació en Munich…
- Y también conoce el italiano…
- Bueno, es que tuve una novia que vivía en Roma…
- Y también el portugués
-Bueno, es que en mi anterior trabajo me destacaron a Lisboa
-Muy bien, muy bien, queda usted contratado. Sólo una curiosidad: conociendo tantas lenguas diferentes… ¿Usted en qué piensa?
- ¿Yo? En follar, como todo el mundo.
"Initially, Gosling attempted to modify and extend C++ but soon abandoned that in favor of creating a new platform called Green and an entirely new language, which he called Oak, after the tree that stood just outside his office"
en.wikipedia.org/wiki/Oak_(programming_language)
- Así que es usted malabarista?
- si, y de los buenos!,
- Usted a echo malabares con varias bolas al mismo tiempo?,
- si por supuesto.
- Usted cuenta chistes graciosos mientras hace malabares?,
- pa partirse!
- Usted hace malabares con fuego?
- por supuesto!
- Pues muy bien entonces contratado!.
- esto... y no me va ha pedir que haga unos malabares para ver que tal lo hago?
- ummm no lo había pensado...
Si tenemos en cuenta que las personas que componen un equipo son, con mucha diferencia, el principal motivo del exito o fracaso de cualquier proyecto (por si alguien duda esto, leeros este articulo de cokburn de hace una decada: alistair.cockburn.us/Characterizing+people+as+non-linear,+first-order+) habría que tomarse mucha más en serio la contratación del personal tecnico de un proyecto. Y por supuesto esa contratación no la pueda hacer alguien de RRHH (que horrible nombre para un departamento por cierto) sino que lo ideal es que sea el propio equipo de desarrollo quien haga las entrevistas para ver si la persona encaja, tanto tecnicamente como personalmente, en el equipo. También es habitual pedir que se presenten trabajos anteriores (la cuenta de github a ver que tienes mismo) o pedir el desarrollo de algún pequeño proyectillo, otra posibilidad es pedir a la persona que pase uno o dos días trabajando con el equipo a ver si la cosa funciona. En nuestro caso no tenemos RRHH, somos muy pequeñitos, y las entrevistas siempre las hacemos gente del equipo. De momento nos ha ido bastante bien y hemos juntado un equipo de gente muy majete.
Lo que no tiene sentido es hacer entrevistas por alguien que recita de memoria algunos acronimos y no tiene ni la menor idea de lo que significan. Esto sin contar con la obsesión con los frameworks/tecnologías, cuando en realidad lo que importa son los principios y practicas que uno maneja (cosas como OO, patrones, TDD, SOLID etc,etc), las tecnologías van y bienen a toda la velocidad, tus principios/practicas las usaras durante toda tu vida profesional.
Se hacen tantas cosas mal...
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.
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.
"Y por supuesto esa contratación no la pueda hacer alguien de RRHH (que horrible nombre para un departamento por cierto) sino que lo ideal es que sea el propio equipo de desarrollo quien haga las entrevistas para ver si la persona encaja"
Yo creo que lo ideal es que haya dos entrevistas: la técnica (aptitud) y la de actitud (y si nos ponemos incluso más de dos pruebas, claro). Y en algunos casos la podría hacer la misma persona (no es lo ideal, pero es posible que se contrate a alguien para trabajar sólo)
¿Por qué no sólo la técnica? Pues porque uno puede saber mucho pero luego a lo mejor puede dar problemas de otro tipo: no saber trabajar en equipo o, al revés, necesitar trabajar con otros y no ser capaz de trabajar independiente... o ser una persona que no va a trabajar con muchas ganas (que sabe todo lo que hay que saber, pero que no le apasiona demasiado, lo cual acabará dando problemas), y un largo etcétera.
Pero vamos, que sí estoy muy de acuerdo con lo que dices ahí, porque lo normal en muchos casos es que se haga sólo la de actitud por una persona no técnica que le suenan todos los nombres a chino.
"otra posibilidad es pedir a la persona que pase uno o dos días trabajando con el equipo a ver si la cosa funciona"
Hombre, dependerá de la empresa, el contrato, etc... Aparte de que algunos aspirantes considerarían un abuso "trabajar gratis" dos días y posiblemente incluso sea ilegal (una cosa es preguntar al candidato, aunque sea en papel y otra que el tío se ponga en un ordenador y solucione algo... ). La ley contempla un periodo de prueba en los contratos, antes del cual puedes despedir sin indemnización y quizá sin aviso (eso sí, habiéndole dado de alta en Seguridad Social y pagando la porcioncita de sueldo que corresponda: una semana o dos o lo que sea). Date cuenta que alguna empresa puede tener un problema puntual (se me ha roto una tubería) y camuflar como entrevista de trabajo lo que sería hacerle un servicio gratis (una vez arreglada la tubería: "lo has hecho muy bien, ya te llamaremos"... y como no necesitan tener a esa persona fija nunca le llaman), sin intención ninguna de contratar a nadie (lo que en los concursos se llama declarar el premio desierto, recibiendo un montón de obras e ideas por nada). Por otro lado, para el propio equipo de desarrollo y para la empresa el trabajar dos días con cada candidato o preparar una especie de examen puede suponer una inversión considerable (yo creo que puede ser muy buena inversión, pero quizá no lo sea en algunos casos) y puede suponer pedir que algunos empleados hagan algo para lo que no fueron contratados (fueron contratados como desarrolladores pero no para hacer pruebas o exámenes a sus futuros compañeros).
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.
Te votaría positivo si pudiera.
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.
Yo, gracias a mi educación, no me doy cuenta de cuando estoy leyendo algo en castellano, inglés o chino mandarín. Y eso que no tengo ni idea de chino mandarín.
P.D. Ya, puestos a vacilar...
#8
#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: 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.
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
Yo soy de los que piensa que, a priori, todos saben más que yo en sus respectivos campos profesionales. Por eso no discuto de medicina con médicos o de arquitectura con arquitectos a menos que tenga una buena razón para hacerlo. Y por eso cuando me encuentro que MySQL no funciona del todo bien primero me pregunto qué estoy haciendo mal.
Porque si los ingenieros de Facebook o Tumblr siguen erre que erre utilizándolo, ¿será que son todos idiotas? ¿O será que saben algo que yo no sé?
Y si hay motores como XtraDB o TokuDB que funcionan sobre MySQL, ¿son sus creadores estúpidos por perder el tiempo con una BBDD tan ineficiente? ¿O yo soy un ignorante?
Quizá antes de pontificar y hacerte el interesante deberías plantearte que tu posición en el mundillo de las bases de datos es insignificante. Que no eres nadie, vamos.
Y lo más importante, que desde un principio me he referido a SQL, en general, y que no has tenido los cojones de pensar en Oracle o IBM DB2, por poner dos ejemplos paradigmáticos.
Puede que sea verdad y no tengas ni putísima idea. Puede que los ingenieros de media docena de empresas entre las más grandes de Internet sepan más que tú. Sé que es una idea alocada pero plantéatelo, ¿vale?
#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.
Curiosamente C11 sólo tiene 29 ficheros en su biblioteca estándar y está formado por 32 palabras clave. Es posiblemente uno de los lenguajes de programación generalista más concisos que existen.
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.
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.
En serio, no te pases, sí que te das cuenta ¿o no te has dado cuenta? ¿acaso no has puesto los ojos como un chino?
A mí, además de con los idiomas, también me pasa cuando me cuentan un argumento, que me lo sé, pero muchas veces no sé si he visto la película o me he leído el libro. Y no es por ir de sobrado, es que el cerebro funciona así.