Hacking candidate search with post-it notes

This happened long before LinkedIn,Taleo, or Jobvite existed. The trick hack still works. Give it a try.

A friend needed to fill in a hurry a developer position for a client. He posted the opening in a job site and waited for several days hoping he would find a good candidate for the job; but It didn’t happened.

He received 5-10 CVs; none of them was a good match for the position. Some lacked experience, and others didn’t have enough technology knowledge.

We conceived this hack after lunch. He told me about his problem trying to fill this position and what started as a joke ended.

Sourcing Hack

0- Go to a physical / brick-and-mortar bookstore.

1- Find a book the potential new employee will need to use in the job. For developers a safe bet is any O’Reilly language cookbook, or Pragmatic Programmers book.

2 – Choose a chapter from the table of contents that deals with the specific skill that’s giving you a headache.

3 – Insert a postit note somewhere within that chapter that says something like this:

I have a job for you. Call/email me for details if you understand this subject well

It worked :-)

(If you liked this post, contact me on LinkedIN here)

Please don’t ever make “backups” like this


Today we spotted (again) the stupidestoldest “backup” bug in history from a script that should backup a 300GB/day repository.

Can you spot the bug? (ps: Don’t try to do this at homework):

 tar -czf ${DEST}/${TIMESTAMP}_reports.tar.gz *${TIMESTAMP}*csv
... some more commands here ...
rm -f *${TIMESTAMP}*csv

There might be a race condition between the tar command that stores the files and the rm command that removes them.
How? some might say. I have a timestamp in the csv filename that *should* guarantee that I am removing the right files. Isn’t it?


First, there might be a race condition between the TAR and the RM command. The set of files that you backup and remove can be different.

If you want to actually remove the same files you have in the tar file you have two options:

  1. Make a list of the files that actually match your condition, then backup them with TAR and then remove them.
  2. If you’re using GNU tar, use the –remove-files option. This way tar removes the files as soon as they are stored in the TAR archive, thus making the operation atomic with less temporary disk space requirements than the previous version.

Morale: If your backup tool can remove files (some vendor call this “archive”) as soon as they are backed up, use that feature.

BTW: Option#1 might be done carefully to avoid another related bug. Can you see how?

The two types of enterprise software you can sell


There are only two types of enterprise software:    Software that IT departments buy , and

  •     Software that people from a Busines s Unit buy.

In the first group you can find the “usual suspects”: Oracle, Microsoft, IBM, etc…

IT departments usually buy something that they can use for more than one project. For instance, they don’t buy an Oracle license and setup a different database server for every application.

Selling to IT is hard; but there are some opportunities as well. IT budgets shrink even in “good” years – price and/or total cost of ownership is an important selling point here. New, disruptive technology (that affects TCO) can also make you sell something; but it’s harder to justify.

Selling to the second group – Business Units – may be easier to sell to an IT department. As a rule, Business Units don’t manage their own IT (there are some exceptions, but this is he rule). Instead, they consume IT services from the central IT department and they hate it because IT is not flexible enough form them. Remember that word: FLEXIBILITY is your primary selling point.

A Business Unit will buy all hardware, software, or services they need to do the job.

Use three state IfTTT rules in your #@! software, dammit^H^H^H^H^H^Hplease

I’m tired of the way if-this-then-that software manages rules.

If you’ve grown beard (and gone a bit bald, like me) administering IfTTT software like firewalls, ETL, mail filters, web crawlers, yahoo-pipes, or just IfTTT; I’m sure you have spent a lot of timecleaning old configuration rules.

When you are part of a team that administers – for example – a firewall, you may end up asking why did someone added that rule in your firewall and why. Of course, you can always disable that rule (that’s the GUI equivalent of commenting out some lines fomr a configuration file) and cross your fingers waiting until a) someone complains or b) you remove the rule after a prudential amount of time.

The problem is that most (if not all) rule-based software doesn’t tell you how much times a disabled rule matches. And that’s a problem.

Before coding the next IfTTT rule-based software consider using three states for your rules:

  • State 1: Production – Nothing new here. Just apply the rule.
  • State 2: Inactive (log only) – The rule is there; but it’s not alive. When this rule matches, you just increment a counter and and keep searching for the next rule that matches (I wish all routers would have had this feature for years).
  • State 3: Disabled (not deleted). Just “commented-out” and kept for reference.

Disclaimer: you can mimic this behaviour in some firewalls combining the allow and log actions, and digging in your logs; but it’s not clear and needs a lot of time for analisys.

This is specially usefull in a machine-to-machine (m2m) scenario. Most rules won’t have a person behind that will complain if there’s something wrong. In M2M the robot in the other side will take some decision based on it (limited) pre-programmed actions and you need to know how many times a rule does apply and if there’s a dumb robot trying to hit a rule you are about to remove.

¿ Es el fin de Java ?

Me ha llamado mucho la atención éste gráfico de ITJobswatch UK en la que mide el número de ofertas de trabajo en las que se pide Java:

Me llama mucho la atención la caída en picado del año 2007. Supongo que la crisis financiera debió hacer bastante daño a los programadores en Java de la City londinense; sin embargo esa caída no se ve si buscamos “Developer”, ni otras tecnologías como .NET.

En los últimos 8 años Java ha pasado de ser demandado por un 36% de las ofertas de empleo a poco más de un 28%.

Parece que la demanda se ha ido a la plataforma .NET de Microsoft y a lenguajes entornos más sencillos como PHP o Ruby. Mientras tanto lo que tira de la demanda de Java es el mantenimiento de aplicaciones existentes y el desarrollo de Hadoop.

PD: Si la caída de demanda de Java te llama la atención, echa un vistazo a las ofertas de trabajo para UNIX (no Linux: UNIX del de toda la vida como Solaris, IRIX, HP-UX..).

Gestión de Tecnología, Seguridad, y Negocios, por Íñigo González.