Didoo

Our recruiting process is flawed

My experiences being interviewed for a job. And someone else's views on the recruiting process.

I have had this blogpost in draft since December 2015, probably even more. With exactly this title. A few months later I stumbled upon an article by Zach Holman (former GitHub and Gild) and I decided to do a collage of my thoughts, quotes from the article and tweets I have collected about this topic. Fast forward to today, I think it’s time to put it out there (now that I am distant from those painful memories).

As you probably know :) I have a new job. This means that I’ve been through the hiring process for a few months (I’ve been very picky this time) . And I have to tell you, after all this period I have come to the conclusion that our recruiting process is completely flawed.

It’s not only because of recruiters that are sharks waiting for the next prey (not all of them, but those of them who behave this way are poisoning the entire pond).

Not only because of job specs that lack any form of realism (at this point, you’d better write “Superman/Wonder Woman” as job title because in my entire life I have never seen all those competences and skills and experiences in one single person).

Not only because of companies that (you know firsthand) are technologically #oooold (and when I say old, I mean entire editorial platforms built on top of a super-customised Drupal5, and none of the front-end developers daring to touch the code anymore) but then they require the candidates to be React ninjas (for what?! bloody hell!).

It’s always been so, and probably will never change even in the future, who knows.

But what made the process painful – at least for me – was the complete distance between what the companies were asking in the job spec and the interview, and what you know they need and you know you can provide.

It’s a problem of selection, of filtering, I get it. But look in your company, look at your team, think of those developers (or designers) that you have met on your career, and ask yourself: what was the main problem you had when working with them, on your daily job? If they knew what a closure is, the difference between call and apply, how to find a valid palindrome?

Or maybe the problem was how they worked, individually and with the other colleagues, how they were able to estimate an effort and meet a deadline, how they organised their HTML/JS/CSS source files or named their Photoshop/Sketch layers, how readable and maintainable was their work?

And then comes a second problem, probably even bigger than the first one: tools.

People always thinks in term of “tools” and recruit consequently. Are you pro or against this tool? Can you use this tool? Can you tick all these checkboxes in this list of “required” tools (that actually we barely use, but who cares)?

And I have experienced first hand this nonsense. The following is a real email thread, with a pretty-big well-known startup, that occurred when I was doing interviews looking for a new job last year. I was pretty sure  the interviews went well (something like four or five interviews). But then I received this email:

Hi Cristiano.
I am sorry the team have been having a lot of conversations about this. Alright we felt that your skills are very obvious and very strong. Also culturally we felt you fit in there has been concerns around how you are pro react and we are using angular and in the role we were thinking of would this be an issue.
It is what is making the decision very challenging for the team here.

To which I replied in this way, the only way I was capable of:

Hi ######
this is something I tried to clarify with ******* (but clearly I failed in that): I can’t be “pro” a tool (in this specific case, React).
Tools are tools, you use them, but if they are good or bad it depends on how you use them, and for what (what are the company needs, what are the team needs, what are the user needs).

I can be “pro” a principle, an idea, a purpose. Not a tool.

I am pro the use of web components and modular design (because it makes the development process faster and more efficient, it increase the consistency of a product, and improves the communication between designers and developers). Not pro React, Angular or Polymer.
I am pro styleguides and component libraries (because again they enforce consistency and re-usability, and are the natural counterpart of web components) but not a specific implementation or adoption of them (it can be a PDF, for me, as soon as makes sense for the needs).

There is good in React? Yes, of course. There is good in Angular? Yes, of course! Look what a friend of mine tweeted in the last days (he was at AngularConnect):

Angular2 looks interesting. It’s taking the best bits from other frameworks: universal js, cli tool, rx and immutable data – link
Native support for Observables and template transforms look like the best features of Angular2 to me. Decisive factors? – link
Impressive form builder with custom fields and validators demoed by @RicardoMallols  – link

I met him yesterday, and the first I asked him when we met was to tell me about the new features of Angular2 that were presented, because I was eager and very excited to hear about it. So, am I “pro” Angular now? :)

As you know, I work at 2 minutes from your offices. More than happy to come and discuss with anyone who has doubts about me being “pro” a tool, and try to clarify any other doubt you may have. Communication and dialog, that’s what I believe in.

As you can see, I was “fit” for the job, the people that interviewed me liked me but… I was “pro React”, a JavaScript library! (and looking back now, it’s even more ridiculous considered what React has become now; and of course, it can be also a totally made up excuse to say me “No” in a gentle way, I am totally aware of it).

And we come to the post by Zach Holman, titled “Startup Interviewing is Fucked” that contains this nailing tweet:

and these reflections:

“we’re still romanticizing the idea that programming riddles will magically be the best benchmark for hiring, even though technology is very rarely the cause for any given startup’s success.”

“A huge problem with all this is that it creates a power dynamic that virtually all but assures that people who are bad at technical interviews will fail.”

“Every single product I’ve built in my professional career has not had a correct answer. It’s more akin to carving a statue out of marble: you have a vague understanding of what you want to see, but you have to continually chip away at it and refine it until you end up with one possible result. You arrive at the answer, together, with your teammates. You don’t sit on a preconceived answer and direct your coworker to slug through it alone.”

How can you not agree with him?

An how can you not agree with Jessica Rose, that in this keynote at Codemotion Rome explains how there is a clear bias in the way companies are hiring, that is harmful and detrimental not only for the candidates but especially for the company themselves.

These companies are missing a lot of opportunities to hire the “right” person, the one they actually need, not the one that they think meets some kind of abstract (unrealistic) criteria.

UPDATE: and on the other side, this is how amazing companies like Made by Many decided to change their hiring process to hire great developers:

“This year we’ve made a concerted effort to make our hiring process even better. From the language of our job ads to questions we ask at interview and our overarching assessment criteria. Most importantly we favour the characteristics that identify great software developers rather than specific experience in particular languages or techniques.”

Go to blog index