A veces hago entrevistas laborales. Una de nuestras oficinas está en México. En mi compañía NO hacemos pruebas psicométricas, y solicitamos currículums sin foto, edad o información personal. Mi interés principal es 1) Eres listo, puedes escribir código al nivel que requerimos?, 2) Trabajas sin tenerte que decir qué hacer a cada rato? y 3) Tienes pasión por escribir software y por ayudar a otros a escribir software?

Evidentemente, todos los candidatos van a decir que sí. La cosa es probarlo. La validez de los metos con los que probamos cualquier cosa en cuanto a reclutamiento es lo que está en cuestión aquí.

El sistema de reclutamiento en México en general es muy probre, y yo creo que es cuestión más cultural que por "falta de profesionalismo" - palabra muy interesante porque cada persona tiene una definición diferente (por ejemplo los reclutadores que hacen eso parte de la entrevista probablemente piensan que eso es muy profesional) y nos permite quejarnos sin repercusiones.. "Yo si soy profesional, él/ella no" piensan orgullosamente ambas partes, normalmente al mismo tiempo, sin darse cuenta de que ambos al pensar eso están permitiendo que su ego les enturbie la posibilidad de trabajar juntos.

Por un lado la actitud de algunos empleadores es de intercambiar piezas. En mi caso prefiero pensar que la empresa es una persona, y cada quién es una parte importante de una misma entidad. Así que perder a un empleado es más como perder una mano que como perder una pieza en una maquinaria. El comentario de la lealtad e "irte sabiendo más" me preocupó porque en mi caso yo quiero que todos mis desarrolladores cuando se vayan de mi compañía sepan más. Si nó de qué les sirvió estar con nosotros? Espero y exijo que cumplan con sus non-competes y que se comporten éticamente, por supuesto, pero les deseo lo mejor y a lo mejor un día regresan, o se vuelven nuestros clientes o proveedores. Tratamos de serles nosotros también leales a nuestros empleados esperando que no necesiten irse - Si se fué, es un problema de retención mío, no un problema de lealtad de mi empleado. Pero el mercado es el mercado.

Por el lado de los empleados, hay una tendencia clasista de pensar que el empleador ("patrón" que es una palabra con "baggage" cultural y es increible que todavía se use y hasta en ámbitos legales) es o malvado, "no nos quiere dar el empleo" (entonces porqué puso el anuncio??) o la tiene contra el pobre empleado (proletario) de alguna manera. Estoy seguro de que hay algunos empleadores que son así, pero en general éstos no retienen a buenos empleados por mucho tiempo y acaban tronando después de pelearse con todo su equipo. Sabiendo esto, si piensas así porqué te quieres poner en esa situación? Mejor ve a aplicar en otro lado donde pienses que son buenas personas.

Pero en vez de expresar nuestras frustraciones mediante el quejarnos porque nuestro reclutador es muy joven o nuestro candidato es muy viejo (discriminación por edad en ambos lados), o asumir que el reclutador es incompetente porque te pone ciertas preguntas (cómo sabes si esta persona no es obligada a preguntar eso antes de entrar "en materia"?), o "éste es de otro país" (empleado o empleador tienen menor o diferente valor por ser o no ser de país X - sí, Estados Unidos incluido?), mejor pónte en los zapatos del reclutador durante el periodo entero de la entrevista, desde el enviar el resume+cover letter hasta la contratación. Una vez adentro, puedes averiguar el motivo por el cual la entrevista se hace así y cambiarlo.

Por ejemplo, agencia o no, un reclutador promedio tiene que revisar a veces cientos de curriculums que la computadora puso como "posible". 90% de ellos no llegarán a entrevista. Todos los currículums dicen que la persona es "capaz", "profesional", "a team player", "learns fast". Dime tú, si tengo 400 currículums que regresó el computer match y 300 dicen que son profesionales, lo creo nomás porque lo leo? No, si le dedico sólo 10 segundos por cada uno, rápido tirando los que no me atraen inmediatamente o no parecen muy buenos, termino reduciendo la pila a unos pocos para hacer las llamadas, y eso me tomó una hora entera. Después hay que hablarles y eso es una hora en promedio cada uno mientras escribo mis notas y envío el currículum interesante después de hablar. Ahí te fué media semana. Todo este tiempo es caro, y las compañías no reciben dinero por este tiempo.

En la entrevista es lo mismo. La pregunta de "porqué te contrato a tí y no a otros?" te permite venderte a tí mismo y demostrar pasión por tu trabajo, te permite decir qué piensas que es tu ventaja en el mercado competitivo, y le permite al reclutador comparar intereses personales con los de la compañía. También es oportunidad para sacar tu portafolio de trabajo si lo tienes y mostrar cómo le ahorraste a la compañía dinero, hiciste una venta mayor o decir una anécdota que pruebe que el valor que proporcionas a la compañía es mucho mayor al costo que le incurres mediante tu salario. Obviamente, no hay respuesta "exacta" para todas las compañías. Si la hubiera, no la preguntarían por el mismo motivo por el que no importa que todos dicen que son muy "profesionales".

El "qué sabes/investigaste acerca de nuestra compañía?" demuestra interés en ayudar a los otros empleados de la compañía (un grupo de trabajo de humanos, no una "entidad malévola") a cumplir sus metas desde el momento en que aprendes que existe. Si lo viste, sabes lo que producen y venden y sigues aquí, demuestra que al menos puedes verte a tí mismo haciendo una carrera al menos a mediano plazo en la compañía para ayudarles en sus metas, en vez de nada más preocuparte por el siguiente cheque.
Dices que eres profesional? Pórtate entonces como un colaborador, que eres antes de la entrevista (estás colaborando con ellos para averiguar si puedes ayudarles), y cuando te contraten serás un socio y no un empleado. Demuéstrales que averiguaste lo que hace la compañía, y en particular cómo es su flujo de dinero (qué venden? Quién los provee? Cómo funcionan sus economías de escala?), e incluso que a lo mejor averiguaste algo interesante relacionado con tu carrera. Por ejemplo, para contadores: fíjate que averigué que la estructura fiscal de una compañía como esta permite creatividad en deducir XXXX clase de gastos - pum, a lo mejor les ahorras dinero rápido. O para desarrolladores - Oye, noté que su sitio de ventas están usando servidor de aplicaciones X y hay unos parches importantes que pueden hacer ese servidor más rápido. Convence a tu entrevistador que si tu pasión por tu vida y por tu carrera te hace obsesionarte por ayudar a cualquier compañía antes de que te conozcan, es más probable que seas más que otra persona en otra silla recibiendo un salario, en vez de eso ahora eres un socio, y todos quieren trabajar con gente así.

Créanme que es la total esperanza del reclutador que tú seas el adecuado, porque eso quiere decir que pueden dejar de entrevistar gente donde hacen las mismas preguntas una y otra vez (aburridísimo, particularmente si el interlocutor no tiene pasión o interés real en lo que la compañia hace).

La carta termina con lo siguiente:

Miren, señores. Yo sólo quiero un empleo. Uno en el que volver a sentirme digno, uno que me permita levantarme todas las mañanas con nueva ilusión. Una empresa que me quiera por lo que contribuyo, que me respete y cuente conmigo.
Así que por favor, hagan bien su trabajo que yo haré el mío.

Que es precisamente el problema de actitud del que estamos hablando. Parte de tu trabajo es el explicarles a ellos por qué tú eres la respuesta a sus necesidades. Tienes el mismo valor que ellos, pero está en tí comprobarlo. Ánimo.

If this sounds attractive to you, read on to see how you can use git as the sandbox for your svn repository and to learn about the features of git.

The basics of Git

In git, every change is a simple delta of multiple files with a SHA1 string as its name, so that it can be uniquely identified across branches, and a branch is just a list of SHA1s that make up that branch. In a sense, the SHA1 deltas themselves can be thought of as a mini-branch, which means that merging is a lot more common. But don't fret, git is a lot smarter about merging than most content tracking systems.

Git does not track "files". It instead tracks "blobs", which is partial file data. Ignore files and folders work mostly as you would expect, except empty folders are not tracked.

Git also tracks "remote" sets of deltas and remote branches, which are, like a local branch, a collection of deltas. Finally, it can track the deltas that have been uploaded to the server in a particular remote branch versus the ones that are just local to your machine.

What Git makes possible

These basic building blocks allow git to be a very powerful content tracking system, in particular because it allows you to commit several times (maybe for weeks) into your local repository until your feature works perfectly, and only then submit all your commits to the server. Because it lower the barrier of effort in creating a branch (cheap, atomic and no server required), it allows you to manage your work in "feature branches".

How do I get it

On Mac OS X, use MacPorts. On Windows, you can use Cygwin. On Linux a simple rpm or apt install should do it.

Some Useful Git Tools

OS X Specific

• But I don't like how Gitk is so ugly..! Ok you baby, you have two options: GitNub for basic stuff, GitX for more gitk-level functionality. Gitk is still the best though.
• I have TextMate Zen. Then you will like the Git TextMate Bundle. Control-Shift-G. If you use git-svn, you still need to do dcommit and rebase manually though.

How can I learn how to use it

The Git Manual is a great start. There is also a pretty good two-part tutorial by Bart Trojanowski. If you like learning using books instead, Pragmatic Version Control Using Git by Travis Swicegood is pretty good.

technorati tags:
textmate,
blogging
tools

And here's a picture of it in action.

Rocks, I tell you, it rocks. Maybe now I can start blogging more often, if it's right on my editor.

It doesn't support technorati tags, but I just edited the bundle template to remind me.

Before I was using Flock to post, this works a bit different but it doesn't require to have another app open.

Development: "You want answers?"
Marketing: "I think we are entitled to them!"
Development: "You want answers?!"
Marketing: "I want the truth!"
Development: "You can't handle the truth!!!

Son, we live in a world that requires software. And that software must be built by people with elite skills. Who's going to build it? You, Mr. Marketing? You, Mr. Sales? You, Mr. Finance? You, Mr. Human Resources? I don’t think so.

Agile Chronicles: A Few Good Managers

technorati tags:agile, funny, development

1. What was expected
2. What actually happened

Translation: assertTrue should always, always have a message.

Consider the following:

 
assertTrue(mv.getViewName()
    .startsWith(myController.getSuccessView()));
 

This will only return "assertion failed". Which is great, but how do we know what happened? If this is buried on one of the lunt automated remote builds, how am I supposed to know what is going wrong? Which is the expected? What actually happened?

A much better version of the same looks like this:

 
assertTrue(
    "Was expecting something like "
        + myController.getSuccessView() + " but was "
        + mv.getViewName(),
    mv.getViewName()
        .startsWith(myController.getSuccessView()));
 

Same assertion, but now it tells me more specifically what's going on and I can fix bugs with it. Once I set this on the test, it becomes easy to see what was going on.

I recently had a Saturday with some other Bay Area developers where we did a lot of thinking about testing, so expect some more advice in the future as I collect my notes.

Remember the goal of unit tests is to "find bugs" (thanks Harry!). An assertion without an associated message merely notifies you that a bug occurred but doesn't actually "find it". As you are writing your unit tests, make sure you find it as well.

technorati tags:testing, junit, assertions, java

technorati tags:scrum, estimation

After doing this for a little bit and then having a small crisis on a Scrum project (where requirements for the current sprint kept changing during the sprint). I realized that one of the big sources of mental stress is precisely trying to do both at once. Our brains just don't seem to be able to handle it.

The way I see it, our brains are pretty much still cavemen brains, used to running out and hunting deer for a very long period of time, and then going out and foraging for food for another long period of time. If you get into a "chase" mode when you're foraging, it means you're the one being chased, and it automatically fires our stressors.

technorati tags:gtd

In this article, Ted Bergeron shows you how to use the Validator component of Hibernate Annotations to build and maintain validation logic easily in your Web apps.

Hibernate can meet your validation needs

technorati tags:java, validation

Here’s a few tips I’ve learned in my short time on this earth that have kept me from getting too much accomplished.

fullduplex.org » How to Do Nothing at Work, and Get Away With It

He goes on to explain his "tips".

It left me thinking two things. First, I'm very glad he's not on my team, second, the value of scrum and agile methodologies to get rid of the dead weight. Here's my response to it:

I'm a lead in a web development team, and I manage and assign work for web developers. This is the behavior that gets you fired from my team.

Let's analyze it shall we?

Look Busy/Look Stressed: We're a Scrum team, we meet every day to talk about what we did the day before, what we will do today, and what roadblocks we have in our way. So why aren't you asking for help? I have no use for web devs with such little people skills that they won't even ask other members of their peer group for help. If you can't be on a team, maybe you should go independent and not work on a team.

Speak Quickly/Hide/Break Limb/Make Excuses/Never Leave your office/rearrange furniture,etc: The only thing here that may work is breaking a limb. And even then if that happened to you it would make you a prime candidate for pairing with another developer. All the others, your non-activity would show up on the cvs commit log. In my team we have a great cvs mailer that shows colored differences of what you did, and I check it daily.

Choose a Profession people don't understand: Your manager is probably not a techie, or he's as lazy as you are about checking your work. You're a perfect example why only techies can manage techies, and techie managers need to code at least 20% of their time on the current project so they can keep their skills. Also following the cvsspam list helps understand the issues.

So you see, using Scrum or other Agile methodologies underscores the lack of value of these people and will make it obvious who needs to drop off your team. Either that or they'll shape up via peer pressure, which in the long run will make the ex-lazy team member happier as well.

technorati tags:agile, scrum, lazy, development

Try to put the big train and attach it to the little train. It doesn't work. How about the toy car? Nope, not that either. At the end he has all the magnetic pieces put together properly and then says "choo-choo!" as he pulls the locomotive. Now he's trying to place a small "Jojo Circus" figure as a "passenger" on top of the train. He pulls it a couple of times but it keeps falling, until he realizes that the bendy legs fit perfectly around the oil tanker car. Then he pulls everything apart and tries it again, this time in a different configuration.

Will Wright on Wired: 

Just watch a kid with a new videogame. The last thing they do is read the manual. Instead, they pick up the controller and start mashing buttons to see what happens. This isn't a random process; it's the essence of the scientific method. Through trial and error, players build a model of the underlying game based on empirical evidence collected through play. As the players refine this model, they begin to master the game world. It's a rapid cycle of hypothesis, experiment, and analysis.

Wired 14.04: Dream Machines

 
Think about this when you write your next piece of software - these are the people you are writing software for (after all, most young adults grew up playing videogames).  The previous generation read a lot more than they experimented. The new generations try things out first, then collect their experiences and blog about them, then maybe read someone else's experiences to find kindred spirits. So make your software easy to experiment with, and make most everything undoable.

technorati tags: design, random