BS in HR, part 1:
The Stranded Developer
A cold call on a hot afternoon
“Can we have a little talk about technical matters? 5 to 10 minutes or so…” asked the voice on the other end. I had been told by the recruiting agent that this IT company is very thorough and they usually have 2 to 4 hour technical interviews with prospects in their own office, but given the fact that I had years of experience, the interview would be conducted via phone. “yeah, sure!” said I, and then I totally blew it…
Is this a job interview, or Who wants to be a billionaire?
I got asked some pretty basic SQL questions and also how to go about securing user input and output to prevent XSS attacks. I was completely at a loss. I forgot about htmlentities() and also made a fool of myself regarding a couple of very simple SQL questions… (needless to say, all the correct answers came back to my mind 10 minutes after the call…) Of course I know my limitations and I make sure I am upfront about those. For instance, regarding SQL I always stress there are query optimizations involving dozens of tables that I’m not used to make. Furthermore, I had been using a friggin awesome framework for ages and an ORM that abstracts most of this boilerplate stuff. I always try to follow best practices, and when I am not using a framework I am mindful of such pitfalls as SQL injection and XSS vulnerabilities. I had been doing so for years!
For the past 14 months I had been developing a complex web application with a lot of moving parts. I was using what is arguably the most robust enterprise-grade PHP framework (Symfony2), plus a lot of other cool things like PrinceXML for generating PDFs from HTML and CSS, and the PhantomJS headless browser. Before that, I had spent 4 years designing and developing websites, web apps, portals, mobile apps, and standalone multimedia applications. Before that, I spent 15+ years working as a freelance designer, web developer and teacher… and before that (in the previous millennium) I had been a C programmer at what would later become the most successful software house in the country.
Let’s face it: if you take down search engines and StackOverflow, you take down 90% of the developers in this planet.
I am well aware that recruiters have no problem in ignoring 25 years of experience in 25 minutes, but what puzzles me is that these people interview you for a totally unrealistic scenario, which I like to call the developer stranded on a desert island. It’s total BS! You are not hiring someone to sit at a desk and answer questions about programming technology. You are hiring a developer, and that’s not how developers work. Let’s face it: if you take down search engines and StackOverflow, you take down 90% of the world’s web developers. That’s not a problem in itself. It has long been found out by cognitive psychologists that there is such a thing as distributed cognition: you think using your brain AND the brains of your peers (besides books, notes and all other means of cognitive off-loading). Nothing exists in a vacuum (except for some job interviews).
If you need a developer, it is highly unlikely that you will need someone who can recite SQL commands or PHP syntax by heart. We have tools for that. And if you think that an average programmer has used 6 to 7 different programming languages, it is all the more plausible that a good programmer will not know syntax details by heart. What you need is people who know how to think, to solve problems, and to learn from their mistakes and from others.
Do you really want your employees to know stuff that can be learned in 5 seconds, and learn on-the-job all the things that require decades of training?
There is no better way to test a developer than to look at his code. My advice for recruiters is this: develop a short assignment with clear requirements that tests all the core skills, those skills that should by now have matured in any professional developer, and then have the guy walk you through the code and explain his decisions. A thorough conversation with your prospect will not only reveal if he knows what he’s talking about, but will also help you find out if he is a good fit for your team as a person.
This who-wants-to-be-a-billionaire practice among IT recruiters also means that someone looking for a job as a developer just needs to forge a believable CV (I was never asked for references nor certificates) and train for interview questions like it was a game show.
Businesses should really think about this. What do you want from an employee? Do you want him to possess rote knowledge that can be acquired in 5 seconds, and then learn on-the-job all the things that require decades of training? Or do you want him to possess the knowledge and intuition that can only be acquired through years of experience and only learn on-the-job those minor details that can be learned in 5 seconds?
Wait a minute… are you guys from MI5? Are you recruiting for the next 007 mission? Is that why you need someone who can come up with SELECTs from the top of their heads? Is there a JQuery plugin to find out if I should cut the red wire or not? Should I be able to thwart XSS attacks during high-speed chases in my Aston-Martin? Sorry, then. I’m not the guy for THAT job.*
*Well, actually… if you throw in that Aston-Martin and a Bond girl, I might reconsider.