Fallacies of the tech recruitment process
Note: I would like to thank @gbarrs for reviewing my blog post almost instantly, and also the offer of @GraemeF, @MarkRendle, @swaggerdmangene and @moldyseaswimmer to be a reviewer. Without them, there would be a lot more Dunglish in this post...
Why I like my job.
I have been hooked into computers ever since I wrote my first few lines of Basic on my mothers' brand new TRS-80 Model 3 with 64Kb of ram and 2 - yes 2 !!! - diskdrives of a whopping 178Kb. (Actually, I did not write the code, but I copied it character by character from a textbook that might have looked like this, but in my defense, I was about 7 years old).
The first program probably looked like this:
10 PRINT "HI, WHAT IS YOUR NAME?"
20 INPUT N$
30 PRINT "HELLO, ",N$
Exciting, is it not? In the five years that followed, I learned almost every in and out of this machine, where to peek and poke in memory, how to set pixels on the screen (monochrome, 128x48 resolution, imagine that), which ASCII codes to send to my dot matrix printer to switch control modes, ...
When I was about twelve years old, I had written a drawing application, complete with circles, boxes, Bresenham lines, and even the possibility to print the graphics on the (very noisy) dot matrix printer (remember those printers which had to print on chained paper?).
Then we got our first 80286, an IBM-compatible PC that ran at a mind-boggling speed of 16 Mhz, with 4 megs of memory and a color VGA screen... A screen buffer of 320x200 pixels with 256 colors was available directly by poking at the #A000 segment, and we discovered a whole brave new world out there using color pallette rotation, and apps like Deluxe Paint. We even managed to do blitting by reprogramming the VGA-card directly by poking video card ports and bypassing BIOS...
As years progressed I got involved in the Belgian BBS/hacking/cracking scene, but after one of our fellow BBS's got all his material confiscated, we decided to focus on the demo scene, as we had some experience writing some "cool intros" for our and other BBS's.
In the demo scene, we were not very succesfull, but we did have a lot of fun. (This was the pre-internet-era folks, so figuring out how to write a software 3D rasterizer from disassembling other demo 'exe' files was a bit of a challenge. The example below was one of those demos we completely disassembled to figure out how everything worked.)
The biggest achievement that is now still traceable would probably be the fact that I did manage to come second in a 4K assembler demo on a demo party in Mons (Which is now, in the hardware-accelerated era, probably pretty unspectacular) .
Fast forward to a few years later...
I walked a very diverse path, both in programming languages (e.g. all kinds of Basic, Turbo Pascal, x86 assembly, C, C++, C--, (PL/Transact)-SQL, Smalltalk, lua, ruby, shell scripts, C#, some 4GL's and probably a dozen of others), in platforms (pre-PC area, Windows, *nix , VMS, AS400, ...) as well as in my career (Oracle dev/DBA, C++ dev, c# dev, ICT manager, technical analist, independent consultant).
As I got involved with .Net (I wrote my first app framework when independent using a Beta of .Net 1.0), I started focussing on this new thing, first Winforms, and afterwards ASP.NET, and finally ASP.NET MVC.
I skipped things like Silverlight, WCF, WWF and XAML as they all seemed way to much overhead for achieving something to me.
However, in the last few years I started realizing something...
If you focus on the tech stack, you are focussing on the wrong thing!
Spending all those years behind a PC and the last 15 years interacting with both business and development, I started realizing the biggest problem is not in the tech stack, but it is in the interaction between business and technology that the biggest problems occur.
From my numerous experiences with all those different environments, I know by experience that learning a new tech thing usually takes somewhere between a week and a few months before you can be productive (becoming an expert is a different thing, but that is not what I am referring to here).
The hardest part is not in the tech, but it is in learning how to scope, plan and build software that matches the business' expectations. That is something one cannot learn in a few weeks, let alone months.
This is exactly the reason why I read numerous business books every year, and have taken several sabatticals of a few months studying new things (more specific: Behaviour Driven Development, Domain Driven Design including the Command-Query responsibility Seggregation thing, as well as the whole Lean startup development process).
I did make some mistakes in the past, but hey, I am learning from them... (On a side-note, you should really check out this blog post from Seth Godin about the difference between a failure and a mistake.)
"What does this have to do with the tech recruitment process?"
The last few years all my business leads came from my personal or online network. Some experiences turned out pretty good, and some a bit less.
Unfortunately, my current client's project got delayed for a few months at first, and cancelled afterwards by his customer, so I am currently short on leads. (Luckily they are now giving me the opportunity to migrate them from a waterfall to a more scrum-like approach, so I am not quite broke yet; however, the job ends this month.)
As I got short on leads, I decided to accellerate my job/project search using companies that play an intermediate between me and the customer, and I was flabbergasted by most of them...
Most recruiters just seem to play "Keyword lottery"
People from my personal/social network do not hire me because I know a certain tech stack, they hire me because they think I am capable of solving the problem they have.
However, almost every recruiter that contacts me - the exceptions know who they are - just search their database for keywords, and contact you based on those keywords. In the rare case that you do get asked some technical questions, the interviewers either do not know anything about the subject, or they start asking questions about the things irrelevant to the job.
In my experience this keyword approach is as usefull as taking an asprin when your leg is broken. Here is an excerpt from a recent conversation I had with Szymon Pobiega on twitter:
@tojans Same for any technology, approach and methodology. Juniors tend to write they are experts if they heard a buzzword more than 3 times— Szymon Pobiega (@SzymonPobiega) november 15, 2012
Every single recruiter I talk to talks about how they would like to bond and invest into people, and really contribute and build a relationship, so I point them to my blog, and tell them this is exactly who I am. However, almost nobody - again, some exceptions - decided to invest in me by reading the blog and finding out what my exact profile is.
There are exceptions to this rule, and some even go a long way to acquire your trust and confidence, for example the story of github recruitment comes to my mind; who would not love to be treated like that?
I intended to make this a short post (i.e. 1K words), as it was more of a rant then a true essay, but as usual I am having a hard time respecting the limit.
I hope I did not blow any of my own bridges by writing this post, but I find this whole recruiter thing rather frustrating, as the business model for most of them seems to evolve around introducing as many candidates as possible to as many potential customers as possible, filtering only by keywords...
As the globalization and "enterprise consumerization" continues, I assume the world will evolve into an interconnected network of people first and organizations second, so I think that recruitment organizations that are simply focusing on getting the most contracts by using pure volume will not manage to survive in the future. (Maybe they should try reading the Agile manifesto.)
Once again I will close this blog post with a quote:
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge." - Stephen Hawking