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).
A guide to developer job descriptions pic.twitter.com/RQW3jhMseO
— Stackify (@Stackify) January 27, 2016
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?
All these poor students going through college when all they actually need to know is how to write a Fibonacci solution on a whiteboard.
— I Am Devloper (@iamdevloper) December 1, 2015
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:
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:
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.
And we come to the post by Zach Holman, titled “Startup Interviewing is Fucked” that contains this nailing tweet:
Startup: We’re hiring people to reinvent and change the world!
Interviewer: Please shift this char onto this array.
— Zach Holman (@holman) December 29, 2015
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.
- November 4, 2016
Two hundreds years have passed, but still technical choices are discussed on the tip of personal tasteOctober 3, 2016
An inspiring evening about interactions, humans, agents, instability and hacks.September 29, 2016
A transcript of the Interaction Design London meetupJune 30, 2016
- June 24, 2016
A series of interviews on BEM methodologyMay 12, 2016
Writeup of a special event in LondonApril 26, 2016
An unexpected conference in NewcastleApril 21, 2016
Some good news from a very personal point of observationMarch 2, 2016
I've joined the company as Mobile Web Developer.January 25, 2016
After 16 months of hard work, it's time for me to take new roadsJanuary 18, 2016
Una riflessione in pausa pranzo, nata da una discussione fra amiciJanuary 6, 2016
- December 1, 2015
Don Norman and Bruce Tognazzini explain how and why they formalised the principles of good, understandable design in Apple’s Human Interface Guidelines (and much more)November 25, 2015
If you have eyes to see, it will tell you a lot about your team (and your company)October 1, 2015
How a small (in size) but great (in content and people) meetup becomes “epic”September 29, 2015
The building blocks of the web are small components, but you need a systemic view to win his inherent complexityJuly 27, 2015
(OK, kinda melodramatic as a title, but I do not get a better metaphor)July 15, 2015
(OK, un po’ melodrammatico come titolo; ma non mi viene un’altra metafora)July 8, 2015
An open letter to a special personJune 5, 2015
Are we building the web, or digging a hole around it?June 2, 2015
It should be easy to answer this question, right? Instead...April 30, 2015
A newsletter with hand picked interesting links, delivered in your inbox every day at lunch timeApril 15, 2015
Then, and only after that, it becomes (also) a creative effortFebruary 25, 2015
(or Design, as you like)January 20, 2015
More and more “fanboys” can no longer bear the inglorious decline of Apple’s softwareJanuary 10, 2015
Some notes, resources and links that helped me while preparing the talkDecember 3, 2014
I am so happy that I had the opportunity to take part to it, as a speaker and attendeeDecember 1, 2014
Some quick notes from the TechTalks@CassNovember 14, 2014
The hard truth about CEOs and their “ability” to sink a companyNovember 10, 2014
A brief journey through startups, developers and physicsNovember 6, 2014
Today after 18 months I am leaving the company and taking a new road.September 26, 2014
They are the dots that you connect to understand your lifeSeptember 15, 2014
This post is dedicated to a special friend and colleague, that deserves even more than the Smashing Magazine homepage.September 4, 2014